From joe.darcy at oracle.com  Wed May  1 01:59:23 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Apr 2019 18:59:23 -0700
Subject: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem example
 with map factory methods
Message-ID: <193181fd-a6a5-24d1-3bb1-7fec7780468b@oracle.com>

Hello,

The readability of usage example for FileSystems.newFileSystem would 
benefit from using a method to create a map from JEP 269: "Convenience 
Factory Methods for Collections." The current example is rendered in 
javadoc as

 ?? Map<String,String> env = new HashMap<>();
 ?? env.put("capacity", "16G");
 ?? env.put("blockSize", "4k");
 ?? FileSystem fs = 
FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);

and the proposed replacement renders as

 ?? FileSystem fs = 
FileSystems.newFileSystem(URI.create("memory:///?name=logfs"),
Map.of("capacity", "16G",
"blockSize", "4k"));

I've verified the replacement compiles.

Patch below.

Thanks,

-Joe

--- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue Apr 
30 16:11:42 2019 -0700
+++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Tue Apr 
30 18:52:11 2019 -0700
@@ -252,10 +252,9 @@
 ????? * Suppose there is a provider identified by the scheme {@code 
"memory"}
 ????? * installed:
 ????? * <pre>
-???? *?? Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
-???? *?? env.put("capacity", "16G");
-???? *?? env.put("blockSize", "4k");
-???? *?? FileSystem fs = 
FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);
+???? *?? FileSystem fs = 
FileSystems.newFileSystem(URI.create("memory:///?name=logfs"),
+ * Map.of("capacity", "16G",
+ * "blockSize", "4k"));
 ????? * </pre>
 ????? *
 ????? * @param?? uri


From Alan.Bateman at oracle.com  Wed May  1 06:16:49 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 May 2019 07:16:49 +0100
Subject: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem
 example with map factory methods
In-Reply-To: <193181fd-a6a5-24d1-3bb1-7fec7780468b@oracle.com>
References: <193181fd-a6a5-24d1-3bb1-7fec7780468b@oracle.com>
Message-ID: <ef5734fd-13ae-e478-6ec1-ea9286570b58@oracle.com>

On 01/05/2019 02:59, Joe Darcy wrote:
> :
>
> --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue 
> Apr 30 16:11:42 2019 -0700
> +++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Tue 
> Apr 30 18:52:11 2019 -0700
> @@ -252,10 +252,9 @@
> ????? * Suppose there is a provider identified by the scheme {@code 
> "memory"}
> ????? * installed:
> ????? * <pre>
> -???? *?? Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
> -???? *?? env.put("capacity", "16G");
> -???? *?? env.put("blockSize", "4k");
> -???? *?? FileSystem fs = 
> FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);
> +???? *?? FileSystem fs = 
> FileSystems.newFileSystem(URI.create("memory:///?name=logfs"),
> + * Map.of("capacity", "16G",
> + * "blockSize", "4k"));
Changing it to use an unmodifable map is good. One nit the really long 
line in the source will be annoying with future side-by-side diffs. It 
wouldn't take much from the readability to keep env.

-Alan

From christoph.langer at sap.com  Wed May  1 13:10:49 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 1 May 2019 13:10:49 +0000
Subject: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem
 example with map factory methods
In-Reply-To: <ef5734fd-13ae-e478-6ec1-ea9286570b58@oracle.com>
References: <193181fd-a6a5-24d1-3bb1-7fec7780468b@oracle.com>
 <ef5734fd-13ae-e478-6ec1-ea9286570b58@oracle.com>
Message-ID: <AM6PR02MB5192046B0DF3487AF77A1DCB8A3B0@AM6PR02MB5192.eurprd02.prod.outlook.com>

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Alan Bateman
> Sent: Mittwoch, 1. Mai 2019 08:17
> To: Joe Darcy <joe.darcy at oracle.com>; nio-dev <nio-
> dev at openjdk.java.net>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem
> example with map factory methods
> 
> On 01/05/2019 02:59, Joe Darcy wrote:
> > :
> >
> > --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue
> > Apr 30 16:11:42 2019 -0700
> > +++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Tue
> > Apr 30 18:52:11 2019 -0700
> > @@ -252,10 +252,9 @@
> > ????? * Suppose there is a provider identified by the scheme {@code
> > "memory"}
> > ????? * installed:
> > ????? * <pre>
> > -???? *?? Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
> > -???? *?? env.put("capacity", "16G");
> > -???? *?? env.put("blockSize", "4k");
> > -???? *?? FileSystem fs =
> > FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);
> > +???? *?? FileSystem fs =
> > FileSystems.newFileSystem(URI.create("memory:///?name=logfs"),
> > + * Map.of("capacity", "16G",
> > + * "blockSize", "4k"));
> Changing it to use an unmodifable map is good. One nit the really long
> line in the source will be annoying with future side-by-side diffs. It
> wouldn't take much from the readability to keep env.

+1


From andy.herrick at oracle.com  Wed May  1 14:59:06 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 1 May 2019 10:59:06 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
Message-ID: <b7abc46a-e78c-9516-c6e0-79e9c0a95ac0@oracle.com>

I filed task JDK-8223187 
<https://bugs.openjdk.java.net/browse/JDK-8223187> to look into (1) and 
CR JDK-8223188 <https://bugs.openjdk.java.net/browse/JDK-8223188> to 
address (2).

/Andy


On 4/30/2019 6:53 PM, Phil Race wrote:
> A couple of questions / observations :-
> 1) setlocale
> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/linux/native/jpackageapplauncher/launcher.cpp.html
>
>    52 int main(int argc, char *argv[]) {
>    53     int result = 1;
>    54     setlocale(LC_ALL, "en_US.utf8");
>
> Why is this setlocale() call there ?
>
> What does this mean for a user whose desktop is (say) German, or French, or Japanese ?
>
> When the Java app is launched from this environment is it inheriting this US locale ? I hope not.
>
> We have the same on Mac :-
>
> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/macosx/native/jpackageapplauncher/main.m.html
>
> and windows :-
>
> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/native/jpackageapplauncher/WinLauncher.cpp.html
>
>    64     ::setlocale(LC_ALL, "en_US.utf8");
>
>
> 2) C++ files containing C
>
> src/jdk.jpackage/windows/native/libjpackage/WindowsRegistry.cpp
>
>
>
> src/jdk.jpackage/windows/native/libjpackage/jpackage.cpp
>
>
>
> src/jdk.jpackage/windows/native/libwixhelper/libwixhelper.cpp
>
>
>
> have their entire contents wrapped in
>
>    36 #ifdef __cplusplus
>    37 extern "C" {
>    38 #endif
>
>   159 #ifdef __cplusplus
>   160 }
>   161 #endif
>
> wouldn't it be better to put them in .c files ?
>
>
> -phil.


From andy.herrick at oracle.com  Wed May  1 15:08:55 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 1 May 2019 11:08:55 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
Message-ID: <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>


I have filed JDK-8223189 
<https://bugs.openjdk.java.net/browse/JDK-8223189> to address these.

/Andy


On 4/30/2019 7:02 PM, Kevin Rushforth wrote:
> I have a couple nit-picky comments:
>
> 1. The change to src/jdk.jlink/share/classes/module-info.java is 
> unrelated to jpackage and should be reverted (there is only a 
> white-space change and a copyright date change to that file)
>
>
> 2. The following files have whitespace errors that will cause jcheck 
> to fail:
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java:326: 
> Trailing whitespace
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java:58: 
> Tab character
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkBundlerHelper.java:217: 
> Trailing whitespace
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java:55: 
> Trailing whitespace
>
>
> 3. I recommend to replace the wild-card imports with explicit imports, 
> for example:
> src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java 
> (java.util.* and java.io.*)
> (I think the wild-card static import is fine, just not the import 
> every class from a package)
>
> I'll try to remember to note these as I go through the review. This 
> one could be done as a follow-up bug rather than doing it prior to 
> integration if you prefer.
>
> -- Kevin
>


From chris.hegarty at oracle.com  Wed May  1 16:45:02 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 1 May 2019 17:45:02 +0100
Subject: RFR: 8219202: Use Unsynchronized StringBuilder in
 sun.net.www.ParseUtil
In-Reply-To: <CAC1Wh8Hd=KYMC6DGVfQm+9_BBOm7hWT8aX324LMevJoQfWhH5w@mail.gmail.com>
References: <CAC1Wh8Hd=KYMC6DGVfQm+9_BBOm7hWT8aX324LMevJoQfWhH5w@mail.gmail.com>
Message-ID: <AE579D6D-2644-4DA3-B71D-5C20C1395BDC@oracle.com>

Alan,

> On 30 Apr 2019, at 18:53, Alan Malloy <amalloy at google.com> wrote:
> 
> Hello. Please review this patch to use StringBuilder instead of
> StringBuffer in sun.net.www.ParseUtil, a usage that does not need
> synchronization.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8219202
> webrev: http://cr.openjdk.java.net/~cushon/8219202/webrev.01/ <http://cr.openjdk.java.net/~cushon/8219202/webrev.01/>

Looks ok.

> Testing: All of jtreg:test/jdk/sun/net/www pass locally. No new test added,
> as no behavior change is intended.

Can you please add an appropriate noreg-XXX label [1] to the JIRA
issue if an existing test is not being modified or a new one added.

-Chris.

[1] https://openjdk.java.net/guide/changePlanning.html#noreg



From huizhe.wang at oracle.com  Wed May  1 16:46:32 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 01 May 2019 09:46:32 -0700
Subject: RFR(JDK 13/java.xml) 8220818: Validator does not find missing match
 for keyref error
Message-ID: <5CC9CD68.4050803@oracle.com>

Please review a fix for a regression introduced during JDK 9 
development. The issue was that a patch ported to the JDK added a 
counter to count the number of values found in the XML document, and 
then compared with the constraint's field count. The problem was that 
the counter would get updated as the validator parsed through the XML 
document. When the XML contains multiple elements, the counter reflected 
the last one. If the last one didn't have the problem field, then errors 
in previous elements wouldn't get reported. The fix is to add a field to 
indicate whether the field exists in any of the elements.

All tests and the new test that covers both cases in the original patch 
and that reported in the JBS passed.

JBS: https://bugs.openjdk.java.net/browse/JDK-8220818
webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8220818/webrev/

Thanks,
Joe

From joe.darcy at oracle.com  Wed May  1 16:53:27 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 1 May 2019 09:53:27 -0700
Subject: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem
 example with map factory methods
In-Reply-To: <ef5734fd-13ae-e478-6ec1-ea9286570b58@oracle.com>
References: <193181fd-a6a5-24d1-3bb1-7fec7780468b@oracle.com>
 <ef5734fd-13ae-e478-6ec1-ea9286570b58@oracle.com>
Message-ID: <3dd3eaee-643c-6d35-151b-7bd932022fe9@oracle.com>

Hi Alan,

The maximum line length is actually slightly reduced by the proposed patch:

--- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue Apr 
30 16:11:42 2019 -0700
+++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Wed May 
01 00:12:25 2019 -0700
@@ -252,10 +252,9 @@
 ????? * Suppose there is a provider identified by the scheme {@code 
"memory"}
 ????? * installed:
 ????? * <pre>
-???? *?? Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
-???? *?? env.put("capacity", "16G");
-???? *?? env.put("blockSize", "4k");
-???? *?? FileSystem fs = 
FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);
+???? *?? FileSystem fs = 
FileSystems.newFileSystem(URI.create("memory:///?name=logfs"),
+ * Map.of("capacity", "16G",
+ * "blockSize", "4k"));
 ????? * </pre>
 ????? *
 ????? * @param?? uri

Keeping env to one line also gives a comparably long line length:

--- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue Apr 
30 16:11:42 2019 -0700
+++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Wed May 
01 09:50:15 2019 -0700
@@ -252,9 +252,7 @@
 ????? * Suppose there is a provider identified by the scheme {@code 
"memory"}
 ????? * installed:
 ????? * <pre>
-???? *?? Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
-???? *?? env.put("capacity", "16G");
-???? *?? env.put("blockSize", "4k");
+???? *?? Map&lt;String,String&gt; env = Map.of("capacity", "16G", 
"blockSize", "4k");
 ????? *?? FileSystem fs = 
FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);
 ????? * </pre>
 ????? *
The {"capacity", "16G"} and {"blockSize", "4k"} can be put on different 
lines to provide a stronger visual hint of grouping.

Which of these alternatives do you prefer?

Thanks,

-Joe

On 4/30/2019 11:16 PM, Alan Bateman wrote:
> On 01/05/2019 02:59, Joe Darcy wrote:
>> :
>>
>> --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue 
>> Apr 30 16:11:42 2019 -0700
>> +++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Tue 
>> Apr 30 18:52:11 2019 -0700
>> @@ -252,10 +252,9 @@
>> ????? * Suppose there is a provider identified by the scheme {@code 
>> "memory"}
>> ????? * installed:
>> ????? * <pre>
>> -???? *?? Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
>> -???? *?? env.put("capacity", "16G");
>> -???? *?? env.put("blockSize", "4k");
>> -???? *?? FileSystem fs = 
>> FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);
>> +???? *?? FileSystem fs = 
>> FileSystems.newFileSystem(URI.create("memory:///?name=logfs"),
>> + * Map.of("capacity", "16G",
>> + * "blockSize", "4k"));
> Changing it to use an unmodifable map is good. One nit the really long 
> line in the source will be annoying with future side-by-side diffs. It 
> wouldn't take much from the readability to keep env.
>
> -Alan

From Alan.Bateman at oracle.com  Wed May  1 17:00:11 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 May 2019 18:00:11 +0100
Subject: RFR: 8222895: StackOverflowError in custom security manager that
 relies on ClassSpecializer
In-Reply-To: <d8ec15e4-adbe-f342-ba5a-638a5e2d9e8e@oracle.com>
References: <d8ec15e4-adbe-f342-ba5a-638a5e2d9e8e@oracle.com>
Message-ID: <c1b342d6-8316-8052-1002-b91b84cc6e55@oracle.com>

On 24/04/2019 13:49, Claes Redestad wrote:
> Hi,
>
> recent changes to the String concatenation bootstrap sequence[1]
> accidentally uncovered an issue introduced earlier by changing the
> ClassSpecializer to use Lookup.defineClass[2].
>
> The issue with this is the introduction of a call to SM.checkPermission
> deep inside the ClassSpecializer code used when bootstrapping certain
> String concatenation expressions. When triggered, this causes a
> recursive bootstrap cycle and a crash with a StackOverflowError.
>
> This is related to earlier bootstrapping issues in the area[3], and
> would have been caught by the regression test added then if not for the
> fact that we've been rather successful in avoiding the use of
> ClassSpecializer during bootstrap of commonly used concatenation shapes.
>
> Providing a more contorted concatenation shape in the test ensures we
> drop into the ClassSpecializer code path where the recursive
> checkPermission call happens. The updated test passes before
> JDK-8181443, fails since, and passes with the changes proposed in this
> patch.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8222895/open.00/
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8222895
This looks okay as a temporary solution to fix the regression. It will 
probably need a bit of thought to figure how to get the specializer to 
work when there is a security manager, something for another issue.

-Alan.

From chris.hegarty at oracle.com  Wed May  1 17:25:46 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 1 May 2019 18:25:46 +0100
Subject: RFR: 8219202: Use Unsynchronized StringBuilder in
 sun.net.www.ParseUtil
In-Reply-To: <CAC1Wh8E6eWocCfi-y2jnmxz4Zbo9H-sxZC8-NY=BNXq2MqkgRw@mail.gmail.com>
References: <CAC1Wh8Hd=KYMC6DGVfQm+9_BBOm7hWT8aX324LMevJoQfWhH5w@mail.gmail.com>
 <AE579D6D-2644-4DA3-B71D-5C20C1395BDC@oracle.com>
 <CAC1Wh8E6eWocCfi-y2jnmxz4Zbo9H-sxZC8-NY=BNXq2MqkgRw@mail.gmail.com>
Message-ID: <6ACB8C90-F37B-4559-9CE4-DAAF945B87C3@oracle.com>

Alan,

> On 1 May 2019, at 18:08, Alan Malloy <amalloy at google.com> wrote:
> 
> It looks to me like Liam, acting as my sponsor, put noreg-cleanup on this bug a couple days ago, which seems reasonable to me.

Agreed.

> Do you suggest an additional label?

No. My mistake I missed that there was already a label added.

-Chris.

From alexey.semenyuk at oracle.com  Wed May  1 17:34:59 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 1 May 2019 13:34:59 -0400
Subject: jpackage producing non-working binaries on Windows
In-Reply-To: <alpine.DEB.2.20.1904301609580.10640@urchin.earth.li>
References: <alpine.DEB.2.20.1904301609580.10640@urchin.earth.li>
Message-ID: <8e66036e-fa7d-586e-fe97-76701952556f@oracle.com>

Hi Tom,

What is your jpackage command line? Could you please rerun it with 
JPACKAGE_DEBUG environment variable set to "true".

- Alexey

On 4/30/2019 11:15 AM, Tom Anderson wrote:
> Hello,
>
> I am trying out the early-access jpackage tool. It works perfectly on 
> Linux, but on Windows produces a binary which does not do anything 
> when run.
>
> I would like to either fix any error i have made, or help you identify 
> a bug, if there is one!
>
> Is this the right place to come with this problem? If not, where 
> should i go? Is there a list of known issues other than on the 
> download page [1]? What debugging steps should i try? Would a 
> self-contained example be helpful to you? What other information would 
> you like?
>
> Regards,
> tom
>
> [1] https://jdk.java.net/jpackage/


From kevin.rushforth at oracle.com  Wed May  1 17:56:15 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 1 May 2019 10:56:15 -0700
Subject: jpackage producing non-working binaries on Windows
In-Reply-To: <8e66036e-fa7d-586e-fe97-76701952556f@oracle.com>
References: <alpine.DEB.2.20.1904301609580.10640@urchin.earth.li>
 <8e66036e-fa7d-586e-fe97-76701952556f@oracle.com>
Message-ID: <5d91ace1-85bd-f20b-fe1d-fc5d1d2d7784@oracle.com>

When you say "doesn't do anything when run", do you perhaps mean that 
you have some print statements in your program and you don't see them 
when you run it from a command shell? If so, then this is expected, and 
you need to add the "--win-console" option.

If it's something else, then Alexey's suggestion is the next thing to try.

-- Kevin


On 5/1/2019 10:34 AM, Alexey Semenyuk wrote:
> Hi Tom,
>
> What is your jpackage command line? Could you please rerun it with 
> JPACKAGE_DEBUG environment variable set to "true".
>
> - Alexey
>
> On 4/30/2019 11:15 AM, Tom Anderson wrote:
>> Hello,
>>
>> I am trying out the early-access jpackage tool. It works perfectly on 
>> Linux, but on Windows produces a binary which does not do anything 
>> when run.
>>
>> I would like to either fix any error i have made, or help you 
>> identify a bug, if there is one!
>>
>> Is this the right place to come with this problem? If not, where 
>> should i go? Is there a list of known issues other than on the 
>> download page [1]? What debugging steps should i try? Would a 
>> self-contained example be helpful to you? What other information 
>> would you like?
>>
>> Regards,
>> tom
>>
>> [1] https://jdk.java.net/jpackage/
>


From brent.christian at oracle.com  Wed May  1 18:15:38 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 1 May 2019 11:15:38 -0700
Subject: RFR 8221267 : Document the
 jdk.net.URLClassPath.showIgnoredClassPathEntries system property
Message-ID: <db7448d7-43f8-b5b3-b9d3-7c7797e487b9@oracle.com>

Hi,

The "jdk.net.URLClassPath.showIgnoredClassPathEntries" system property 
was added by 8211941[1].  When enabled, it provides debugging output of 
invalid "Class-Path" attributes in JAR manifests (which are ordinarily 
silently ignored).

The new property will be mentioned in the JDK 13 Release Notes, but it 
could also be helpful to mention in the JavaDoc (as requested during CSR 
review[2]).

Issues w/ Class-Path entries happen during classloading, and the 
ClassLoader.getSystemClassLoader() JavaDoc already has an @implNote 
describing other classloading-related system properties.  So that seems 
as good a place as any.

Please review this JavaDoc addition.  CSR[3] has been approved.

http://cr.openjdk.java.net/~bchristi/8221267/webrev01/

Thanks,
-Brent

1. https://bugs.openjdk.java.net/browse/JDK-8211941
2. 
https://bugs.openjdk.java.net/browse/JDK-8217215?focusedCommentId=14251670&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14251670
3. https://bugs.openjdk.java.net/browse/JDK-8223103


From Alan.Bateman at oracle.com  Wed May  1 18:20:14 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 May 2019 19:20:14 +0100
Subject: RFR 8221267 : Document the
 jdk.net.URLClassPath.showIgnoredClassPathEntries system property
In-Reply-To: <db7448d7-43f8-b5b3-b9d3-7c7797e487b9@oracle.com>
References: <db7448d7-43f8-b5b3-b9d3-7c7797e487b9@oracle.com>
Message-ID: <30576e95-c332-a07d-1332-a7fe16e3d44a@oracle.com>

On 01/05/2019 19:15, Brent Christian wrote:
> Hi,
>
> The "jdk.net.URLClassPath.showIgnoredClassPathEntries" system property 
> was added by 8211941[1].? When enabled, it provides debugging output 
> of invalid "Class-Path" attributes in JAR manifests (which are 
> ordinarily silently ignored).
>
> The new property will be mentioned in the JDK 13 Release Notes, but it 
> could also be helpful to mention in the JavaDoc (as requested during 
> CSR review[2]).
>
> Issues w/ Class-Path entries happen during classloading, and the 
> ClassLoader.getSystemClassLoader() JavaDoc already has an @implNote 
> describing other classloading-related system properties.? So that 
> seems as good a place as any.
>
> Please review this JavaDoc addition.? CSR[3] has been approved.
>
> http://cr.openjdk.java.net/~bchristi/8221267/webrev01/
This is the right @implNote to extend so I think this looks good.

-Alan

From brian.burkhalter at oracle.com  Wed May  1 18:20:03 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 May 2019 11:20:03 -0700
Subject: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem
 example with map factory methods
In-Reply-To: <3dd3eaee-643c-6d35-151b-7bd932022fe9@oracle.com>
References: <193181fd-a6a5-24d1-3bb1-7fec7780468b@oracle.com>
 <ef5734fd-13ae-e478-6ec1-ea9286570b58@oracle.com>
 <3dd3eaee-643c-6d35-151b-7bd932022fe9@oracle.com>
Message-ID: <A6A62C48-B3D9-4F1A-AE66-BD5A7746EE8D@oracle.com>


> On May 1, 2019, at 9:53 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue Apr 30 16:11:42 2019 -0700
> +++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Wed May 01 00:12:25 2019 -0700
> @@ -252,10 +252,9 @@
>       * Suppose there is a provider identified by the scheme {@code "memory"}
>       * installed:
>       * <pre>
> -     *   Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
> -     *   env.put("capacity", "16G");
> -     *   env.put("blockSize", "4k");
> -     *   FileSystem fs = FileSystems.newFileSystem(URI.create("memory:///?name=logfs <memory:///?name=logfs>"), env);
> +     *   FileSystem fs = FileSystems.newFileSystem(URI.create("memory:///?name=logfs <memory:///?name=logfs>"),
> + * Map.of("capacity", "16G",
> + * "blockSize", "4k"));
>       * </pre>
>       *
>       * @param   uri
> 
> Keeping env to one line also gives a comparably long line length:
> 
> --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue Apr 30 16:11:42 2019 -0700
> +++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Wed May 01 09:50:15 2019 -0700
> @@ -252,9 +252,7 @@
>       * Suppose there is a provider identified by the scheme {@code "memory"}
>       * installed:
>       * <pre>
> -     *   Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
> -     *   env.put("capacity", "16G");
> -     *   env.put("blockSize", "4k");
> +     *   Map&lt;String,String&gt; env = Map.of("capacity", "16G", "blockSize", "4k");
>       *   FileSystem fs = FileSystems.newFileSystem(URI.create("memory:///?name=logfs <memory:///?name=logfs>"), env);
>       * </pre>
>       *
> The {"capacity", "16G"} and {"blockSize", "4k"} can be put on different lines to provide a stronger visual hint of grouping.
> 
> Which of these alternatives do you prefer?

I like the second one. Another alternative would be something like:

+     *   FileSystem fs = FileSystems.newFileSystem(URI.create("memory:///?name=logfs <memory:///?name=logfs>"),
+     *           Map.of("capacity", "16G?, "blockSize", "4k"));

Brian



From lance.andersen at oracle.com  Wed May  1 18:26:31 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 1 May 2019 14:26:31 -0400
Subject: RFR 8221267 : Document the
 jdk.net.URLClassPath.showIgnoredClassPathEntries system property
In-Reply-To: <db7448d7-43f8-b5b3-b9d3-7c7797e487b9@oracle.com>
References: <db7448d7-43f8-b5b3-b9d3-7c7797e487b9@oracle.com>
Message-ID: <0E7A97CC-4B4C-4A3C-B38A-D8B9DC914458@oracle.com>

Looks good Brent.
> On May 1, 2019, at 2:15 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Hi,
> 
> The "jdk.net.URLClassPath.showIgnoredClassPathEntries" system property was added by 8211941[1].  When enabled, it provides debugging output of invalid "Class-Path" attributes in JAR manifests (which are ordinarily silently ignored).
> 
> The new property will be mentioned in the JDK 13 Release Notes, but it could also be helpful to mention in the JavaDoc (as requested during CSR review[2]).
> 
> Issues w/ Class-Path entries happen during classloading, and the ClassLoader.getSystemClassLoader() JavaDoc already has an @implNote describing other classloading-related system properties.  So that seems as good a place as any.
> 
> Please review this JavaDoc addition.  CSR[3] has been approved.
> 
> http://cr.openjdk.java.net/~bchristi/8221267/webrev01/
> 
> Thanks,
> -Brent
> 
> 1. https://bugs.openjdk.java.net/browse/JDK-8211941
> 2. https://bugs.openjdk.java.net/browse/JDK-8217215?focusedCommentId=14251670&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14251670
> 3. https://bugs.openjdk.java.net/browse/JDK-8223103
> 

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




From brian.burkhalter at oracle.com  Wed May  1 18:29:36 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 May 2019 11:29:36 -0700
Subject: RFR 8221267 : Document the
 jdk.net.URLClassPath.showIgnoredClassPathEntries system property
In-Reply-To: <db7448d7-43f8-b5b3-b9d3-7c7797e487b9@oracle.com>
References: <db7448d7-43f8-b5b3-b9d3-7c7797e487b9@oracle.com>
Message-ID: <8AF2A3F5-09C4-49BE-8E4A-213C22AAFB9B@oracle.com>

+1

Brian

> On May 1, 2019, at 11:15 AM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Please review this JavaDoc addition.  CSR[3] has been approved.
> 
> http://cr.openjdk.java.net/~bchristi/8221267/webrev01/ <http://cr.openjdk.java.net/~bchristi/8221267/webrev01/>

From Alan.Bateman at oracle.com  Wed May  1 18:43:29 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 May 2019 19:43:29 +0100
Subject: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem
 example with map factory methods
In-Reply-To: <3dd3eaee-643c-6d35-151b-7bd932022fe9@oracle.com>
References: <193181fd-a6a5-24d1-3bb1-7fec7780468b@oracle.com>
 <ef5734fd-13ae-e478-6ec1-ea9286570b58@oracle.com>
 <3dd3eaee-643c-6d35-151b-7bd932022fe9@oracle.com>
Message-ID: <3d983664-dc0c-9b91-2bb3-6d6bd4c7258a@oracle.com>



On 01/05/2019 17:53, Joe Darcy wrote:
> :
>
> Keeping env to one line also gives a comparably long line length:
>
> --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue 
> Apr 30 16:11:42 2019 -0700
> +++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Wed 
> May 01 09:50:15 2019 -0700
> @@ -252,9 +252,7 @@
> ????? * Suppose there is a provider identified by the scheme {@code 
> "memory"}
> ????? * installed:
> ????? * <pre>
> -???? *?? Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
> -???? *?? env.put("capacity", "16G");
> -???? *?? env.put("blockSize", "4k");
> +???? *?? Map&lt;String,String&gt; env = Map.of("capacity", "16G", 
> "blockSize", "4k");
> ????? *?? FileSystem fs = 
> FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);
> ????? * </pre>
> ????? *
> The {"capacity", "16G"} and {"blockSize", "4k"} can be put on 
> different lines to provide a stronger visual hint of grouping.
>
> Which of these alternatives do you prefer?
This looks okay. Brian's suggestion looks good too (I don't want to 
waste your time on this one).

-Alan

From amalloy at google.com  Wed May  1 17:08:21 2019
From: amalloy at google.com (Alan Malloy)
Date: Wed, 1 May 2019 10:08:21 -0700
Subject: RFR: 8219202: Use Unsynchronized StringBuilder in
 sun.net.www.ParseUtil
In-Reply-To: <AE579D6D-2644-4DA3-B71D-5C20C1395BDC@oracle.com>
References: <CAC1Wh8Hd=KYMC6DGVfQm+9_BBOm7hWT8aX324LMevJoQfWhH5w@mail.gmail.com>
 <AE579D6D-2644-4DA3-B71D-5C20C1395BDC@oracle.com>
Message-ID: <CAC1Wh8E6eWocCfi-y2jnmxz4Zbo9H-sxZC8-NY=BNXq2MqkgRw@mail.gmail.com>

It looks to me like Liam, acting as my sponsor, put noreg-cleanup on this
bug a couple days ago, which seems reasonable to me. Do you suggest an
additional label?

On Wed, May 1, 2019 at 9:45 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Can you please add an appropriate noreg-XXX label [1] to the JIRA
> issue if an existing test is not being modified or a new one added.
> [1] https://openjdk.java.net/guide/changePlanning.html#noreg
>

From vicente.romero at oracle.com  Wed May  1 20:08:11 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 1 May 2019 16:08:11 -0400
Subject: RFR: JDK-8219483: j.l.c.ClassDesc::nested(String, String...)
 doesn't throw NPE if any arg is null
In-Reply-To: <5CC8C57A.5020906@oracle.com>
References: <7b71bdb8-53cb-fdd3-eca4-4e4ba89fe5a4@oracle.com>
 <9b0ea90c-ddca-ab76-caf0-c41e2b56aa2c@oracle.com>
 <042c4118-e6c2-8094-6b8e-d38c519b0196@oracle.com>
 <5CC8C57A.5020906@oracle.com>
Message-ID: <f69543af-d683-94e1-236a-54660927f43e@oracle.com>

Hi Joe,

Thanks for the reviews, I have updated the webrev after you suggestion [1],

Vicente

[1] http://cr.openjdk.java.net/~vromero/8219483/webrev.02/

On 4/30/19 6:00 PM, Joseph D. Darcy wrote:
> Hi Vicente,
>
> CSR reviewed.
>
> I suggesting adding a test case for
>
> ??? cd.nested("good", null)
>
> Thanks,
>
> -Joe
>
> On 4/29/2019 2:41 PM, Vicente Romero wrote:
>> Hi Joe,
>>
>> Thanks for the review. I have modified the patch, please see [1] . I 
>> still need a reviewer for the CSR [2],
>>
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.01/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8223034
>>
>>
>> On 4/26/19 9:32 PM, Joe Darcy wrote:
>>> Hi Vicente,
>>>
>>> For purposes of a better exception message, do you want to 
>>> explicitly check moreNestedNames for null in some way before 
>>> accessing its contents? Also, I'd commend the spec be updated 
>>> slightly to
>>>
>>> ??? @throws NullPointerException if any argument or its contents is 
>>> {@code null}
>>>
>>> assuming the desired behavior is a NPE if an element of 
>>> moreNestedNames is null as opposed to ust moreNestedNames itself.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 4/26/2019 9:33 AM, Vicente Romero wrote:
>>>> Hi,
>>>>
>>>> Please review fix [1] and CSR [2] for [3]. The API for method 
>>>> j.l.c.ClassDesc::nested(String, String...) states that it should 
>>>> throw NPE if any of the arguments is null. The implementation is 
>>>> not in sync with the API and should be corrected,
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.00/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8223034
>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8219483
>>>>
>>
>


From james.laskey at oracle.com  Wed May  1 20:42:43 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 1 May 2019 17:42:43 -0300
Subject: RFR (CSR) - JDK-8218285 ClassDesc should have a full name method 
Message-ID: <B6442EBA-8A82-4BAE-AE6A-5D002B0363DE@oracle.com>

Please review. Thank you.

Cheers,

-- Jim



Summary: Add the method ClassDesc::displayFullName to return the fully qualified class name from a ClassDesc. Add a second method MethodTypeDesc::displayFullDescriptor which returns the MethodTypeDesc descriptor using fully qualified class names.

csr: https://bugs.openjdk.java.net/browse/JDK-8218285 <https://bugs.openjdk.java.net/browse/JDK-8218285>
jbs: https://bugs.openjdk.java.net/browse/JDK-8212975 <https://bugs.openjdk.java.net/browse/JDK-8212975>
webrev: http://cr.openjdk.java.net/~jlaskey/8212975/webrev-03/index.html <http://cr.openjdk.java.net/~jlaskey/8212975/webrev-03/index.html>

From joe.darcy at oracle.com  Wed May  1 20:48:25 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 1 May 2019 13:48:25 -0700
Subject: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem
 example with map factory methods
In-Reply-To: <3d983664-dc0c-9b91-2bb3-6d6bd4c7258a@oracle.com>
References: <193181fd-a6a5-24d1-3bb1-7fec7780468b@oracle.com>
 <ef5734fd-13ae-e478-6ec1-ea9286570b58@oracle.com>
 <3dd3eaee-643c-6d35-151b-7bd932022fe9@oracle.com>
 <3d983664-dc0c-9b91-2bb3-6d6bd4c7258a@oracle.com>
Message-ID: <86de9d15-d023-21a0-2869-5c4dee06cc7e@oracle.com>

On 5/1/2019 11:43 AM, Alan Bateman wrote:
>
>
> On 01/05/2019 17:53, Joe Darcy wrote:
>> :
>>
>> Keeping env to one line also gives a comparably long line length:
>>
>> --- a/src/java.base/share/classes/java/nio/file/FileSystems.java Tue 
>> Apr 30 16:11:42 2019 -0700
>> +++ b/src/java.base/share/classes/java/nio/file/FileSystems.java Wed 
>> May 01 09:50:15 2019 -0700
>> @@ -252,9 +252,7 @@
>> ????? * Suppose there is a provider identified by the scheme {@code 
>> "memory"}
>> ????? * installed:
>> ????? * <pre>
>> -???? *?? Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
>> -???? *?? env.put("capacity", "16G");
>> -???? *?? env.put("blockSize", "4k");
>> +???? *?? Map&lt;String,String&gt; env = Map.of("capacity", "16G", 
>> "blockSize", "4k");
>> ????? *?? FileSystem fs = 
>> FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);
>> ????? * </pre>
>> ????? *
>> The {"capacity", "16G"} and {"blockSize", "4k"} can be put on 
>> different lines to provide a stronger visual hint of grouping.
>>
>> Which of these alternatives do you prefer?
> This looks okay. Brian's suggestion looks good too (I don't want to 
> waste your time on this one).
>
I'd prefer to push a version without the explicit map variable, but the 
max line length is slightly longer:

 ????? * <pre>
-???? *?? Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
-???? *?? env.put("capacity", "16G");
-???? *?? env.put("blockSize", "4k");
-???? *?? FileSystem fs = 
FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);
+???? *? FileSystem fs = 
FileSystems.newFileSystem(URI.create("memory:///?name=logfs"),
+???? * Map.of("capacity", "16G", "blockSize", "4k"));
 ????? * </pre>

-Joe


From lance.andersen at oracle.com  Wed May  1 21:23:55 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 1 May 2019 17:23:55 -0400
Subject: RFR(JDK 13/java.xml) 8220818: Validator does not find missing
 match for keyref error
In-Reply-To: <5CC9CD68.4050803@oracle.com>
References: <5CC9CD68.4050803@oracle.com>
Message-ID: <12BF6380-1138-4517-A549-A57CF7836B5E@oracle.com>

Hi Joe, 

the change looks OK as does the test.

> On May 1, 2019, at 12:46 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Please review a fix for a regression introduced during JDK 9 development. The issue was that a patch ported to the JDK added a counter to count the number of values found in the XML document, and then compared with the constraint's field count. The problem was that the counter would get updated as the validator parsed through the XML document. When the XML contains multiple elements, the counter reflected the last one. If the last one didn't have the problem field, then errors in previous elements wouldn't get reported. The fix is to add a field to indicate whether the field exists in any of the elements.
> 
> All tests and the new test that covers both cases in the original patch and that reported in the JBS passed.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8220818
> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8220818/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 huizhe.wang at oracle.com  Wed May  1 21:29:27 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 01 May 2019 14:29:27 -0700
Subject: RFR(JDK 13/java.xml) 8220818: Validator does not find missing
 match for keyref error
In-Reply-To: <12BF6380-1138-4517-A549-A57CF7836B5E@oracle.com>
References: <5CC9CD68.4050803@oracle.com>
 <12BF6380-1138-4517-A549-A57CF7836B5E@oracle.com>
Message-ID: <5CCA0FB7.1070202@oracle.com>

Thanks Lance!

--Joe

On 5/1/19, 2:23 PM, Lance Andersen wrote:
> Hi Joe,
>
> the change looks OK as does the test.
>
>> On May 1, 2019, at 12:46 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> Please review a fix for a regression introduced during JDK 9 
>> development. The issue was that a patch ported to the JDK added a 
>> counter to count the number of values found in the XML document, and 
>> then compared with the constraint's field count. The problem was that 
>> the counter would get updated as the validator parsed through the XML 
>> document. When the XML contains multiple elements, the counter 
>> reflected the last one. If the last one didn't have the problem 
>> field, then errors in previous elements wouldn't get reported. The 
>> fix is to add a field to indicate whether the field exists in any of 
>> the elements.
>>
>> All tests and the new test that covers both cases in the original 
>> patch and that reported in the JBS passed.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8220818
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8220818/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk13/8220818/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 joe.darcy at oracle.com  Wed May  1 22:47:01 2019
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 01 May 2019 15:47:01 -0700
Subject: RFR: JDK-8219483: j.l.c.ClassDesc::nested(String, String...)
 doesn't throw NPE if any arg is null
In-Reply-To: <f69543af-d683-94e1-236a-54660927f43e@oracle.com>
References: <7b71bdb8-53cb-fdd3-eca4-4e4ba89fe5a4@oracle.com>
 <9b0ea90c-ddca-ab76-caf0-c41e2b56aa2c@oracle.com>
 <042c4118-e6c2-8094-6b8e-d38c519b0196@oracle.com>
 <5CC8C57A.5020906@oracle.com>
 <f69543af-d683-94e1-236a-54660927f43e@oracle.com>
Message-ID: <5CCA21E5.8020103@oracle.com>

Hi Vicente,

Revised version looks good; thanks,

-Joe

On 5/1/2019 1:08 PM, Vicente Romero wrote:
> Hi Joe,
>
> Thanks for the reviews, I have updated the webrev after you suggestion 
> [1],
>
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.02/
>
> On 4/30/19 6:00 PM, Joseph D. Darcy wrote:
>> Hi Vicente,
>>
>> CSR reviewed.
>>
>> I suggesting adding a test case for
>>
>>     cd.nested("good", null)
>>
>> Thanks,
>>
>> -Joe
>>
>> On 4/29/2019 2:41 PM, Vicente Romero wrote:
>>> Hi Joe,
>>>
>>> Thanks for the review. I have modified the patch, please see [1] . I 
>>> still need a reviewer for the CSR [2],
>>>
>>> Vicente
>>>
>>> [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.01/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8223034
>>>
>>>
>>> On 4/26/19 9:32 PM, Joe Darcy wrote:
>>>> Hi Vicente,
>>>>
>>>> For purposes of a better exception message, do you want to 
>>>> explicitly check moreNestedNames for null in some way before 
>>>> accessing its contents? Also, I'd commend the spec be updated 
>>>> slightly to
>>>>
>>>>     @throws NullPointerException if any argument or its contents is 
>>>> {@code null}
>>>>
>>>> assuming the desired behavior is a NPE if an element of 
>>>> moreNestedNames is null as opposed to ust moreNestedNames itself.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>> On 4/26/2019 9:33 AM, Vicente Romero wrote:
>>>>> Hi,
>>>>>
>>>>> Please review fix [1] and CSR [2] for [3]. The API for method 
>>>>> j.l.c.ClassDesc::nested(String, String...) states that it should 
>>>>> throw NPE if any of the arguments is null. The implementation is 
>>>>> not in sync with the API and should be corrected,
>>>>>
>>>>> Thanks,
>>>>> Vicente
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.00/
>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8223034
>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8219483
>>>>>
>>>
>>
>


From kevin.rushforth at oracle.com  Wed May  1 23:17:22 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 1 May 2019 16:17:22 -0700
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
Message-ID: <ed2334bc-c87a-418a-fe3b-387cacdf2d6b@oracle.com>

I got most of the way through the platform-independent Java code today. 
Here is my feedback so far.

NOTE: I don't think any of these need to be addressed prior to 
integration, so you can either fix them in a follow-on webrev or file a 
bug for fixing after integration.

GENERAL:

* Several files (e.g., Arguments.java) have unused imports that can be 
removed. Maybe this can be done along with expanding wild-card imports.


src/jdk.jpackage/share/classes/module-info.java:

* I see that jdk.jpackage requires java.desktop. It looks like this is 
only needed by the Linux installers to get the size of application 
icons. If so, then perhaps this dependency could be moved to 
`linux/classes/module-info.java.extra`?


src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java:

* Should JPackageToolProvider::run log the exception it catches? 
Although normal error handling shouldn't throw exceptions, it might be 
useful.


src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java:

* The following will prefix the version message with "jpackage version "

 ??? private static final String version = bundle.getString("MSG_Version")
 ??????????? + " " + System.getProperty("java.version");

Similar tools such as jlink and jmod don't prefix their output, but 
instead simply print the value of the "java.version" property.


src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/ResourceLocator.java:

* It would be helpful to add a comment to highlight its usage. Also, for 
classes such as this where it is not expected that anyone should create 
an instance, a private constructor might be useful?


src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java:

* The following two constants can be (default) package-scope, since it 
isn't used outside the package (and if it were, the BundlerParamInfo 
class would need to be public in order for it to be useful) :

 ??? public static final BundlerParamInfo<Boolean> CREATE_APP_IMAGE =
 ??? public static final BundlerParamInfo<Boolean> CREATE_INSTALLER =


* The "hasAppImage" field is set but not used (which might be OK, unless 
you meant to use it for argument validation)


src/jdk.jpackage/share/classes/jdk/jpackage/internal/AbstractAppImageBuilder.java:

* This file could use a class comment

* What is the purpose of the following?

 ??? excludeFileList.add(".*\\.diz");

If it really is needed, a comment would be helpful.


* The following on line 195 could use try-with-resources:

 ??????? PrintStream out = new PrintStream(cfgFileName);


src/jdk.jpackage/share/classes/jdk/jpackage/internal/AbstractBundler.java:

* IMAGES_ROOT can be package-scope


src/jdk.jpackage/share/classes/jdk/jpackage/internal/AbstractImageBundler.java:

* Spelling error on line 36

 > or as an intermeadiate step in "create-installer" mode.

should be "intermediate"


* In extractFlagsFromVersion, other than throwing an exception, is there 
a need to pattern match older JDK versions? The minimum that jpackage 
needs to support is JDK 11, so we should be able to assume JEP 322 
compliant version numbers. Might this allow for a simplification?


src/jdk.jpackage/share/classes/jdk/jpackage/internal/BundleParams.java:

* I think the following comment is obsolete, since the support for the 
"JavaFX-Application-Class" jar manifest entry is no longer in jpackage:

 ??? // Note we look for both JavaFX executable jars and regular 
executable jars
 ??? // As long as main "application" entry point is the same it is main 
class
 ??? // (i.e. for FX jar we will use JavaFX manifest entry ...)


-- Kevin


From stuart.marks at oracle.com  Thu May  2 00:39:21 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 1 May 2019 17:39:21 -0700
Subject: RFR(trivial): 8222394: HashMap.compute() throws CME on an empty
 Map if clear() called concurrently
In-Reply-To: <BYAPR01MB50465E819FB106ACABEC8E998F3D0@BYAPR01MB5046.prod.exchangelabs.com>
References: <BL0PR01MB50445D4086CD13A9785367348F280@BL0PR01MB5044.prod.exchangelabs.com>
 <a4fdb034-df89-9d86-2e53-5413048bd637@oracle.com>
 <BYAPR01MB50464E833DF1E9918A8BE9348F2B0@BYAPR01MB5046.prod.exchangelabs.com>
 <520e1ee0-8f1c-ae46-2b45-24555c88aa05@oracle.com>
 <BYAPR01MB50465E819FB106ACABEC8E998F3D0@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <33a11459-830f-07cd-3ee0-743657f6a6b7@oracle.com>


>> ...merely to serve as a discussion point about the policy for throwing 
>> ConcurrentModificationException?

> Yes, for the time being, I want to see and welcome more ideas on this. It 
> seems to me that the policy for throwing CME here is not a unified one, 
> mostly based on experience and testing. Clear, compute, and computeIfAbsent 
> are more special as I described.

OK. For reference, here are some of the words from the
ConcurrentModificationException specification: [1]


> This exception may be thrown by methods that have detected concurrent
> modification of an object when such modification is not permissible.
> 
> For example, it is not generally permissible for one thread to modify a
> Collection while another thread is iterating over it. In general, the results
> of the iteration are undefined under these circumstances. Some Iterator
> implementations (including those of all the general purpose collection
> implementations provided by the JRE) may choose to throw this exception if
> this behavior is detected. Iterators that do this are known as fail-fast
> iterators, as they fail quickly and cleanly, rather that risking arbitrary,
> non-deterministic behavior at an undetermined time in the future.
> 
> Note that this exception does not always indicate that an object has been
> concurrently modified by a different thread. If a single thread issues a
> sequence of method invocations that violates the contract of an object, the
> object may throw this exception. For example, if a thread modifies a
> collection directly while it is iterating over the collection with a
> fail-fast iterator, the iterator will throw this exception.
> 
> Note that fail-fast behavior cannot be guaranteed as it is, generally
> speaking, impossible to make any hard guarantees in the presence of
> unsynchronized concurrent modification. Fail-fast operations throw
> ConcurrentModificationException on a best-effort basis. Therefore, it would
> be wrong to write a program that depended on this exception for its
> correctness: ConcurrentModificationException should be used only to detect
> bugs.

[1] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ConcurrentModificationException.html


Similar words are repeated in several different locations around the
specification, such as in the ArrayList and HashMap class specifications.

I'm not entirely sure what your concerns are with
ConcurrentModificationException (and the "fail-fast" concurrent modification
policy), but let me discuss a few points.

1. throwing of CME is not guaranteed - "best effort"

Unlike most Java specifications, the specification around CME is fairly 
indefinite. The wording is hedged -- "This exception may be thrown...." This 
implies that CME might or might not be thrown, even in cases where one might 
expect it to be.

It also says that CME is thrown on a "best effort" basis. This doesn't mean that 
the library makes the maximum possible effort to throw CME in every possible 
situation. Maybe "best effort" is somewhat misleading. Perhaps "reasonable" 
effort is more descriptive.

For example, ArrayList keeps a modCount field and increments and checks it 
occasionally. No synchronization is done. If the ArrayList is modified by 
another thread, the update to modCount might not be visible to all threads, 
which might result in data corruption instead of a CME.

One way to "fix" this would be to make access to modCount synchronized (or to 
make it volatile, or to make it an AtomicInteger or something) to improve the 
reliability of detecting concurrent modifications from other threads. This would 
add complexity to the code and also slow down common operations. Making this 
extra effort doesn't seem to be worthwhile.

2. throwing CME sometimes done even when not absolutely necessary

Another point is that the detection and throwing of a CME is an approximation of 
when concurrent modification would have any impact. In some cases CME will be 
thrown even when one wouldn't think it strictly necessary.

For example, consider a loop in the middle of iterating an ArrayList. 
ArrayList's iterator simply keeps an index to represent its current position. If 
an element is added to or removed from the front of the list, this would result 
in the iteration skipping or repeating elements. Thus, throwing CME seems 
warranted in this case.

Now consider an iteration in the middle of an ArrayList, and an addition or 
removal is made to the *end* of the list. This doesn't affect the current 
iteration; yet CME is thrown anyway. Why?

To avoid throwing CME in this case (but to throw it in the previous case) the 
ArrayList and its Iterators would have to keep track of more information about 
what changes were made and would have to do more checking at each iteration 
step. This could increase code complexity considerably. Again, this seems like 
it isn't worthwhile. Keeping a simple counter (modCount) and checking it at each 
iteration step is quite cheap, although it arguably does throw CME unnecessarily 
in this case.

Some of the cases you're talking about seem to fall into this category. A CME is 
thrown from compute() if an operation is merely attempted, even if the actual 
operation performed would have no ill effect.

3. state-dependent behavior

I discussed this in a previous message. My personal design style is to try to 
avoid this, although the library isn't wholly consistent in this regard. The 
discussion regarding CME and the compute() and similar methods is also related 
to state-dependent behavior.

4. edge cases

There are a number of edge cases that aren't treated wholly consistently across 
the libraries. Again with ArrayList, consider the following:

         List<Integer> list = new ArrayList<>(List.of(0, 1, 2))
     [0, 1, 2]
         var it = list.iterator()
         it.hasNext()
     true
         it.next()
     0
         it.hasNext()
     true
         it.next()
     1
         list.remove(0)
     0
         it.hasNext()
     false

Arguably, hasNext() should throw CME. If this were in a for-loop, the concurrent 
modification would be missed and the loop would terminate normally. Many 
iterators check for concurrent modification in their next() method but not in 
hasNext(). Perhaps this should be fixed, but it might break code that is 
apparently behaving well today, so we've left it unchanged.

There is also the case of JDK-8114832, where a failed attempt at modification 
will still cause a CME. This is more state-dependent behavior: should modCount 
be incremented when a modification is *attempted* or when modification 
*actually* occurs? (Martin says, "attempted murder is still a crime!")

This bug is still open, though Martin and I agree that no change should be made 
here. It's questionable to me whether we want to go through the old collections 
and update things to be more consistent. The effort is high, the benefit is 
fairly low, in my estimation, and there is a risk of breaking existing code. So 
we live with the inconsistencies.

*******

I'm kind of rambling here. Is this the kind of discussion you're interested in? 
Do you have any specific questions?

s'marks



From ivan.gerasimov at oracle.com  Thu May  2 01:04:29 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 1 May 2019 18:04:29 -0700
Subject: RFR 8223193 : PatternSyntaxException need to truncate lengthy pattern
 strings
Message-ID: <10c41a6c-744a-1d0a-cc52-4d3bc6acc7ee@oracle.com>

Hello!

If an error occurred during regexp pattern compilation, 
PatternSyntaxException.getMessage() can be used to generate a multi-line 
detailed description.  Generally, the description can include a message, 
the pattern, and the index where the error occurred.

If the pattern is too long, then the description becomes hard to read.
It is proposed to limit the length of the pattern in the description by 
80 characters, and truncate it if it is too long.

Here are examples of how the description will look like:


named capturing group <x> does not exist near index 4
\k<x>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[...TRUNCATED]
     ^

named capturing group <x> does not exist near index 105
[TRUNCATED...]aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\k<x>
^

named capturing group <x> does not exist near index 105
[TRUNCATED...]aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\k<x>bbbbbbbbbb
^

named capturing group <x> does not exist near index 105
[TRUNCATED...]aaaaaaaaaaaaaaaaaaaaaa\k<x>bbbbbbbbbbbbbbbbbbbbbbbbb[...TRUNCATED]
                                         ^

Would you please help review the fix?

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

-- 
With kind regards,
Ivan Gerasimov


From claes.redestad at oracle.com  Thu May  2 08:28:34 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 2 May 2019 10:28:34 +0200
Subject: RFR: 8222895: StackOverflowError in custom security manager that
 relies on ClassSpecializer
In-Reply-To: <c1b342d6-8316-8052-1002-b91b84cc6e55@oracle.com>
References: <d8ec15e4-adbe-f342-ba5a-638a5e2d9e8e@oracle.com>
 <c1b342d6-8316-8052-1002-b91b84cc6e55@oracle.com>
Message-ID: <e002aa7d-97e6-85b1-2969-ed164547bb41@oracle.com>

On 2019-05-01 19:00, Alan Bateman wrote:
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8222895/open.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222895
> This looks okay as a temporary solution to fix the regression.

Thanks Alan!

Yes, using the shared secrets API for this is a bit of a hack, and we
should think carefully about how to allow use of APIs that can be
guarded by a SM without risk of running in cycles like this.

We have a related issue[1] that you can't initialize lambdas during
execution of a checkPermission method, which might be a subtle source
for regressions when upgrading (with an increasing risk as more and more
core libraries are lambda and streamified). A similar hack there would
be to elide the (privileged) SM call when the target of the lambda is
a class loaded by the bootloader, but that would only solve for the case
when the offending lambda is something introduced in the core libraries
(like in java.util.regex)

/Claes

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

From andy.herrick at oracle.com  Thu May  2 12:52:54 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 2 May 2019 08:52:54 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <ed2334bc-c87a-418a-fe3b-387cacdf2d6b@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
 <ed2334bc-c87a-418a-fe3b-387cacdf2d6b@oracle.com>
Message-ID: <9ecde5c9-9014-aa69-745f-5c9d976cbc6f@oracle.com>

I filed JDK-8223241 <https://bugs.openjdk.java.net/browse/JDK-8223241> 
to address each of these issues, and included import statement wildcard 
usage as suggested (removing it from JDK-8223189 
<https://bugs.openjdk.java.net/browse/JDK-8223189>)

/Andy


On 5/1/2019 7:17 PM, Kevin Rushforth wrote:
> I got most of the way through the platform-independent Java code 
> today. Here is my feedback so far.
>
> NOTE: I don't think any of these need to be addressed prior to 
> integration, so you can either fix them in a follow-on webrev or file 
> a bug for fixing after integration.
>
> GENERAL:
>
> * Several files (e.g., Arguments.java) have unused imports that can be 
> removed. Maybe this can be done along with expanding wild-card imports.
>
>
> src/jdk.jpackage/share/classes/module-info.java:
>
> * I see that jdk.jpackage requires java.desktop. It looks like this is 
> only needed by the Linux installers to get the size of application 
> icons. If so, then perhaps this dependency could be moved to 
> `linux/classes/module-info.java.extra`?
>
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java: 
>
>
> * Should JPackageToolProvider::run log the exception it catches? 
> Although normal error handling shouldn't throw exceptions, it might be 
> useful.
>
>
> src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java:
>
> * The following will prefix the version message with "jpackage version "
>
> ??? private static final String version = bundle.getString("MSG_Version")
> ??????????? + " " + System.getProperty("java.version");
>
> Similar tools such as jlink and jmod don't prefix their output, but 
> instead simply print the value of the "java.version" property.
>
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/ResourceLocator.java: 
>
>
> * It would be helpful to add a comment to highlight its usage. Also, 
> for classes such as this where it is not expected that anyone should 
> create an instance, a private constructor might be useful?
>
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java:
>
> * The following two constants can be (default) package-scope, since it 
> isn't used outside the package (and if it were, the BundlerParamInfo 
> class would need to be public in order for it to be useful) :
>
> ??? public static final BundlerParamInfo<Boolean> CREATE_APP_IMAGE =
> ??? public static final BundlerParamInfo<Boolean> CREATE_INSTALLER =
>
>
> * The "hasAppImage" field is set but not used (which might be OK, 
> unless you meant to use it for argument validation)
>
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AbstractAppImageBuilder.java: 
>
>
> * This file could use a class comment
>
> * What is the purpose of the following?
>
> ??? excludeFileList.add(".*\\.diz");
>
> If it really is needed, a comment would be helpful.
>
>
> * The following on line 195 could use try-with-resources:
>
> ??????? PrintStream out = new PrintStream(cfgFileName);
>
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AbstractBundler.java: 
>
>
> * IMAGES_ROOT can be package-scope
>
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AbstractImageBundler.java: 
>
>
> * Spelling error on line 36
>
> > or as an intermeadiate step in "create-installer" mode.
>
> should be "intermediate"
>
>
> * In extractFlagsFromVersion, other than throwing an exception, is 
> there a need to pattern match older JDK versions? The minimum that 
> jpackage needs to support is JDK 11, so we should be able to assume 
> JEP 322 compliant version numbers. Might this allow for a simplification?
>
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/BundleParams.java:
>
> * I think the following comment is obsolete, since the support for the 
> "JavaFX-Application-Class" jar manifest entry is no longer in jpackage:
>
> ??? // Note we look for both JavaFX executable jars and regular 
> executable jars
> ??? // As long as main "application" entry point is the same it is 
> main class
> ??? // (i.e. for FX jar we will use JavaFX manifest entry ...)
>
>
> -- Kevin
>


From martinrb at google.com  Thu May  2 14:14:32 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 2 May 2019 07:14:32 -0700
Subject: RFR: jsr166 integration 2019-05
In-Reply-To: <OF788C7A24.AB96BB3C-ON002583EC.0032EF9D-802583EC.0034AE43@notes.na.collabserv.com>
References: <CA+kOe08OewQ+OKF3VoHwUfLDLFmdBL0-yAb2i0e7wXmKVEnAOw@mail.gmail.com>
 <77f82966-5741-3a25-41b9-f2b685957211@oracle.com>
 <OF788C7A24.AB96BB3C-ON002583EC.0032EF9D-802583EC.0034AE43@notes.na.collabserv.com>
Message-ID: <CA+kOe08icw3jp440-9iicBSfqhfMQENcN4w57fr29Y=GDCtNgw@mail.gmail.com>

Changes were pushed (except of course for
203662: remove increment of modCount from ArrayList and Vector replaceAll()

Adam,
Nothing more for you to do here.  I will shepherd the fix for
8222930: ConcurrentSkipListMap.clone() shares size variable between
original and clone
into jdk12u and jdk11u

From adam.farley at uk.ibm.com  Thu May  2 14:28:30 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Thu, 2 May 2019 15:28:30 +0100
Subject: RFR: jsr166 integration 2019-05
In-Reply-To: <CA+kOe08icw3jp440-9iicBSfqhfMQENcN4w57fr29Y=GDCtNgw@mail.gmail.com>
References: <CA+kOe08OewQ+OKF3VoHwUfLDLFmdBL0-yAb2i0e7wXmKVEnAOw@mail.gmail.com>
 <77f82966-5741-3a25-41b9-f2b685957211@oracle.com>
 <OF788C7A24.AB96BB3C-ON002583EC.0032EF9D-802583EC.0034AE43@notes.na.collabserv.com>
 <CA+kOe08icw3jp440-9iicBSfqhfMQENcN4w57fr29Y=GDCtNgw@mail.gmail.com>
Message-ID: <OF2118781E.3B5C2758-ON002583EE.004E606D-802583EE.004F83FA@notes.na.collabserv.com>

Thanks Martin. :)

Best Regards

Adam Farley 
IBM Runtimes


Martin Buchholz <martinrb at google.com> wrote on 02/05/2019 15:14:32:

> From: Martin Buchholz <martinrb at google.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>
> Cc: David Holmes <david.holmes at oracle.com>, Chris Hegarty 
> <chris.hegarty at oracle.com>, core-libs-dev <core-libs-
> dev at openjdk.java.net>, Doug Lea <dl at cs.oswego.edu>, Jonathan Gibbons
> <jonathan.gibbons at oracle.com>
> Date: 02/05/2019 15:14
> Subject: Re: RFR: jsr166 integration 2019-05
> 
> Changes were pushed (except of course for 
> 203662: remove increment of modCount from ArrayList and Vector 
replaceAll()
> 
> Adam,
> Nothing more for you to do here.  I will shepherd the fix for 
> 8222930: ConcurrentSkipListMap.clone() shares size variable between 
> original and clone
> into jdk12u and jdk11u
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From Roger.Riggs at oracle.com  Thu May  2 15:16:30 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 2 May 2019 11:16:30 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
 <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
Message-ID: <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>

Hi,

Some comments, a initial batch...

Having support for the ToolProvider is great.
However, there is no indication about whether it is valid to use it from 
multiple threads.
The implementation is structured to be deliberately single thread use only
with the invocation being via a static method and the logging being via 
static methods.
There will need to be a disclaimer and perhaps an exception should be 
thrown.

A future improvement:
The implementation should be methods on the instance created by the 
ToolProvider
and the logging relative to that instance/delegated where needed.
Main can then be a simple lookup of the tool provider and invoke.

jpackage.main.Main:

 ?- Main.run returns -1, which then is used as exit status, -1 is not 
the usual exit status for a C/Unix main.

65,? the run() method is usually not static and should be re-named to 
avoid confusion

92: Implies something should be logged on a failure.

65: Run (Pw, Pw, args...) doesn't use try ... finally to ensure log is 
flushed.

65: 'throws Exception' implies it can throw an exception but is 
ambiguous as to whether
it returns an error number or throws on what kinds of errors?

91: Ambiguous as to whether processArguments() throws or return false!

CommandLine:
59: Would be more flexible and powerful to use List<String> consistently...

67: use arg.startsWith() for cleaner code.

102: Seems wasteful to parse all the arguments twice.

jdk.jpackage.internal classes:

AbstractAppImageBuilder:
 ?57: The constructor does not need to throw IOException

60:? are .diz files common enough to preemptively exclude (w/o 
documentation)

89: Can the mix of old File API and new Path/Files APIs be avoided?

Adding javadoc to the abstract builder methods will help future maintainers.

203: is a bit more generous than most CLASSPATH parsing and might lead 
to non-obvious bugs.
 ?? For example, a path component with a space in it!

229:? There is no mention of debugging support in JEP 343.
 ? Where is this functionality defined or is it to be identified as 
undocumented internal implementation

Regards, Roger


From alexey.semenyuk at oracle.com  Thu May  2 16:19:59 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 2 May 2019 12:19:59 -0400
Subject: jpackage producing non-working binaries on Windows
In-Reply-To: <alpine.DEB.2.20.1905021206360.19127@urchin.earth.li>
References: <alpine.DEB.2.20.1904301609580.10640@urchin.earth.li>
 <8e66036e-fa7d-586e-fe97-76701952556f@oracle.com>
 <alpine.DEB.2.20.1905021206360.19127@urchin.earth.li>
Message-ID: <d1849f30-0714-0805-b1aa-04c63ab0dc80@oracle.com>

Hi Tom,

Thank for providing a reference to the demo project and build output.

In your example you use jpackage to produce an application image, not an 
exe or msi installers. Just to be clear on the test scenario.

Test app prints "Hello, world!" to stdout as far as I can tell from 
https://github.com/tomwhoiscontrary/jpackage-demo/blob/master/src/main/java/demo/App.java
I think I understand why there is no output when the app is launched by 
executable produced by jpackage. To make stdout and stderr streams work 
as expected Windows application should explicitly allocate a console by 
calling corresponding win api or be linked as console app. None is the 
case with executables produced by jpackage. This looks like a bug.

If you have something like
---
package demo;

import javax.swing.*;

public class App {
 ??? public static void main(String args[]){
 ??????? JFrame frame = new JFrame("My First GUI");
 ??????? frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
 ??????? frame.setSize(300,300);
 ??????? JButton button1 = new JButton("Press");
 ??????? frame.getContentPane().add(button1);
 ??????? frame.setVisible(true);
 ??? }
}
---

in your test app you should see some output though.

- Alexey

On 5/2/2019 7:14 AM, Tom Anderson wrote:
> Hi Alexey,
>
> Here is a demo project:
>
> https://github.com/tomwhoiscontrary/jpackage-demo
>
> If i run this on Windows (Windows 10 in a VM), it produces this output:
>
> https://gist.github.com/tomwhoiscontrary/ee33dda3c124d8a67bd5bba5b8d5e32d
>
> Which includes the following command line:
>
> [create-app-image, --name, demo, --input, 
> C:\Users\IEUser\Downloads\jpackage-demo-master\jpackage-demo-master\build\libs, 
> --output, 
> C:\Users\IEUser\Downloads\jpackage-demo-master\jpackage-demo-master\build/app-image, 
> --main-jar, jpackage-demo.jar]
>
> I should note that i am running the build using JDK 11, then using the 
> early access JDK 13 only to run jpackage at the end.
>
> Regards,
> tom
>
> On Wed, 1 May 2019, Alexey Semenyuk wrote:
>
>> Hi Tom,
>>
>> What is your jpackage command line? Could you please rerun it with 
>> JPACKAGE_DEBUG environment variable set to "true".
>>
>> - Alexey
>>
>> On 4/30/2019 11:15 AM, Tom Anderson wrote:
>>> Hello,
>>>
>>> I am trying out the early-access jpackage tool. It works perfectly 
>>> on Linux, but on Windows produces a binary which does not do 
>>> anything when run.
>>>
>>> I would like to either fix any error i have made, or help you 
>>> identify a bug, if there is one!
>>>
>>> Is this the right place to come with this problem? If not, where 
>>> should i go? Is there a list of known issues other than on the 
>>> download page [1]? What debugging steps should i try? Would a 
>>> self-contained example be helpful to you? What other information 
>>> would you like?
>>>
>>> Regards,
>>> tom
>>>
>>> [1] https://jdk.java.net/jpackage/
>


From cushon at google.com  Thu May  2 16:25:03 2019
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 2 May 2019 09:25:03 -0700
Subject: RFR: 8219202: Use Unsynchronized StringBuilder in
 sun.net.www.ParseUtil
In-Reply-To: <6ACB8C90-F37B-4559-9CE4-DAAF945B87C3@oracle.com>
References: <CAC1Wh8Hd=KYMC6DGVfQm+9_BBOm7hWT8aX324LMevJoQfWhH5w@mail.gmail.com>
 <AE579D6D-2644-4DA3-B71D-5C20C1395BDC@oracle.com>
 <CAC1Wh8E6eWocCfi-y2jnmxz4Zbo9H-sxZC8-NY=BNXq2MqkgRw@mail.gmail.com>
 <6ACB8C90-F37B-4559-9CE4-DAAF945B87C3@oracle.com>
Message-ID: <CAL4Qsgv=cXYQvDWXLY8dN1SSK5N8Mdp1gtCVwDzPKzNXGrMvKA@mail.gmail.com>

Chris, thanks for reviewing.

Alan, I pushed the change as
http://hg.openjdk.java.net/jdk/jdk/rev/96ad739cfc39.

On Wed, May 1, 2019 at 10:25 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Alan,
>
> > On 1 May 2019, at 18:08, Alan Malloy <amalloy at google.com> wrote:
> >
> > It looks to me like Liam, acting as my sponsor, put noreg-cleanup on
> this bug a couple days ago, which seems reasonable to me.
>
> Agreed.
>
> > Do you suggest an additional label?
>
> No. My mistake I missed that there was already a label added.
>
> -Chris.

From kevin.rushforth at oracle.com  Thu May  2 16:25:27 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 2 May 2019 09:25:27 -0700
Subject: jpackage producing non-working binaries on Windows
In-Reply-To: <d1849f30-0714-0805-b1aa-04c63ab0dc80@oracle.com>
References: <alpine.DEB.2.20.1904301609580.10640@urchin.earth.li>
 <8e66036e-fa7d-586e-fe97-76701952556f@oracle.com>
 <alpine.DEB.2.20.1905021206360.19127@urchin.earth.li>
 <d1849f30-0714-0805-b1aa-04c63ab0dc80@oracle.com>
Message-ID: <19062872-2efd-7b7d-b844-6dc43e3fade9@oracle.com>

You need to run jpackage the "--win-console" option in order to get a 
console app. This is intentional and documented.

-- Kevin


On 5/2/2019 9:19 AM, Alexey Semenyuk wrote:
> Hi Tom,
>
> Thank for providing a reference to the demo project and build output.
>
> In your example you use jpackage to produce an application image, not 
> an exe or msi installers. Just to be clear on the test scenario.
>
> Test app prints "Hello, world!" to stdout as far as I can tell from 
> https://github.com/tomwhoiscontrary/jpackage-demo/blob/master/src/main/java/demo/App.java
> I think I understand why there is no output when the app is launched 
> by executable produced by jpackage. To make stdout and stderr streams 
> work as expected Windows application should explicitly allocate a 
> console by calling corresponding win api or be linked as console app. 
> None is the case with executables produced by jpackage. This looks 
> like a bug.
>
> If you have something like
> ---
> package demo;
>
> import javax.swing.*;
>
> public class App {
> ??? public static void main(String args[]){
> ??????? JFrame frame = new JFrame("My First GUI");
> ??????? frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> ??????? frame.setSize(300,300);
> ??????? JButton button1 = new JButton("Press");
> ??????? frame.getContentPane().add(button1);
> ??????? frame.setVisible(true);
> ??? }
> }
> ---
>
> in your test app you should see some output though.
>
> - Alexey
>
> On 5/2/2019 7:14 AM, Tom Anderson wrote:
>> Hi Alexey,
>>
>> Here is a demo project:
>>
>> https://github.com/tomwhoiscontrary/jpackage-demo
>>
>> If i run this on Windows (Windows 10 in a VM), it produces this output:
>>
>> https://gist.github.com/tomwhoiscontrary/ee33dda3c124d8a67bd5bba5b8d5e32d 
>>
>>
>> Which includes the following command line:
>>
>> [create-app-image, --name, demo, --input, 
>> C:\Users\IEUser\Downloads\jpackage-demo-master\jpackage-demo-master\build\libs, 
>> --output, 
>> C:\Users\IEUser\Downloads\jpackage-demo-master\jpackage-demo-master\build/app-image, 
>> --main-jar, jpackage-demo.jar]
>>
>> I should note that i am running the build using JDK 11, then using 
>> the early access JDK 13 only to run jpackage at the end.
>>
>> Regards,
>> tom
>>
>> On Wed, 1 May 2019, Alexey Semenyuk wrote:
>>
>>> Hi Tom,
>>>
>>> What is your jpackage command line? Could you please rerun it with 
>>> JPACKAGE_DEBUG environment variable set to "true".
>>>
>>> - Alexey
>>>
>>> On 4/30/2019 11:15 AM, Tom Anderson wrote:
>>>> Hello,
>>>>
>>>> I am trying out the early-access jpackage tool. It works perfectly 
>>>> on Linux, but on Windows produces a binary which does not do 
>>>> anything when run.
>>>>
>>>> I would like to either fix any error i have made, or help you 
>>>> identify a bug, if there is one!
>>>>
>>>> Is this the right place to come with this problem? If not, where 
>>>> should i go? Is there a list of known issues other than on the 
>>>> download page [1]? What debugging steps should i try? Would a 
>>>> self-contained example be helpful to you? What other information 
>>>> would you like?
>>>>
>>>> Regards,
>>>> tom
>>>>
>>>> [1] https://jdk.java.net/jpackage/
>>
>


From vicente.romero at oracle.com  Thu May  2 12:34:58 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 2 May 2019 08:34:58 -0400
Subject: RFR: JDK-8219483: j.l.c.ClassDesc::nested(String, String...)
 doesn't throw NPE if any arg is null
In-Reply-To: <5CCA21E5.8020103@oracle.com>
References: <7b71bdb8-53cb-fdd3-eca4-4e4ba89fe5a4@oracle.com>
 <9b0ea90c-ddca-ab76-caf0-c41e2b56aa2c@oracle.com>
 <042c4118-e6c2-8094-6b8e-d38c519b0196@oracle.com>
 <5CC8C57A.5020906@oracle.com>
 <f69543af-d683-94e1-236a-54660927f43e@oracle.com>
 <5CCA21E5.8020103@oracle.com>
Message-ID: <fad8ff26-322c-a526-d48a-787abfa583bf@oracle.com>

thanks,

Vicente

On 5/1/19 6:47 PM, Joseph D. Darcy wrote:
> Hi Vicente,
>
> Revised version looks good; thanks,
>
> -Joe
>
> On 5/1/2019 1:08 PM, Vicente Romero wrote:
>> Hi Joe,
>>
>> Thanks for the reviews, I have updated the webrev after you 
>> suggestion [1],
>>
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.02/
>>
>> On 4/30/19 6:00 PM, Joseph D. Darcy wrote:
>>> Hi Vicente,
>>>
>>> CSR reviewed.
>>>
>>> I suggesting adding a test case for
>>>
>>> ??? cd.nested("good", null)
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 4/29/2019 2:41 PM, Vicente Romero wrote:
>>>> Hi Joe,
>>>>
>>>> Thanks for the review. I have modified the patch, please see [1] . 
>>>> I still need a reviewer for the CSR [2],
>>>>
>>>> Vicente
>>>>
>>>> [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.01/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8223034
>>>>
>>>>
>>>> On 4/26/19 9:32 PM, Joe Darcy wrote:
>>>>> Hi Vicente,
>>>>>
>>>>> For purposes of a better exception message, do you want to 
>>>>> explicitly check moreNestedNames for null in some way before 
>>>>> accessing its contents? Also, I'd commend the spec be updated 
>>>>> slightly to
>>>>>
>>>>> ??? @throws NullPointerException if any argument or its contents 
>>>>> is {@code null}
>>>>>
>>>>> assuming the desired behavior is a NPE if an element of 
>>>>> moreNestedNames is null as opposed to ust moreNestedNames itself.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Joe
>>>>>
>>>>> On 4/26/2019 9:33 AM, Vicente Romero wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review fix [1] and CSR [2] for [3]. The API for method 
>>>>>> j.l.c.ClassDesc::nested(String, String...) states that it should 
>>>>>> throw NPE if any of the arguments is null. The implementation is 
>>>>>> not in sync with the API and should be corrected,
>>>>>>
>>>>>> Thanks,
>>>>>> Vicente
>>>>>>
>>>>>> [1] http://cr.openjdk.java.net/~vromero/8219483/webrev.00/
>>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8223034
>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8219483
>>>>>>
>>>>
>>>
>>
>


From semyon.sadetsky at oracle.com  Thu May  2 17:39:53 2019
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Thu, 2 May 2019 10:39:53 -0700
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
Message-ID: <9a4debfd-a171-5285-4e3d-8ec53d575805@oracle.com>

The --mac-app-store-entitlements option was only used for the Mac App 
Store deployment. Since it is not supported anymore this option is not 
used anywhere and need to be removed.

Also the jdk.jpackage.internal. MacAppStoreBundler class and related 
resources are the dead code.

--Semyon

On 4/24/19 5:44 PM, Andy Herrick wrote:
> Please review  changes for [1] which is the implementation bug for 
> JEP-343.
>
> The webrev at [2] is the total cumulative webrev of changes for the 
> jpackage tool, currently in the JDK-8200758-branch branch of the open 
> sandbox repository.
>
> The webrev at [3] shows the changes from EA-05 to EA-06.
>
> The latest EA-6 (build 49) is posted at [4].
>
> Please send feedback to core-libs-dev at openjdk.java.net
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>
> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/
>
> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/
>
> [4] http://jdk.java.net/jpackage/
>
>
> /Andy
>
>


From alexey.semenyuk at oracle.com  Thu May  2 17:49:22 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 2 May 2019 13:49:22 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <5CC4F7E0.7020208@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
Message-ID: <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com>

Some findings:

http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk:
I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and 
BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to 
http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html. 
Reason: these targets don't output executables into images/jdk/bin 
directory. They produce artifacts that stored as resources in jpackage 
just like other targets defined in Lib-jdk.jpackage.gmk.

Wix source code produced by 
http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html 
doesn't comply to recommendations of how files should be packed in 
component. The recommendation is to use one file per a component - 
http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html. 
However jpackage produces way less components than files:
---
$ less config/bundle.wxi | grep '<Component' | wc -w
634

$ less config/bundle.wxi | grep '<File' | wc -w
1650
---
Data picked from my local test project.

http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745
 ???? + " Guid=\"" + UUID.randomUUID().toString() + "\""
Use of random GUIDs for components is not recommended and potentially 
can result in issues with application updates. The recommended approach 
is to generate stable GUIDs - 
http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html, 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html.
Algorithm to create stable GUIDs is explained at 
https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the 
hassle of generating stable GUIDs if we would put only one file in every 
component. In this case WiX is able to generate stable GUIDs for us.

- Alexey

On 4/27/2019 8:46 PM, Philip Race wrote:
> Adding build-dev for the build changes. I don't know if these were 
> previously reviewed there,
> but I am not sure what the changes in NativeCompilation.gmk have to do 
> with jpackage.
>
> -phil.
>
> On 4/24/19, 5:47 PM, Andy Herrick wrote:
>>
>> On 4/24/2019 8:44 PM, Andy Herrick wrote:
>>> Please review? changes for [1] which is the implementation bug for 
>>> JEP-343.
>>>
>>> The webrev at [2] is the total cumulative webrev of changes for the 
>>> jpackage tool, currently in the JDK-8200758-branch branch of the 
>>> open sandbox repository.
>>>
>>> The webrev at [3] shows the changes from EA-05 to EA-06.
>> sorry - the links are reversed from what is stated above. [2] is the 
>> incremental webrev since EA 05, [3] is the cumulativewebrev
>> /Andy
>>>
>>> The latest EA-6 (build 49) is posted at [4].
>>>
>>> Please send feedback to core-libs-dev at openjdk.java.net
>>>
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/
>>>
>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/
>>>
>>> [4] http://jdk.java.net/jpackage/
>>>
>>>
>>> /Andy
>>>
>>>
>>


From twic at urchin.earth.li  Thu May  2 11:14:51 2019
From: twic at urchin.earth.li (Tom Anderson)
Date: Thu, 2 May 2019 12:14:51 +0100 (BST)
Subject: jpackage producing non-working binaries on Windows
In-Reply-To: <8e66036e-fa7d-586e-fe97-76701952556f@oracle.com>
References: <alpine.DEB.2.20.1904301609580.10640@urchin.earth.li>
 <8e66036e-fa7d-586e-fe97-76701952556f@oracle.com>
Message-ID: <alpine.DEB.2.20.1905021206360.19127@urchin.earth.li>

Hi Alexey,

Here is a demo project:

https://github.com/tomwhoiscontrary/jpackage-demo

If i run this on Windows (Windows 10 in a VM), it produces this output:

https://gist.github.com/tomwhoiscontrary/ee33dda3c124d8a67bd5bba5b8d5e32d

Which includes the following command line:

[create-app-image, --name, demo, --input, 
C:\Users\IEUser\Downloads\jpackage-demo-master\jpackage-demo-master\build\libs, 
--output, 
C:\Users\IEUser\Downloads\jpackage-demo-master\jpackage-demo-master\build/app-image, 
--main-jar, jpackage-demo.jar]

I should note that i am running the build using JDK 11, then using the 
early access JDK 13 only to run jpackage at the end.

Regards,
tom

On Wed, 1 May 2019, Alexey Semenyuk wrote:

> Hi Tom,
>
> What is your jpackage command line? Could you please rerun it with 
> JPACKAGE_DEBUG environment variable set to "true".
>
> - Alexey
>
> On 4/30/2019 11:15 AM, Tom Anderson wrote:
>> Hello,
>> 
>> I am trying out the early-access jpackage tool. It works perfectly on 
>> Linux, but on Windows produces a binary which does not do anything when 
>> run.
>> 
>> I would like to either fix any error i have made, or help you identify a 
>> bug, if there is one!
>> 
>> Is this the right place to come with this problem? If not, where should i 
>> go? Is there a list of known issues other than on the download page [1]? 
>> What debugging steps should i try? Would a self-contained example be 
>> helpful to you? What other information would you like?
>> 
>> Regards,
>> tom
>> 
>> [1] https://jdk.java.net/jpackage/

-- 
A weed is just a plant that's in the wrong place. -- Jane Anderson

From philip.race at oracle.com  Thu May  2 18:25:33 2019
From: philip.race at oracle.com (Phil Race)
Date: Thu, 2 May 2019 11:25:33 -0700
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
 <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
 <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
Message-ID: <e918c5f8-c385-a553-f3cf-e4965381b43a@oracle.com>

Although our build system doesn't complain, my local Linux gcc generates 
several
warnings which prevent jpackage from building. The attached patch makes 
it happy.


There are several of these :-

jpackage/open/src/jdk.jpackage/share/native/libapplauncher/IniFile.cpp: 
In member function ?virtual bool IniFile::GetSection(TString, 
OrderedMap<std::__cxx11::basic_string<char>, 
std::__cxx11::basic_string<char> >&)?:
/home/prrace/jpackage/open/src/jdk.jpackage/share/native/libapplauncher/IniFile.cpp:192:25: 
error: ?section? may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
 ???????? IniSectionData* section;

A couple of complains about not checking the return value of chdir. My 
patch throws an exception
which I think is better than ignoring it and using the wrong directory.
jpackage/open/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp: 
In member function ?virtual void 
LinuxPlatform::SetCurrentDirectory(TString)?:
/home/prrace/jpackage/open/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp:129:52: 
error: ignoring return value of ?int chdir(const char*)?, declared with 
attribute warn_unused_result [-Werror=unused-result]
 ???? chdir(PlatformString(Value).toPlatformString());

 ??????????????????????????????????????????????????? ^

And this :
jpackage/open/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp: 
In member function ?virtual void PosixProcess::SetInput(TString)?:
/home/prrace/jpackage/open/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp:313:56: 
error: ignoring return value of ?ssize_t write(int, const void*, 
size_t)?, declared with attribute warn_unused_result [-Werror=unused-result]
 ???????? write(FInputHandle, Value.data(), Value.size());
 ??????????????????????????????????????????????????????? ^
cc1plus: all warnings being treated as errors


-phil.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc.patch
Type: text/x-patch
Size: 2895 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20190502/2a40ee53/gcc.patch>

From brian.burkhalter at oracle.com  Thu May  2 19:24:05 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 May 2019 12:24:05 -0700
Subject: 8223254: DataOutputStream/WriteUTF.java fails due to
 "OutOfMemoryError: Java heap space"
Message-ID: <F8AD31EC-96F4-4686-9214-DE959355997F@oracle.com>

It looks like the memory bump in [1, 2] was not enough. This patch [3] would add 1GB to the required Java heap size.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8221568
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059355.html
[3] patch

--- a/test/jdk/java/io/DataOutputStream/WriteUTF.java
+++ b/test/jdk/java/io/DataOutputStream/WriteUTF.java
@@ -22,10 +22,10 @@
  */
 
 /* @test
- * @bug 4260284 8219196
+ * @bug 4260284 8219196 8223254
  * @summary Test if DataOutputStream will overcount written field.
- * @requires (sun.arch.data.model == "64" & os.maxMemory >= 3g)
- * @run testng/othervm -Xmx3g WriteUTF
+ * @requires (sun.arch.data.model == "64" & os.maxMemory >= 4g)
+ * @run testng/othervm -Xmx4g WriteUTF
  */
 
 import java.io.ByteArrayOutputStream;
@@ -60,7 +60,7 @@
     }
 
     // Without 8219196 fix, throws ArrayIndexOutOfBoundsException instead of
-    // expected UTFDataFormatException. Requires 3GB of heap (-Xmx3g) to run
+    // expected UTFDataFormatException. Requires 4GB of heap (-Xmx4g) to run
     // without throwing an OutOfMemoryError.
     @Test(expectedExceptions = UTFDataFormatException.class)
     public void arrayIndexOutOfBoundsException() throws IOException {


From Roger.Riggs at oracle.com  Thu May  2 19:42:34 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 2 May 2019 15:42:34 -0400
Subject: 8223254: DataOutputStream/WriteUTF.java fails due to
 "OutOfMemoryError: Java heap space"
In-Reply-To: <F8AD31EC-96F4-4686-9214-DE959355997F@oracle.com>
References: <F8AD31EC-96F4-4686-9214-DE959355997F@oracle.com>
Message-ID: <d7235451-ea65-573d-47df-e24ec0b376d1@oracle.com>

ok,? +1

On 05/02/2019 03:24 PM, Brian Burkhalter wrote:
> It looks like the memory bump in [1, 2] was not enough. This patch [3] would add 1GB to the required Java heap size.
>
> Thanks,
>
> Brian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8221568
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059355.html
> [3] patch
>
> --- a/test/jdk/java/io/DataOutputStream/WriteUTF.java
> +++ b/test/jdk/java/io/DataOutputStream/WriteUTF.java
> @@ -22,10 +22,10 @@
>    */
>   
>   /* @test
> - * @bug 4260284 8219196
> + * @bug 4260284 8219196 8223254
>    * @summary Test if DataOutputStream will overcount written field.
> - * @requires (sun.arch.data.model == "64" & os.maxMemory >= 3g)
> - * @run testng/othervm -Xmx3g WriteUTF
> + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 4g)
> + * @run testng/othervm -Xmx4g WriteUTF
>    */
>   
>   import java.io.ByteArrayOutputStream;
> @@ -60,7 +60,7 @@
>       }
>   
>       // Without 8219196 fix, throws ArrayIndexOutOfBoundsException instead of
> -    // expected UTFDataFormatException. Requires 3GB of heap (-Xmx3g) to run
> +    // expected UTFDataFormatException. Requires 4GB of heap (-Xmx4g) to run
>       // without throwing an OutOfMemoryError.
>       @Test(expectedExceptions = UTFDataFormatException.class)
>       public void arrayIndexOutOfBoundsException() throws IOException {
>


From lance.andersen at oracle.com  Thu May  2 19:45:44 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 2 May 2019 15:45:44 -0400
Subject: 8223254: DataOutputStream/WriteUTF.java fails due to
 "OutOfMemoryError: Java heap space"
In-Reply-To: <F8AD31EC-96F4-4686-9214-DE959355997F@oracle.com>
References: <F8AD31EC-96F4-4686-9214-DE959355997F@oracle.com>
Message-ID: <2D5C7204-E8EC-4270-A9A5-90AE88933C73@oracle.com>

+1 2nd time is a charm :-)
> On May 2, 2019, at 3:24 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> It looks like the memory bump in [1, 2] was not enough. This patch [3] would add 1GB to the required Java heap size.
> 
> Thanks,
> 
> Brian
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8221568
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059355.html
> [3] patch
> 
> --- a/test/jdk/java/io/DataOutputStream/WriteUTF.java
> +++ b/test/jdk/java/io/DataOutputStream/WriteUTF.java
> @@ -22,10 +22,10 @@
>  */
> 
> /* @test
> - * @bug 4260284 8219196
> + * @bug 4260284 8219196 8223254
>  * @summary Test if DataOutputStream will overcount written field.
> - * @requires (sun.arch.data.model == "64" & os.maxMemory >= 3g)
> - * @run testng/othervm -Xmx3g WriteUTF
> + * @requires (sun.arch.data.model == "64" & os.maxMemory >= 4g)
> + * @run testng/othervm -Xmx4g WriteUTF
>  */
> 
> import java.io.ByteArrayOutputStream;
> @@ -60,7 +60,7 @@
>     }
> 
>     // Without 8219196 fix, throws ArrayIndexOutOfBoundsException instead of
> -    // expected UTFDataFormatException. Requires 3GB of heap (-Xmx3g) to run
> +    // expected UTFDataFormatException. Requires 4GB of heap (-Xmx4g) to run
>     // without throwing an OutOfMemoryError.
>     @Test(expectedExceptions = UTFDataFormatException.class)
>     public void arrayIndexOutOfBoundsException() throws IOException {
> 

 <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 andy.herrick at oracle.com  Thu May  2 20:27:19 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 2 May 2019 16:27:19 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <9a4debfd-a171-5285-4e3d-8ec53d575805@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <9a4debfd-a171-5285-4e3d-8ec53d575805@oracle.com>
Message-ID: <a0a26487-c3da-8fa2-4b79-8e0fc24cf1ae@oracle.com>

Semyon:

Although we removed --mac-app-store-entitlements and 
--mac-app-store-category options from help text, and disabled the 
mac-app-store target (so these two options have no effect) when we 
decided to drop support for this in the the initial release, we never 
actually removed the options, or the (now dead) code behind them.? At 
the very least we should have removed them from ValidOptions, but it 
will be cleaner to remove them entirely.

Please file a bug to address this.

/Andy




On 5/2/2019 1:39 PM, semyon.sadetsky at oracle.com wrote:
> The --mac-app-store-entitlements option was only used for the Mac App 
> Store deployment. Since it is not supported anymore this option is not 
> used anywhere and need to be removed.
>
> Also the jdk.jpackage.internal. MacAppStoreBundler class and related 
> resources are the dead code.
>
> --Semyon
>
> On 4/24/19 5:44 PM, Andy Herrick wrote:
>> Please review? changes for [1] which is the implementation bug for 
>> JEP-343.
>>
>> The webrev at [2] is the total cumulative webrev of changes for the 
>> jpackage tool, currently in the JDK-8200758-branch branch of the open 
>> sandbox repository.
>>
>> The webrev at [3] shows the changes from EA-05 to EA-06.
>>
>> The latest EA-6 (build 49) is posted at [4].
>>
>> Please send feedback to core-libs-dev at openjdk.java.net
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>>
>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/
>>
>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/
>>
>> [4] http://jdk.java.net/jpackage/
>>
>>
>> /Andy
>>
>>
>


From andy.herrick at oracle.com  Thu May  2 20:34:19 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 2 May 2019 16:34:19 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <e918c5f8-c385-a553-f3cf-e4965381b43a@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
 <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
 <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
 <e918c5f8-c385-a553-f3cf-e4965381b43a@oracle.com>
Message-ID: <0f9976a1-c0ba-50b6-1d9f-88cdaec8da40@oracle.com>

JDK-8223264 <https://bugs.openjdk.java.net/browse/JDK-8223264> has been 
filed to address this.

/Andy


On 5/2/2019 2:25 PM, Phil Race wrote:
> Although our build system doesn't complain, my local Linux gcc 
> generates several
> warnings which prevent jpackage from building. The attached patch 
> makes it happy.
>
>
> There are several of these :-
>
> jpackage/open/src/jdk.jpackage/share/native/libapplauncher/IniFile.cpp: 
> In member function ?virtual bool IniFile::GetSection(TString, 
> OrderedMap<std::__cxx11::basic_string<char>, 
> std::__cxx11::basic_string<char> >&)?:
> /home/prrace/jpackage/open/src/jdk.jpackage/share/native/libapplauncher/IniFile.cpp:192:25: 
> error: ?section? may be used uninitialized in this function 
> [-Werror=maybe-uninitialized]
> ???????? IniSectionData* section;
>
> A couple of complains about not checking the return value of chdir. My 
> patch throws an exception
> which I think is better than ignoring it and using the wrong directory.
> jpackage/open/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp: 
> In member function ?virtual void 
> LinuxPlatform::SetCurrentDirectory(TString)?:
> /home/prrace/jpackage/open/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp:129:52: 
> error: ignoring return value of ?int chdir(const char*)?, declared 
> with attribute warn_unused_result [-Werror=unused-result]
> ???? chdir(PlatformString(Value).toPlatformString());
>
> ??????????????????????????????????????????????????? ^
>
> And this :
> jpackage/open/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp: 
> In member function ?virtual void PosixProcess::SetInput(TString)?:
> /home/prrace/jpackage/open/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp:313:56: 
> error: ignoring return value of ?ssize_t write(int, const void*, 
> size_t)?, declared with attribute warn_unused_result 
> [-Werror=unused-result]
> ???????? write(FInputHandle, Value.data(), Value.size());
> ??????????????????????????????????????????????????????? ^
> cc1plus: all warnings being treated as errors
>
>
> -phil.


From andy.herrick at oracle.com  Thu May  2 21:08:25 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 2 May 2019 17:08:25 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com>
Message-ID: <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com>

Alexey:

Please file Bugs for these two issues.

/Andy


On 5/2/2019 1:49 PM, Alexey Semenyuk wrote:
> Some findings:
>
> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: 
>
> I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and 
> BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to 
> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html. 
> Reason: these targets don't output executables into images/jdk/bin 
> directory. They produce artifacts that stored as resources in jpackage 
> just like other targets defined in Lib-jdk.jpackage.gmk.
>
> Wix source code produced by 
> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html 
> doesn't comply to recommendations of how files should be packed in 
> component. The recommendation is to use one file per a component - 
> http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html. 
> However jpackage produces way less components than files:
> ---
> $ less config/bundle.wxi | grep '<Component' | wc -w
> 634
>
> $ less config/bundle.wxi | grep '<File' | wc -w
> 1650
> ---
> Data picked from my local test project.
>
> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745 
>
> ???? + " Guid=\"" + UUID.randomUUID().toString() + "\""
> Use of random GUIDs for components is not recommended and potentially 
> can result in issues with application updates. The recommended 
> approach is to generate stable GUIDs - 
> http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html, 
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html. 
>
> Algorithm to create stable GUIDs is explained at 
> https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the 
> hassle of generating stable GUIDs if we would put only one file in 
> every component. In this case WiX is able to generate stable GUIDs for 
> us.
>
> - Alexey
>
> On 4/27/2019 8:46 PM, Philip Race wrote:
>> Adding build-dev for the build changes. I don't know if these were 
>> previously reviewed there,
>> but I am not sure what the changes in NativeCompilation.gmk have to 
>> do with jpackage.
>>
>> -phil.
>>
>> On 4/24/19, 5:47 PM, Andy Herrick wrote:
>>>
>>> On 4/24/2019 8:44 PM, Andy Herrick wrote:
>>>> Please review? changes for [1] which is the implementation bug for 
>>>> JEP-343.
>>>>
>>>> The webrev at [2] is the total cumulative webrev of changes for the 
>>>> jpackage tool, currently in the JDK-8200758-branch branch of the 
>>>> open sandbox repository.
>>>>
>>>> The webrev at [3] shows the changes from EA-05 to EA-06.
>>> sorry - the links are reversed from what is stated above. [2] is the 
>>> incremental webrev since EA 05, [3] is the cumulativewebrev
>>> /Andy
>>>>
>>>> The latest EA-6 (build 49) is posted at [4].
>>>>
>>>> Please send feedback to core-libs-dev at openjdk.java.net
>>>>
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>>>>
>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/
>>>>
>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/
>>>>
>>>> [4] http://jdk.java.net/jpackage/
>>>>
>>>>
>>>> /Andy
>>>>
>>>>
>>>
>


From joe.darcy at oracle.com  Thu May  2 21:42:01 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 2 May 2019 14:42:01 -0700
Subject: JDK 13 RFR of JDK-8223112: Clarify operational semantics of
 java.util.Objects.equals()
Message-ID: <8e9f4850-6ef9-7cfa-b846-e05ec48107a8@oracle.com>

Hello,

Bug JDK-8223112 notes indirectly that if Objects.equals is called with 
(foo, null) and foo has a buggy equals method that returns true for 
null, the wrong result will be computed.

I don't think code should be added to Objects.equals itself to guard 
against this case. Instead, I think the operational semantics of the 
implementation should be made explicit in the specification.

Please review the patch below.

Thanks,

-Joe

diff -r 7ab4310ed472 src/java.base/share/classes/java/util/Objects.java
--- a/src/java.base/share/classes/java/util/Objects.java??? Wed May 01 
20:25:31 2019 -0700
+++ b/src/java.base/share/classes/java/util/Objects.java??? Thu May 02 
14:41:06 2019 -0700
@@ -62,10 +62,11 @@
 ????? * Returns {@code true} if the arguments are equal to each other
 ????? * and {@code false} otherwise.
 ????? * Consequently, if both arguments are {@code null}, {@code true}
-???? * is returned and if exactly one argument is {@code null}, {@code
-???? * false} is returned.? Otherwise, equality is determined by using
-???? * the {@link Object#equals equals} method of the first
-???? * argument.
+???? * is returned.? Otherwise, if the first argument is not {@code
+???? * null}, equality is determined by calling the {@link
+???? * Object#equals equals} method of the first argument with the
+???? * second argument of this method. Otherwise, {@code false} is
+???? * returned.
 ????? *
 ????? * @param a an object
 ????? * @param b an object to be compared with {@code a} for equality

...

 ??? public static boolean equals(Object a, Object b) {
 ??????? return (a == b) || (a != null && a.equals(b));
 ??? }


From brian.burkhalter at oracle.com  Thu May  2 21:58:00 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 May 2019 14:58:00 -0700
Subject: JDK 13 RFR of JDK-8223112: Clarify operational semantics of
 java.util.Objects.equals()
In-Reply-To: <8e9f4850-6ef9-7cfa-b846-e05ec48107a8@oracle.com>
References: <8e9f4850-6ef9-7cfa-b846-e05ec48107a8@oracle.com>
Message-ID: <1259FCAC-49FC-407D-9B5D-621E3E2E4A1F@oracle.com>

Hi Joe,

Looks good.

Brian

> On May 2, 2019, at 2:42 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Bug JDK-8223112 notes indirectly that if Objects.equals is called with (foo, null) and foo has a buggy equals method that returns true for null, the wrong result will be computed.
> 
> I don't think code should be added to Objects.equals itself to guard against this case. Instead, I think the operational semantics of the implementation should be made explicit in the specification.
> 
> Please review the patch below.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 7ab4310ed472 src/java.base/share/classes/java/util/Objects.java
> --- a/src/java.base/share/classes/java/util/Objects.java    Wed May 01 20:25:31 2019 -0700
> +++ b/src/java.base/share/classes/java/util/Objects.java    Thu May 02 14:41:06 2019 -0700
> @@ -62,10 +62,11 @@
>       * Returns {@code true} if the arguments are equal to each other
>       * and {@code false} otherwise.
>       * Consequently, if both arguments are {@code null}, {@code true}
> -     * is returned and if exactly one argument is {@code null}, {@code
> -     * false} is returned.  Otherwise, equality is determined by using
> -     * the {@link Object#equals equals} method of the first
> -     * argument.
> +     * is returned.  Otherwise, if the first argument is not {@code
> +     * null}, equality is determined by calling the {@link
> +     * Object#equals equals} method of the first argument with the
> +     * second argument of this method. Otherwise, {@code false} is
> +     * returned.


From joe.darcy at oracle.com  Thu May  2 22:44:24 2019
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 02 May 2019 15:44:24 -0700
Subject: JDK 13 RFR of JDK-8223112: Clarify operational semantics of
 java.util.Objects.equals()
In-Reply-To: <8e9f4850-6ef9-7cfa-b846-e05ec48107a8@oracle.com>
References: <8e9f4850-6ef9-7cfa-b846-e05ec48107a8@oracle.com>
Message-ID: <5CCB72C8.90907@oracle.com>

PS Please also review the CSR

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

Note that the particular implementation used in Objects.equals was 
recommended in its initial code review back in 2009:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-September/002580.html

Thanks,

-Joe

On 5/2/2019 2:42 PM, Joe Darcy wrote:
> Hello,
>
> Bug JDK-8223112 notes indirectly that if Objects.equals is called with 
> (foo, null) and foo has a buggy equals method that returns true for 
> null, the wrong result will be computed.
>
> I don't think code should be added to Objects.equals itself to guard 
> against this case. Instead, I think the operational semantics of the 
> implementation should be made explicit in the specification.
>
> Please review the patch below.
>
> Thanks,
>
> -Joe
>
> diff -r 7ab4310ed472 src/java.base/share/classes/java/util/Objects.java
> --- a/src/java.base/share/classes/java/util/Objects.java    Wed May 01 
> 20:25:31 2019 -0700
> +++ b/src/java.base/share/classes/java/util/Objects.java    Thu May 02 
> 14:41:06 2019 -0700
> @@ -62,10 +62,11 @@
>       * Returns {@code true} if the arguments are equal to each other
>       * and {@code false} otherwise.
>       * Consequently, if both arguments are {@code null}, {@code true}
> -     * is returned and if exactly one argument is {@code null}, {@code
> -     * false} is returned.  Otherwise, equality is determined by using
> -     * the {@link Object#equals equals} method of the first
> -     * argument.
> +     * is returned.  Otherwise, if the first argument is not {@code
> +     * null}, equality is determined by calling the {@link
> +     * Object#equals equals} method of the first argument with the
> +     * second argument of this method. Otherwise, {@code false} is
> +     * returned.
>       *
>       * @param a an object
>       * @param b an object to be compared with {@code a} for equality
>
> ...
>
>     public static boolean equals(Object a, Object b) {
>         return (a == b) || (a != null && a.equals(b));
>     }
>


From kevin.rushforth at oracle.com  Fri May  3 00:38:31 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 2 May 2019 17:38:31 -0700
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <ed2334bc-c87a-418a-fe3b-387cacdf2d6b@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
 <ed2334bc-c87a-418a-fe3b-387cacdf2d6b@oracle.com>
Message-ID: <93e05dcc-2497-f5aa-fa02-73184476cc19@oracle.com>

Here are a few follow-on comments. As with my earlier comments, none of 
these need to be addressed prior to integration.


1. I found a few more classes that do I/O and could benefit from using 
try-with-resources:
 ?? IOUtils, LinuxAppImageBuilder, LinuxDebBundler, LinuxRpmBundler, 
MacAppImageBuilder, etc.


JLinkBundlerHelper.java:

2. JRE_MODULES_FILENAME and SERVER_JRE_MODULES_FILENAME are unused 
(obsolete) and should be removed.


VersionExtractor.java:

3. The isLessThan method only looks at MAJOR.MINOR so might not be 
flexible enough for some applications


LinuxAppBundler.java:

3. Several places where non-public (package-scope) API is exported 
publicly; these should all be package-scope itself or else 
BundlerParamInfo should be public



LinuxAppImageBuilder.java:

3. createUtf8File is unused (I went looking because I was curious how 
and why we would use such a method). I see similarly-unused methods of 
the same name in the Mac and Windows AppImageBuilder classes.


MacAppImageBuilder.java:

4. Line 818: is the following still needed?

 ??????????????????????? || p.toString().contains(
 ??????????????????????????????? "/Contents/MacOS/JavaAppletPlugin")


WindowsDefender.java + WindowsRegistry.java:

5. Is the check and warning for Windows Defender really needed? Have we 
seen problems as a result of it running while jpackage is building an 
app installer?

-- Kevin


From swpalmer at gmail.com  Fri May  3 00:54:49 2019
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 2 May 2019 20:54:49 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com>
 <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com>
Message-ID: <43E836D1-908F-426B-A4BB-6CD1A413A7B2@gmail.com>

Ideally the wix code should be generated by running the heat.exe tool on the application image.

Scott

> On May 2, 2019, at 5:08 PM, Andy Herrick <andy.herrick at oracle.com> wrote:
> 
> Alexey:
> 
> Please file Bugs for these two issues.
> 
> /Andy
> 
> 
>> On 5/2/2019 1:49 PM, Alexey Semenyuk wrote:
>> Some findings:
>> 
>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: 
>> I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html. Reason: these targets don't output executables into images/jdk/bin directory. They produce artifacts that stored as resources in jpackage just like other targets defined in Lib-jdk.jpackage.gmk.
>> 
>> Wix source code produced by http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html doesn't comply to recommendations of how files should be packed in component. The recommendation is to use one file per a component - http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html. However jpackage produces way less components than files:
>> ---
>> $ less config/bundle.wxi | grep '<Component' | wc -w
>> 634
>> 
>> $ less config/bundle.wxi | grep '<File' | wc -w
>> 1650
>> ---
>> Data picked from my local test project.
>> 
>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745 
>>      + " Guid=\"" + UUID.randomUUID().toString() + "\""
>> Use of random GUIDs for components is not recommended and potentially can result in issues with application updates. The recommended approach is to generate stable GUIDs - http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html, http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html. 
>> Algorithm to create stable GUIDs is explained at https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the hassle of generating stable GUIDs if we would put only one file in every component. In this case WiX is able to generate stable GUIDs for us.
>> 
>> - Alexey
>> 
>>> On 4/27/2019 8:46 PM, Philip Race wrote:
>>> Adding build-dev for the build changes. I don't know if these were previously reviewed there,
>>> but I am not sure what the changes in NativeCompilation.gmk have to do with jpackage.
>>> 
>>> -phil.
>>> 
>>>> On 4/24/19, 5:47 PM, Andy Herrick wrote:
>>>> 
>>>>> On 4/24/2019 8:44 PM, Andy Herrick wrote:
>>>>> Please review  changes for [1] which is the implementation bug for JEP-343.
>>>>> 
>>>>> The webrev at [2] is the total cumulative webrev of changes for the jpackage tool, currently in the JDK-8200758-branch branch of the open sandbox repository.
>>>>> 
>>>>> The webrev at [3] shows the changes from EA-05 to EA-06.
>>>> sorry - the links are reversed from what is stated above. [2] is the incremental webrev since EA 05, [3] is the cumulativewebrev
>>>> /Andy
>>>>> 
>>>>> The latest EA-6 (build 49) is posted at [4].
>>>>> 
>>>>> Please send feedback to core-libs-dev at openjdk.java.net
>>>>> 
>>>>> 
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>>>>> 
>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/
>>>>> 
>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/
>>>>> 
>>>>> [4] http://jdk.java.net/jpackage/
>>>>> 
>>>>> 
>>>>> /Andy
>>>>> 
>>>>> 
>>>> 
>> 
> 

From twic at urchin.earth.li  Thu May  2 20:02:09 2019
From: twic at urchin.earth.li (Tom Anderson)
Date: Thu, 2 May 2019 21:02:09 +0100 (BST)
Subject: jpackage producing non-working binaries on Windows
In-Reply-To: <19062872-2efd-7b7d-b844-6dc43e3fade9@oracle.com>
References: <alpine.DEB.2.20.1904301609580.10640@urchin.earth.li>
 <8e66036e-fa7d-586e-fe97-76701952556f@oracle.com>
 <alpine.DEB.2.20.1905021206360.19127@urchin.earth.li>
 <d1849f30-0714-0805-b1aa-04c63ab0dc80@oracle.com>
 <19062872-2efd-7b7d-b844-6dc43e3fade9@oracle.com>
Message-ID: <alpine.DEB.2.20.1905022052490.19127@urchin.earth.li>

Hi Kevin,

Aha! That explains it, and yes, adding that flag fixes the issue. Thanks!

The only documentation i have seen is this:

https://openjdk.java.net/jeps/343

And while that does mention this flag, the mention is deep in the section 
describing all the flags, which i have to confess i did not read in 
detail. When jpackage graduates to a production JDK, i would encourage 
that option to be given a bit more prominence.

Regards,
tom

On Thu, 2 May 2019, Kevin Rushforth wrote:

> You need to run jpackage the "--win-console" option in order to get a console 
> app. This is intentional and documented.
>
> -- Kevin
>
>
> On 5/2/2019 9:19 AM, Alexey Semenyuk wrote:
>> Hi Tom,
>> 
>> Thank for providing a reference to the demo project and build output.
>> 
>> In your example you use jpackage to produce an application image, not an 
>> exe or msi installers. Just to be clear on the test scenario.
>> 
>> Test app prints "Hello, world!" to stdout as far as I can tell from 
>> https://github.com/tomwhoiscontrary/jpackage-demo/blob/master/src/main/java/demo/App.java
>> I think I understand why there is no output when the app is launched by 
>> executable produced by jpackage. To make stdout and stderr streams work as 
>> expected Windows application should explicitly allocate a console by 
>> calling corresponding win api or be linked as console app. None is the case 
>> with executables produced by jpackage. This looks like a bug.
>> 
>> If you have something like
>> ---
>> package demo;
>> 
>> import javax.swing.*;
>> 
>> public class App {
>> ??? public static void main(String args[]){
>> ??????? JFrame frame = new JFrame("My First GUI");
>> ??????? frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>> ??????? frame.setSize(300,300);
>> ??????? JButton button1 = new JButton("Press");
>> ??????? frame.getContentPane().add(button1);
>> ??????? frame.setVisible(true);
>> ??? }
>> }
>> ---
>> 
>> in your test app you should see some output though.
>> 
>> - Alexey
>> 
>> On 5/2/2019 7:14 AM, Tom Anderson wrote:
>>> Hi Alexey,
>>> 
>>> Here is a demo project:
>>> 
>>> https://github.com/tomwhoiscontrary/jpackage-demo
>>> 
>>> If i run this on Windows (Windows 10 in a VM), it produces this output:
>>> 
>>> https://gist.github.com/tomwhoiscontrary/ee33dda3c124d8a67bd5bba5b8d5e32d 
>>> 
>>> Which includes the following command line:
>>> 
>>> [create-app-image, --name, demo, --input, 
>>> C:\Users\IEUser\Downloads\jpackage-demo-master\jpackage-demo-master\build\libs, 
>>> --output, 
>>> C:\Users\IEUser\Downloads\jpackage-demo-master\jpackage-demo-master\build/app-image, 
>>> --main-jar, jpackage-demo.jar]
>>> 
>>> I should note that i am running the build using JDK 11, then using the 
>>> early access JDK 13 only to run jpackage at the end.
>>> 
>>> Regards,
>>> tom
>>> 
>>> On Wed, 1 May 2019, Alexey Semenyuk wrote:
>>> 
>>>> Hi Tom,
>>>> 
>>>> What is your jpackage command line? Could you please rerun it with 
>>>> JPACKAGE_DEBUG environment variable set to "true".
>>>> 
>>>> - Alexey
>>>> 
>>>> On 4/30/2019 11:15 AM, Tom Anderson wrote:
>>>>> Hello,
>>>>> 
>>>>> I am trying out the early-access jpackage tool. It works perfectly on 
>>>>> Linux, but on Windows produces a binary which does not do anything when 
>>>>> run.
>>>>> 
>>>>> I would like to either fix any error i have made, or help you identify a 
>>>>> bug, if there is one!
>>>>> 
>>>>> Is this the right place to come with this problem? If not, where should 
>>>>> i go? Is there a list of known issues other than on the download page 
>>>>> [1]? What debugging steps should i try? Would a self-contained example 
>>>>> be helpful to you? What other information would you like?
>>>>> 
>>>>> Regards,
>>>>> tom
>>>>> 
>>>>> [1] https://jdk.java.net/jpackage/

From alexander.matveev at oracle.com  Fri May  3 01:33:45 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 2 May 2019 18:33:45 -0700
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <93e05dcc-2497-f5aa-fa02-73184476cc19@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
 <ed2334bc-c87a-418a-fe3b-387cacdf2d6b@oracle.com>
 <93e05dcc-2497-f5aa-fa02-73184476cc19@oracle.com>
Message-ID: <bce04dec-7334-8f33-9aa0-e7fb7babc3d1@oracle.com>

Hi Kevin,

See below.

On 5/2/2019 5:38 PM, Kevin Rushforth wrote:
> Here are a few follow-on comments. As with my earlier comments, none 
> of these need to be addressed prior to integration.
>
>
> 1. I found a few more classes that do I/O and could benefit from using 
> try-with-resources:
> ?? IOUtils, LinuxAppImageBuilder, LinuxDebBundler, LinuxRpmBundler, 
> MacAppImageBuilder, etc.
>
>
> JLinkBundlerHelper.java:
>
> 2. JRE_MODULES_FILENAME and SERVER_JRE_MODULES_FILENAME are unused 
> (obsolete) and should be removed.
>
>
> VersionExtractor.java:
>
> 3. The isLessThan method only looks at MAJOR.MINOR so might not be 
> flexible enough for some applications
Currently it is being used for InnoSetup and Wixs and we only need to 
compare major.minor, so should be fine for now.
>
>
> LinuxAppBundler.java:
>
> 3. Several places where non-public (package-scope) API is exported 
> publicly; these should all be package-scope itself or else 
> BundlerParamInfo should be public
>
>
>
> LinuxAppImageBuilder.java:
>
> 3. createUtf8File is unused (I went looking because I was curious how 
> and why we would use such a method). I see similarly-unused methods of 
> the same name in the Mac and Windows AppImageBuilder classes.
>
>
> MacAppImageBuilder.java:
>
> 4. Line 818: is the following still needed?
>
> ??????????????????????? || p.toString().contains(
> "/Contents/MacOS/JavaAppletPlugin")
>
>
> WindowsDefender.java + WindowsRegistry.java:
>
> 5. Is the check and warning for Windows Defender really needed? Have 
> we seen problems as a result of it running while jpackage is building 
> an app installer?
Yes, it is still needed. Resource update fails sometimes and I was able 
to reproduce this issue. However, not very often.

Thanks,
Alexander

From stuart.marks at oracle.com  Fri May  3 01:36:03 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 2 May 2019 18:36:03 -0700
Subject: RFR (M): JDK-6394757: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
Message-ID: <a55aaa5c-d530-4080-06c5-887af283bec0@oracle.com>

Hi all,

Please review these spec and implementation changes to remove the "optimization" 
to AbstractSet.removeAll. Briefly, this method was specified (and implemented) 
to iterate one collection or the other depending on the relative sizes of the 
collections. The problem is that this would cause an unexpected semantic shift, 
since one or the other collection's contains() method would be called depending 
on their relative sizes, and the contains() methods might implement different 
semantics depending upon the kind of collection.

The fix is to remove the specification and implementation of 
AbstractSet.removeAll and to inherit AbstractCollection.removeAll, which does 
the iteration one way consistently.

I've removed overriding removeAll method implementations from IdentityHashMap's 
view sets which were added in order to avoid the "optimization" inherited from 
AbstractSet.removeAll.

I've added some words to the Collection interface to introduce the term 
"membership semantics" for a concept that's been around for a long time but 
which never had a name, essentially the contains() method. I've then updated the 
specifications of containsAll, removeAll, retainAll, and (where necessary) 
equals to specify which collection's membership semantics are used.

Finally, since this change may introduce some performance issues the 
optimization was intended to avoid, I've added some implementation notes to the 
various methods to warn about potential performance issues if this collection's 
(or the other's) contains() method is linear or worse.

There have been various discussions in the past (see JDK-8178425 for example) 
that propose optimizations to the various bulk operations. They usually involve 
modifying the decision criteria for iterating this collection vs iterating the 
other collection. However, as we concluded previously, doing this introduces 
semantic problems. Another approach to optimizating the bulk cases is to copy 
the other collection into an intermediate collection that has an O(1) contains() 
method; however, this also changes the semantics and thus must be ruled out. 
Such approaches should be left to the caller.

Bug:

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

Previous discussions:

     http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html
     http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html

     (see also additional bugs and linked to the above bug)

Webrev:

     http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.0/

Thanks,

s'marks

From Alan.Bateman at oracle.com  Fri May  3 07:25:43 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 3 May 2019 08:25:43 +0100
Subject: JDK 13 RFR of JDK-8223112: Clarify operational semantics of
 java.util.Objects.equals()
In-Reply-To: <8e9f4850-6ef9-7cfa-b846-e05ec48107a8@oracle.com>
References: <8e9f4850-6ef9-7cfa-b846-e05ec48107a8@oracle.com>
Message-ID: <7bed4689-9991-9a32-d484-dc7da4d4b2b7@oracle.com>

On 02/05/2019 22:42, Joe Darcy wrote:
> :
>
> I don't think code should be added to Objects.equals itself to guard 
> against this case. Instead, I think the operational semantics of the 
> implementation should be made explicit in the specification.
I agree, I think the proposed clarification and the CSR look good.

-Alan

From kevin.rushforth at oracle.com  Fri May  3 12:38:31 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 3 May 2019 05:38:31 -0700
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <bce04dec-7334-8f33-9aa0-e7fb7babc3d1@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
 <ed2334bc-c87a-418a-fe3b-387cacdf2d6b@oracle.com>
 <93e05dcc-2497-f5aa-fa02-73184476cc19@oracle.com>
 <bce04dec-7334-8f33-9aa0-e7fb7babc3d1@oracle.com>
Message-ID: <7d13e810-9d9c-d256-854e-e2f8bba4e346@oracle.com>

Hi Alexander,

I'll file cleanup issues (or add to existing bugs) for the rest.

Thanks.

-- Kevin



On 5/2/2019 6:33 PM, Alexander Matveev wrote:
> Hi Kevin,
>
> See below.
>
> On 5/2/2019 5:38 PM, Kevin Rushforth wrote:
>> Here are a few follow-on comments. As with my earlier comments, none 
>> of these need to be addressed prior to integration.
>>
>>
>> 1. I found a few more classes that do I/O and could benefit from 
>> using try-with-resources:
>> ?? IOUtils, LinuxAppImageBuilder, LinuxDebBundler, LinuxRpmBundler, 
>> MacAppImageBuilder, etc.
>>
>>
>> JLinkBundlerHelper.java:
>>
>> 2. JRE_MODULES_FILENAME and SERVER_JRE_MODULES_FILENAME are unused 
>> (obsolete) and should be removed.
>>
>>
>> VersionExtractor.java:
>>
>> 3. The isLessThan method only looks at MAJOR.MINOR so might not be 
>> flexible enough for some applications
> Currently it is being used for InnoSetup and Wixs and we only need to 
> compare major.minor, so should be fine for now.
>>
>>
>> LinuxAppBundler.java:
>>
>> 3. Several places where non-public (package-scope) API is exported 
>> publicly; these should all be package-scope itself or else 
>> BundlerParamInfo should be public
>>
>>
>>
>> LinuxAppImageBuilder.java:
>>
>> 3. createUtf8File is unused (I went looking because I was curious how 
>> and why we would use such a method). I see similarly-unused methods 
>> of the same name in the Mac and Windows AppImageBuilder classes.
>>
>>
>> MacAppImageBuilder.java:
>>
>> 4. Line 818: is the following still needed?
>>
>> ??????????????????????? || p.toString().contains(
>> "/Contents/MacOS/JavaAppletPlugin")
>>
>>
>> WindowsDefender.java + WindowsRegistry.java:
>>
>> 5. Is the check and warning for Windows Defender really needed? Have 
>> we seen problems as a result of it running while jpackage is building 
>> an app installer?
> Yes, it is still needed. Resource update fails sometimes and I was 
> able to reproduce this issue. However, not very often.
>
> Thanks,
> Alexander


From amaembo at gmail.com  Fri May  3 13:20:07 2019
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 3 May 2019 19:20:07 +0600
Subject: RFR (M): JDK-6394757: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <a55aaa5c-d530-4080-06c5-887af283bec0@oracle.com>
References: <a55aaa5c-d530-4080-06c5-887af283bec0@oracle.com>
Message-ID: <CAE+3fjZe5DazuM2Mm1hLp+kZYu+mWjZS6mRF7p6TJb26GL+dFQ@mail.gmail.com>

I'm not a reviewer, but strongly support this change. Simpler is better.
Thanks!

With best regards,
Tagir Valeev.

??, 3 ??? 2019 ?., 7:37 Stuart Marks <stuart.marks at oracle.com>:

> Hi all,
>
> Please review these spec and implementation changes to remove the
> "optimization"
> to AbstractSet.removeAll. Briefly, this method was specified (and
> implemented)
> to iterate one collection or the other depending on the relative sizes of
> the
> collections. The problem is that this would cause an unexpected semantic
> shift,
> since one or the other collection's contains() method would be called
> depending
> on their relative sizes, and the contains() methods might implement
> different
> semantics depending upon the kind of collection.
>
> The fix is to remove the specification and implementation of
> AbstractSet.removeAll and to inherit AbstractCollection.removeAll, which
> does
> the iteration one way consistently.
>
> I've removed overriding removeAll method implementations from
> IdentityHashMap's
> view sets which were added in order to avoid the "optimization" inherited
> from
> AbstractSet.removeAll.
>
> I've added some words to the Collection interface to introduce the term
> "membership semantics" for a concept that's been around for a long time
> but
> which never had a name, essentially the contains() method. I've then
> updated the
> specifications of containsAll, removeAll, retainAll, and (where necessary)
> equals to specify which collection's membership semantics are used.
>
> Finally, since this change may introduce some performance issues the
> optimization was intended to avoid, I've added some implementation notes
> to the
> various methods to warn about potential performance issues if this
> collection's
> (or the other's) contains() method is linear or worse.
>
> There have been various discussions in the past (see JDK-8178425 for
> example)
> that propose optimizations to the various bulk operations. They usually
> involve
> modifying the decision criteria for iterating this collection vs iterating
> the
> other collection. However, as we concluded previously, doing this
> introduces
> semantic problems. Another approach to optimizating the bulk cases is to
> copy
> the other collection into an intermediate collection that has an O(1)
> contains()
> method; however, this also changes the semantics and thus must be ruled
> out.
> Such approaches should be left to the caller.
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-6394757
>
> Previous discussions:
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html
>
>      (see also additional bugs and linked to the above bug)
>
> Webrev:
>
>      http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.0/
>
> Thanks,
>
> s'marks
>

From alexey.semenyuk at oracle.com  Fri May  3 17:04:37 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 3 May 2019 13:04:37 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <43E836D1-908F-426B-A4BB-6CD1A413A7B2@gmail.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com>
 <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com>
 <43E836D1-908F-426B-A4BB-6CD1A413A7B2@gmail.com>
Message-ID: <53cf1f6b-c9bc-d244-bb9a-3266a27253d5@oracle.com>

Hi Scott,

I agree this a good option. Though we still need to create some custom 
wix source code for shortcuts, so we can't get rid completely of Java 
code generating wix sources.

- Alexey

On 5/2/2019 8:54 PM, Scott Palmer wrote:
> Ideally the wix code should be generated by running the heat.exe tool on the application image.
>
> Scott
>
>> On May 2, 2019, at 5:08 PM, Andy Herrick <andy.herrick at oracle.com> wrote:
>>
>> Alexey:
>>
>> Please file Bugs for these two issues.
>>
>> /Andy
>>
>>
>>> On 5/2/2019 1:49 PM, Alexey Semenyuk wrote:
>>> Some findings:
>>>
>>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk:
>>> I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html. Reason: these targets don't output executables into images/jdk/bin directory. They produce artifacts that stored as resources in jpackage just like other targets defined in Lib-jdk.jpackage.gmk.
>>>
>>> Wix source code produced by http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html doesn't comply to recommendations of how files should be packed in component. The recommendation is to use one file per a component - http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html. However jpackage produces way less components than files:
>>> ---
>>> $ less config/bundle.wxi | grep '<Component' | wc -w
>>> 634
>>>
>>> $ less config/bundle.wxi | grep '<File' | wc -w
>>> 1650
>>> ---
>>> Data picked from my local test project.
>>>
>>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745
>>>       + " Guid=\"" + UUID.randomUUID().toString() + "\""
>>> Use of random GUIDs for components is not recommended and potentially can result in issues with application updates. The recommended approach is to generate stable GUIDs - http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html, http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html.
>>> Algorithm to create stable GUIDs is explained at https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the hassle of generating stable GUIDs if we would put only one file in every component. In this case WiX is able to generate stable GUIDs for us.
>>>
>>> - Alexey
>>>
>>>> On 4/27/2019 8:46 PM, Philip Race wrote:
>>>> Adding build-dev for the build changes. I don't know if these were previously reviewed there,
>>>> but I am not sure what the changes in NativeCompilation.gmk have to do with jpackage.
>>>>
>>>> -phil.
>>>>
>>>>> On 4/24/19, 5:47 PM, Andy Herrick wrote:
>>>>>
>>>>>> On 4/24/2019 8:44 PM, Andy Herrick wrote:
>>>>>> Please review  changes for [1] which is the implementation bug for JEP-343.
>>>>>>
>>>>>> The webrev at [2] is the total cumulative webrev of changes for the jpackage tool, currently in the JDK-8200758-branch branch of the open sandbox repository.
>>>>>>
>>>>>> The webrev at [3] shows the changes from EA-05 to EA-06.
>>>>> sorry - the links are reversed from what is stated above. [2] is the incremental webrev since EA 05, [3] is the cumulativewebrev
>>>>> /Andy
>>>>>> The latest EA-6 (build 49) is posted at [4].
>>>>>>
>>>>>> Please send feedback to core-libs-dev at openjdk.java.net
>>>>>>
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>>>>>>
>>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/
>>>>>>
>>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/
>>>>>>
>>>>>> [4] http://jdk.java.net/jpackage/
>>>>>>
>>>>>>
>>>>>> /Andy
>>>>>>
>>>>>>


From kevin.rushforth at oracle.com  Fri May  3 17:22:52 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 3 May 2019 10:22:52 -0700
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
 <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
 <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
Message-ID: <aaa5e2b6-fc88-dee1-3f2b-e1fea912f589@oracle.com>

Thanks for your feedback. I filed two issues [1][2] for the thread 
concurrency issue. The first one needs to be solved for JDK 13, which is 
to either document the existing limitation (which is probably what we'll 
do) or serialize access by synchronizing on the JPackageToolProvider 
class (or, equivalently, making the Main::run methods synchronized). The 
second one is the improvement to allow concurrent execution of two 
instances of the tool, which can be done for a future version.

The rest of the comments can be added as cleanup items (either a new 
issue or to one of the existing issues).

-- Kevin


On 5/2/2019 8:16 AM, Roger Riggs wrote:
> Hi,
>
> Some comments, a initial batch...
>
> Having support for the ToolProvider is great.
> However, there is no indication about whether it is valid to use it 
> from multiple threads.
> The implementation is structured to be deliberately single thread use 
> only
> with the invocation being via a static method and the logging being 
> via static methods.
> There will need to be a disclaimer and perhaps an exception should be 
> thrown.
>
> A future improvement:
> The implementation should be methods on the instance created by the 
> ToolProvider
> and the logging relative to that instance/delegated where needed.
> Main can then be a simple lookup of the tool provider and invoke.
>
> jpackage.main.Main:
>
> ?- Main.run returns -1, which then is used as exit status, -1 is not 
> the usual exit status for a C/Unix main.
>
> 65,? the run() method is usually not static and should be re-named to 
> avoid confusion
>
> 92: Implies something should be logged on a failure.
>
> 65: Run (Pw, Pw, args...) doesn't use try ... finally to ensure log is 
> flushed.
>
> 65: 'throws Exception' implies it can throw an exception but is 
> ambiguous as to whether
> it returns an error number or throws on what kinds of errors?
>
> 91: Ambiguous as to whether processArguments() throws or return false!
>
> CommandLine:
> 59: Would be more flexible and powerful to use List<String> 
> consistently...
>
> 67: use arg.startsWith() for cleaner code.
>
> 102: Seems wasteful to parse all the arguments twice.
>
> jdk.jpackage.internal classes:
>
> AbstractAppImageBuilder:
> ?57: The constructor does not need to throw IOException
>
> 60:? are .diz files common enough to preemptively exclude (w/o 
> documentation)
>
> 89: Can the mix of old File API and new Path/Files APIs be avoided?
>
> Adding javadoc to the abstract builder methods will help future 
> maintainers.
>
> 203: is a bit more generous than most CLASSPATH parsing and might lead 
> to non-obvious bugs.
> ?? For example, a path component with a space in it!
>
> 229:? There is no mention of debugging support in JEP 343.
> ? Where is this functionality defined or is it to be identified as 
> undocumented internal implementation
>
> Regards, Roger
>


From kevin.rushforth at oracle.com  Fri May  3 17:23:28 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 3 May 2019 10:23:28 -0700
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
 <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
 <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
Message-ID: <d8a2a752-aeb3-ca73-14b0-0ab117d49a57@oracle.com>

Thanks for your feedback. I filed two issues [1][2] for the thread 
concurrency issue. The first one needs to be solved for JDK 13, which is 
to either document the existing limitation (which is probably what we'll 
do) or serialize access by synchronizing on the JPackageToolProvider 
class (or, equivalently, making the Main::run methods synchronized). The 
second one is the improvement to allow concurrent execution of two 
instances of the tool, which can be done for a future version.

The rest of the comments can be added as cleanup items (either a new 
issue or to one of the existing issues).

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8223321
[2] https://bugs.openjdk.java.net/browse/JDK-8223322


On 5/2/2019 8:16 AM, Roger Riggs wrote:
> Hi,
>
> Some comments, a initial batch...
>
> Having support for the ToolProvider is great.
> However, there is no indication about whether it is valid to use it 
> from multiple threads.
> The implementation is structured to be deliberately single thread use 
> only
> with the invocation being via a static method and the logging being 
> via static methods.
> There will need to be a disclaimer and perhaps an exception should be 
> thrown.
>
> A future improvement:
> The implementation should be methods on the instance created by the 
> ToolProvider
> and the logging relative to that instance/delegated where needed.
> Main can then be a simple lookup of the tool provider and invoke.
>
> jpackage.main.Main:
>
> ?- Main.run returns -1, which then is used as exit status, -1 is not 
> the usual exit status for a C/Unix main.
>
> 65,? the run() method is usually not static and should be re-named to 
> avoid confusion
>
> 92: Implies something should be logged on a failure.
>
> 65: Run (Pw, Pw, args...) doesn't use try ... finally to ensure log is 
> flushed.
>
> 65: 'throws Exception' implies it can throw an exception but is 
> ambiguous as to whether
> it returns an error number or throws on what kinds of errors?
>
> 91: Ambiguous as to whether processArguments() throws or return false!
>
> CommandLine:
> 59: Would be more flexible and powerful to use List<String> 
> consistently...
>
> 67: use arg.startsWith() for cleaner code.
>
> 102: Seems wasteful to parse all the arguments twice.
>
> jdk.jpackage.internal classes:
>
> AbstractAppImageBuilder:
> ?57: The constructor does not need to throw IOException
>
> 60:? are .diz files common enough to preemptively exclude (w/o 
> documentation)
>
> 89: Can the mix of old File API and new Path/Files APIs be avoided?
>
> Adding javadoc to the abstract builder methods will help future 
> maintainers.
>
> 203: is a bit more generous than most CLASSPATH parsing and might lead 
> to non-obvious bugs.
> ?? For example, a path component with a space in it!
>
> 229:? There is no mention of debugging support in JEP 343.
> ? Where is this functionality defined or is it to be identified as 
> undocumented internal implementation
>
> Regards, Roger
>


From alexey.semenyuk at oracle.com  Fri May  3 17:31:07 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 3 May 2019 13:31:07 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <3591f55d-83af-ad74-7d28-fe5308adc431@oracle.com>
 <7e2628c8-dd5f-13f8-9c4c-d1b257e02a33@oracle.com>
Message-ID: <9a2388a2-6243-9360-536b-b71e4e52f9a5@oracle.com>

Andy,

I've created the following CRs to track the findings:
https://bugs.openjdk.java.net/browse/JDK-8223325
https://bugs.openjdk.java.net/browse/JDK-8223323

- Alexey

On 5/2/2019 5:08 PM, Andy Herrick wrote:
> Alexey:
>
> Please file Bugs for these two issues.
>
> /Andy
>
>
> On 5/2/2019 1:49 PM, Alexey Semenyuk wrote:
>> Some findings:
>>
>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk: 
>>
>> I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and 
>> BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to 
>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html. 
>> Reason: these targets don't output executables into images/jdk/bin 
>> directory. They produce artifacts that stored as resources in 
>> jpackage just like other targets defined in Lib-jdk.jpackage.gmk.
>>
>> Wix source code produced by 
>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html 
>> doesn't comply to recommendations of how files should be packed in 
>> component. The recommendation is to use one file per a component - 
>> http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html. 
>> However jpackage produces way less components than files:
>> ---
>> $ less config/bundle.wxi | grep '<Component' | wc -w
>> 634
>>
>> $ less config/bundle.wxi | grep '<File' | wc -w
>> 1650
>> ---
>> Data picked from my local test project.
>>
>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745 
>>
>> ???? + " Guid=\"" + UUID.randomUUID().toString() + "\""
>> Use of random GUIDs for components is not recommended and potentially 
>> can result in issues with application updates. The recommended 
>> approach is to generate stable GUIDs - 
>> http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html, 
>> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html. 
>>
>> Algorithm to create stable GUIDs is explained at 
>> https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the 
>> hassle of generating stable GUIDs if we would put only one file in 
>> every component. In this case WiX is able to generate stable GUIDs 
>> for us.
>>
>> - Alexey
>>
>> On 4/27/2019 8:46 PM, Philip Race wrote:
>>> Adding build-dev for the build changes. I don't know if these were 
>>> previously reviewed there,
>>> but I am not sure what the changes in NativeCompilation.gmk have to 
>>> do with jpackage.
>>>
>>> -phil.
>>>
>>> On 4/24/19, 5:47 PM, Andy Herrick wrote:
>>>>
>>>> On 4/24/2019 8:44 PM, Andy Herrick wrote:
>>>>> Please review? changes for [1] which is the implementation bug for 
>>>>> JEP-343.
>>>>>
>>>>> The webrev at [2] is the total cumulative webrev of changes for 
>>>>> the jpackage tool, currently in the JDK-8200758-branch branch of 
>>>>> the open sandbox repository.
>>>>>
>>>>> The webrev at [3] shows the changes from EA-05 to EA-06.
>>>> sorry - the links are reversed from what is stated above. [2] is 
>>>> the incremental webrev since EA 05, [3] is the cumulativewebrev
>>>> /Andy
>>>>>
>>>>> The latest EA-6 (build 49) is posted at [4].
>>>>>
>>>>> Please send feedback to core-libs-dev at openjdk.java.net
>>>>>
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>>>>>
>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/
>>>>>
>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/
>>>>>
>>>>> [4] http://jdk.java.net/jpackage/
>>>>>
>>>>>
>>>>> /Andy
>>>>>
>>>>>
>>>>
>>
>


From kevin.rushforth at oracle.com  Fri May  3 18:08:29 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 3 May 2019 11:08:29 -0700
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <d8a2a752-aeb3-ca73-14b0-0ab117d49a57@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
 <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
 <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
 <d8a2a752-aeb3-ca73-14b0-0ab117d49a57@oracle.com>
Message-ID: <9b669f9f-6c11-54a3-668c-2d1fd8745951@oracle.com>

Here is the webrev to document the threading limitation:

https://bugs.openjdk.java.net/browse/JDK-8223321
http://cr.openjdk.java.net/~kcr/8223321/webrev.00/

Once reviewed, Andy can include this in the next version of the webrev 
(and we'll update the CSR).

-- Kevin


On 5/3/2019 10:23 AM, Kevin Rushforth wrote:
> Thanks for your feedback. I filed two issues [1][2] for the thread 
> concurrency issue. The first one needs to be solved for JDK 13, which 
> is to either document the existing limitation (which is probably what 
> we'll do) or serialize access by synchronizing on the 
> JPackageToolProvider class (or, equivalently, making the Main::run 
> methods synchronized). The second one is the improvement to allow 
> concurrent execution of two instances of the tool, which can be done 
> for a future version.
>
> The rest of the comments can be added as cleanup items (either a new 
> issue or to one of the existing issues).
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223321
> [2] https://bugs.openjdk.java.net/browse/JDK-8223322
>
>
> On 5/2/2019 8:16 AM, Roger Riggs wrote:
>> Hi,
>>
>> Some comments, a initial batch...
>>
>> Having support for the ToolProvider is great.
>> However, there is no indication about whether it is valid to use it 
>> from multiple threads.
>> The implementation is structured to be deliberately single thread use 
>> only
>> with the invocation being via a static method and the logging being 
>> via static methods.
>> There will need to be a disclaimer and perhaps an exception should be 
>> thrown.
>>
>> A future improvement:
>> The implementation should be methods on the instance created by the 
>> ToolProvider
>> and the logging relative to that instance/delegated where needed.
>> Main can then be a simple lookup of the tool provider and invoke.
>>
>> jpackage.main.Main:
>>
>> ?- Main.run returns -1, which then is used as exit status, -1 is not 
>> the usual exit status for a C/Unix main.
>>
>> 65,? the run() method is usually not static and should be re-named to 
>> avoid confusion
>>
>> 92: Implies something should be logged on a failure.
>>
>> 65: Run (Pw, Pw, args...) doesn't use try ... finally to ensure log 
>> is flushed.
>>
>> 65: 'throws Exception' implies it can throw an exception but is 
>> ambiguous as to whether
>> it returns an error number or throws on what kinds of errors?
>>
>> 91: Ambiguous as to whether processArguments() throws or return false!
>>
>> CommandLine:
>> 59: Would be more flexible and powerful to use List<String> 
>> consistently...
>>
>> 67: use arg.startsWith() for cleaner code.
>>
>> 102: Seems wasteful to parse all the arguments twice.
>>
>> jdk.jpackage.internal classes:
>>
>> AbstractAppImageBuilder:
>> ?57: The constructor does not need to throw IOException
>>
>> 60:? are .diz files common enough to preemptively exclude (w/o 
>> documentation)
>>
>> 89: Can the mix of old File API and new Path/Files APIs be avoided?
>>
>> Adding javadoc to the abstract builder methods will help future 
>> maintainers.
>>
>> 203: is a bit more generous than most CLASSPATH parsing and might 
>> lead to non-obvious bugs.
>> ?? For example, a path component with a space in it!
>>
>> 229:? There is no mention of debugging support in JEP 343.
>> ? Where is this functionality defined or is it to be identified as 
>> undocumented internal implementation
>>
>> Regards, Roger
>>
>


From philip.race at oracle.com  Fri May  3 18:08:50 2019
From: philip.race at oracle.com (Phil Race)
Date: Fri, 3 May 2019 11:08:50 -0700
Subject: RFR: 8222819: Remove setting of headless property on MacOS from
 launcher code.
Message-ID: <e3df55c0-e5c8-d84f-a7b9-1383a03d3af4@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8222819
Webrev: http://cr.openjdk.java.net/~prr/8222819/


After fixing https://bugs.openjdk.java.net/browse/JDK-8130266 the code
in the launcher which sets the java.awt.headless property on MacOS is 
defunct
since the java.desktop module figures it out for itself.
I did manual verification that this is still true by ssh'ing into a Mac 
system

So this is a clean up fix to remove the now unnecessary launcher code.

-phil.

From Roger.Riggs at oracle.com  Fri May  3 18:21:20 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 3 May 2019 14:21:20 -0400
Subject: RFR: 8222819: Remove setting of headless property on MacOS from
 launcher code.
In-Reply-To: <e3df55c0-e5c8-d84f-a7b9-1383a03d3af4@oracle.com>
References: <e3df55c0-e5c8-d84f-a7b9-1383a03d3af4@oracle.com>
Message-ID: <c59849f0-6d32-dbc1-19dd-fd518106844c@oracle.com>

Hi Phil,

Looks good, thanks for the cleanup.

Roger


On 05/03/2019 02:08 PM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222819
> Webrev: http://cr.openjdk.java.net/~prr/8222819/
>
>
> After fixing https://bugs.openjdk.java.net/browse/JDK-8130266 the code
> in the launcher which sets the java.awt.headless property on MacOS is 
> defunct
> since the java.desktop module figures it out for itself.
> I did manual verification that this is still true by ssh'ing into a 
> Mac system
>
> So this is a clean up fix to remove the now unnecessary launcher code.
>
> -phil.


From Roger.Riggs at oracle.com  Fri May  3 18:31:35 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 3 May 2019 14:31:35 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <9b669f9f-6c11-54a3-668c-2d1fd8745951@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
 <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
 <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
 <d8a2a752-aeb3-ca73-14b0-0ab117d49a57@oracle.com>
 <9b669f9f-6c11-54a3-668c-2d1fd8745951@oracle.com>
Message-ID: <a3fd8b88-728c-1cd6-62d7-e1b1af2e7037@oracle.com>

Hi Kevin,

I'm fine with the disclaimer; undefined behavior is fine.

Thanks, Roger

p.s. synchronizing the run method would prevent filing of issues when
someone does it anyway, keeping the noise to a minimum.


On 05/03/2019 02:08 PM, Kevin Rushforth wrote:
> Here is the webrev to document the threading limitation:
>
> https://bugs.openjdk.java.net/browse/JDK-8223321
> http://cr.openjdk.java.net/~kcr/8223321/webrev.00/
>
> Once reviewed, Andy can include this in the next version of the webrev 
> (and we'll update the CSR).
>
> -- Kevin
>
>
> On 5/3/2019 10:23 AM, Kevin Rushforth wrote:
>> Thanks for your feedback. I filed two issues [1][2] for the thread 
>> concurrency issue. The first one needs to be solved for JDK 13, which 
>> is to either document the existing limitation (which is probably what 
>> we'll do) or serialize access by synchronizing on the 
>> JPackageToolProvider class (or, equivalently, making the Main::run 
>> methods synchronized). The second one is the improvement to allow 
>> concurrent execution of two instances of the tool, which can be done 
>> for a future version.
>>
>> The rest of the comments can be added as cleanup items (either a new 
>> issue or to one of the existing issues).
>>
>> -- Kevin
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223321
>> [2] https://bugs.openjdk.java.net/browse/JDK-8223322
>>
>>
>> On 5/2/2019 8:16 AM, Roger Riggs wrote:
>>> Hi,
>>>
>>> Some comments, a initial batch...
>>>
>>> Having support for the ToolProvider is great.
>>> However, there is no indication about whether it is valid to use it 
>>> from multiple threads.
>>> The implementation is structured to be deliberately single thread 
>>> use only
>>> with the invocation being via a static method and the logging being 
>>> via static methods.
>>> There will need to be a disclaimer and perhaps an exception should 
>>> be thrown.
>>>
>>> A future improvement:
>>> The implementation should be methods on the instance created by the 
>>> ToolProvider
>>> and the logging relative to that instance/delegated where needed.
>>> Main can then be a simple lookup of the tool provider and invoke.
>>>
>>> jpackage.main.Main:
>>>
>>> ?- Main.run returns -1, which then is used as exit status, -1 is not 
>>> the usual exit status for a C/Unix main.
>>>
>>> 65,? the run() method is usually not static and should be re-named 
>>> to avoid confusion
>>>
>>> 92: Implies something should be logged on a failure.
>>>
>>> 65: Run (Pw, Pw, args...) doesn't use try ... finally to ensure log 
>>> is flushed.
>>>
>>> 65: 'throws Exception' implies it can throw an exception but is 
>>> ambiguous as to whether
>>> it returns an error number or throws on what kinds of errors?
>>>
>>> 91: Ambiguous as to whether processArguments() throws or return false!
>>>
>>> CommandLine:
>>> 59: Would be more flexible and powerful to use List<String> 
>>> consistently...
>>>
>>> 67: use arg.startsWith() for cleaner code.
>>>
>>> 102: Seems wasteful to parse all the arguments twice.
>>>
>>> jdk.jpackage.internal classes:
>>>
>>> AbstractAppImageBuilder:
>>> ?57: The constructor does not need to throw IOException
>>>
>>> 60:? are .diz files common enough to preemptively exclude (w/o 
>>> documentation)
>>>
>>> 89: Can the mix of old File API and new Path/Files APIs be avoided?
>>>
>>> Adding javadoc to the abstract builder methods will help future 
>>> maintainers.
>>>
>>> 203: is a bit more generous than most CLASSPATH parsing and might 
>>> lead to non-obvious bugs.
>>> ?? For example, a path component with a space in it!
>>>
>>> 229:? There is no mention of debugging support in JEP 343.
>>> ? Where is this functionality defined or is it to be identified as 
>>> undocumented internal implementation
>>>
>>> Regards, Roger
>>>
>>
>


From philip.race at oracle.com  Fri May  3 18:29:52 2019
From: philip.race at oracle.com (Phil Race)
Date: Fri, 3 May 2019 11:29:52 -0700 (PDT)
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <9b669f9f-6c11-54a3-668c-2d1fd8745951@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
 <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
 <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
 <d8a2a752-aeb3-ca73-14b0-0ab117d49a57@oracle.com>
 <9b669f9f-6c11-54a3-668c-2d1fd8745951@oracle.com>
Message-ID: <7087a83c-a448-52fc-b8eb-3971e1430354@oracle.com>

Looks good to me. We can live with this limitation for a little while, since
there aren't exactly thousands of users who will need to run this 
concurrently.
And concurrent use of the command line tool - ie using separate VMs 
works fine - per Kevin.

But we do need to get to it.

-phil.

On 5/3/19 11:08 AM, Kevin Rushforth wrote:
> Here is the webrev to document the threading limitation:
>
> https://bugs.openjdk.java.net/browse/JDK-8223321
> http://cr.openjdk.java.net/~kcr/8223321/webrev.00/
>
> Once reviewed, Andy can include this in the next version of the webrev 
> (and we'll update the CSR).
>
> -- Kevin
>
>
> On 5/3/2019 10:23 AM, Kevin Rushforth wrote:
>> Thanks for your feedback. I filed two issues [1][2] for the thread 
>> concurrency issue. The first one needs to be solved for JDK 13, which 
>> is to either document the existing limitation (which is probably what 
>> we'll do) or serialize access by synchronizing on the 
>> JPackageToolProvider class (or, equivalently, making the Main::run 
>> methods synchronized). The second one is the improvement to allow 
>> concurrent execution of two instances of the tool, which can be done 
>> for a future version.
>>
>> The rest of the comments can be added as cleanup items (either a new 
>> issue or to one of the existing issues).
>>
>> -- Kevin
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223321
>> [2] https://bugs.openjdk.java.net/browse/JDK-8223322
>>
>>
>> On 5/2/2019 8:16 AM, Roger Riggs wrote:
>>> Hi,
>>>
>>> Some comments, a initial batch...
>>>
>>> Having support for the ToolProvider is great.
>>> However, there is no indication about whether it is valid to use it 
>>> from multiple threads.
>>> The implementation is structured to be deliberately single thread 
>>> use only
>>> with the invocation being via a static method and the logging being 
>>> via static methods.
>>> There will need to be a disclaimer and perhaps an exception should 
>>> be thrown.
>>>
>>> A future improvement:
>>> The implementation should be methods on the instance created by the 
>>> ToolProvider
>>> and the logging relative to that instance/delegated where needed.
>>> Main can then be a simple lookup of the tool provider and invoke.
>>>
>>> jpackage.main.Main:
>>>
>>> ?- Main.run returns -1, which then is used as exit status, -1 is not 
>>> the usual exit status for a C/Unix main.
>>>
>>> 65,? the run() method is usually not static and should be re-named 
>>> to avoid confusion
>>>
>>> 92: Implies something should be logged on a failure.
>>>
>>> 65: Run (Pw, Pw, args...) doesn't use try ... finally to ensure log 
>>> is flushed.
>>>
>>> 65: 'throws Exception' implies it can throw an exception but is 
>>> ambiguous as to whether
>>> it returns an error number or throws on what kinds of errors?
>>>
>>> 91: Ambiguous as to whether processArguments() throws or return false!
>>>
>>> CommandLine:
>>> 59: Would be more flexible and powerful to use List<String> 
>>> consistently...
>>>
>>> 67: use arg.startsWith() for cleaner code.
>>>
>>> 102: Seems wasteful to parse all the arguments twice.
>>>
>>> jdk.jpackage.internal classes:
>>>
>>> AbstractAppImageBuilder:
>>> ?57: The constructor does not need to throw IOException
>>>
>>> 60:? are .diz files common enough to preemptively exclude (w/o 
>>> documentation)
>>>
>>> 89: Can the mix of old File API and new Path/Files APIs be avoided?
>>>
>>> Adding javadoc to the abstract builder methods will help future 
>>> maintainers.
>>>
>>> 203: is a bit more generous than most CLASSPATH parsing and might 
>>> lead to non-obvious bugs.
>>> ?? For example, a path component with a space in it!
>>>
>>> 229:? There is no mention of debugging support in JEP 343.
>>> ? Where is this functionality defined or is it to be identified as 
>>> undocumented internal implementation
>>>
>>> Regards, Roger
>>>
>>
>


From kevin.rushforth at oracle.com  Fri May  3 18:33:51 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 3 May 2019 11:33:51 -0700
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <a3fd8b88-728c-1cd6-62d7-e1b1af2e7037@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
 <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
 <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
 <d8a2a752-aeb3-ca73-14b0-0ab117d49a57@oracle.com>
 <9b669f9f-6c11-54a3-668c-2d1fd8745951@oracle.com>
 <a3fd8b88-728c-1cd6-62d7-e1b1af2e7037@oracle.com>
Message-ID: <db6e323b-8f05-8d1a-26bb-9d8fdc404708@oracle.com>

OK, thanks.

-- Kevin

On 5/3/2019 11:31 AM, Roger Riggs wrote:
> Hi Kevin,
>
> I'm fine with the disclaimer; undefined behavior is fine.
>
> Thanks, Roger
>
> p.s. synchronizing the run method would prevent filing of issues when
> someone does it anyway, keeping the noise to a minimum.
>
>
> On 05/03/2019 02:08 PM, Kevin Rushforth wrote:
>> Here is the webrev to document the threading limitation:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8223321
>> http://cr.openjdk.java.net/~kcr/8223321/webrev.00/
>>
>> Once reviewed, Andy can include this in the next version of the 
>> webrev (and we'll update the CSR).
>>
>> -- Kevin
>>
>>
>> On 5/3/2019 10:23 AM, Kevin Rushforth wrote:
>>> Thanks for your feedback. I filed two issues [1][2] for the thread 
>>> concurrency issue. The first one needs to be solved for JDK 13, 
>>> which is to either document the existing limitation (which is 
>>> probably what we'll do) or serialize access by synchronizing on the 
>>> JPackageToolProvider class (or, equivalently, making the Main::run 
>>> methods synchronized). The second one is the improvement to allow 
>>> concurrent execution of two instances of the tool, which can be done 
>>> for a future version.
>>>
>>> The rest of the comments can be added as cleanup items (either a new 
>>> issue or to one of the existing issues).
>>>
>>> -- Kevin
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8223321
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8223322
>>>
>>>
>>> On 5/2/2019 8:16 AM, Roger Riggs wrote:
>>>> Hi,
>>>>
>>>> Some comments, a initial batch...
>>>>
>>>> Having support for the ToolProvider is great.
>>>> However, there is no indication about whether it is valid to use it 
>>>> from multiple threads.
>>>> The implementation is structured to be deliberately single thread 
>>>> use only
>>>> with the invocation being via a static method and the logging being 
>>>> via static methods.
>>>> There will need to be a disclaimer and perhaps an exception should 
>>>> be thrown.
>>>>
>>>> A future improvement:
>>>> The implementation should be methods on the instance created by the 
>>>> ToolProvider
>>>> and the logging relative to that instance/delegated where needed.
>>>> Main can then be a simple lookup of the tool provider and invoke.
>>>>
>>>> jpackage.main.Main:
>>>>
>>>> ?- Main.run returns -1, which then is used as exit status, -1 is 
>>>> not the usual exit status for a C/Unix main.
>>>>
>>>> 65,? the run() method is usually not static and should be re-named 
>>>> to avoid confusion
>>>>
>>>> 92: Implies something should be logged on a failure.
>>>>
>>>> 65: Run (Pw, Pw, args...) doesn't use try ... finally to ensure log 
>>>> is flushed.
>>>>
>>>> 65: 'throws Exception' implies it can throw an exception but is 
>>>> ambiguous as to whether
>>>> it returns an error number or throws on what kinds of errors?
>>>>
>>>> 91: Ambiguous as to whether processArguments() throws or return false!
>>>>
>>>> CommandLine:
>>>> 59: Would be more flexible and powerful to use List<String> 
>>>> consistently...
>>>>
>>>> 67: use arg.startsWith() for cleaner code.
>>>>
>>>> 102: Seems wasteful to parse all the arguments twice.
>>>>
>>>> jdk.jpackage.internal classes:
>>>>
>>>> AbstractAppImageBuilder:
>>>> ?57: The constructor does not need to throw IOException
>>>>
>>>> 60:? are .diz files common enough to preemptively exclude (w/o 
>>>> documentation)
>>>>
>>>> 89: Can the mix of old File API and new Path/Files APIs be avoided?
>>>>
>>>> Adding javadoc to the abstract builder methods will help future 
>>>> maintainers.
>>>>
>>>> 203: is a bit more generous than most CLASSPATH parsing and might 
>>>> lead to non-obvious bugs.
>>>> ?? For example, a path component with a space in it!
>>>>
>>>> 229:? There is no mention of debugging support in JEP 343.
>>>> ? Where is this functionality defined or is it to be identified as 
>>>> undocumented internal implementation
>>>>
>>>> Regards, Roger
>>>>
>>>
>>
>


From andy.herrick at oracle.com  Fri May  3 18:34:27 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 3 May 2019 14:34:27 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <9b669f9f-6c11-54a3-668c-2d1fd8745951@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <3da2c640-8fad-335b-9696-69f45e1a1024@oracle.com>
 <5CC4F7E0.7020208@oracle.com>
 <de9f5cd7-2829-7e72-e30a-f0f1f1db8d8d@oracle.com>
 <19f1ecec-b932-f096-95ea-5cf0c7c1c365@oracle.com>
 <01b88418-1c69-4180-be24-5e4207c06493@oracle.com>
 <2e0b146d-25fa-1781-2083-bb8901bb95fb@oracle.com>
 <cc6007d4-5848-28c0-22c5-b95b193a4752@oracle.com>
 <3ea7117a-48ae-5d6a-2966-2c9bf29994cd@oracle.com>
 <d8a2a752-aeb3-ca73-14b0-0ab117d49a57@oracle.com>
 <9b669f9f-6c11-54a3-668c-2d1fd8745951@oracle.com>
Message-ID: <c7431e90-5472-e323-1b69-21ef229c5eed@oracle.com>

looks good.

/Andy


On 5/3/2019 2:08 PM, Kevin Rushforth wrote:
> Here is the webrev to document the threading limitation:
>
> https://bugs.openjdk.java.net/browse/JDK-8223321
> http://cr.openjdk.java.net/~kcr/8223321/webrev.00/
>
> Once reviewed, Andy can include this in the next version of the webrev 
> (and we'll update the CSR).
>
> -- Kevin
>
>
> On 5/3/2019 10:23 AM, Kevin Rushforth wrote:
>> Thanks for your feedback. I filed two issues [1][2] for the thread 
>> concurrency issue. The first one needs to be solved for JDK 13, which 
>> is to either document the existing limitation (which is probably what 
>> we'll do) or serialize access by synchronizing on the 
>> JPackageToolProvider class (or, equivalently, making the Main::run 
>> methods synchronized). The second one is the improvement to allow 
>> concurrent execution of two instances of the tool, which can be done 
>> for a future version.
>>
>> The rest of the comments can be added as cleanup items (either a new 
>> issue or to one of the existing issues).
>>
>> -- Kevin
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223321
>> [2] https://bugs.openjdk.java.net/browse/JDK-8223322
>>
>>
>> On 5/2/2019 8:16 AM, Roger Riggs wrote:
>>> Hi,
>>>
>>> Some comments, a initial batch...
>>>
>>> Having support for the ToolProvider is great.
>>> However, there is no indication about whether it is valid to use it 
>>> from multiple threads.
>>> The implementation is structured to be deliberately single thread 
>>> use only
>>> with the invocation being via a static method and the logging being 
>>> via static methods.
>>> There will need to be a disclaimer and perhaps an exception should 
>>> be thrown.
>>>
>>> A future improvement:
>>> The implementation should be methods on the instance created by the 
>>> ToolProvider
>>> and the logging relative to that instance/delegated where needed.
>>> Main can then be a simple lookup of the tool provider and invoke.
>>>
>>> jpackage.main.Main:
>>>
>>> ?- Main.run returns -1, which then is used as exit status, -1 is not 
>>> the usual exit status for a C/Unix main.
>>>
>>> 65,? the run() method is usually not static and should be re-named 
>>> to avoid confusion
>>>
>>> 92: Implies something should be logged on a failure.
>>>
>>> 65: Run (Pw, Pw, args...) doesn't use try ... finally to ensure log 
>>> is flushed.
>>>
>>> 65: 'throws Exception' implies it can throw an exception but is 
>>> ambiguous as to whether
>>> it returns an error number or throws on what kinds of errors?
>>>
>>> 91: Ambiguous as to whether processArguments() throws or return false!
>>>
>>> CommandLine:
>>> 59: Would be more flexible and powerful to use List<String> 
>>> consistently...
>>>
>>> 67: use arg.startsWith() for cleaner code.
>>>
>>> 102: Seems wasteful to parse all the arguments twice.
>>>
>>> jdk.jpackage.internal classes:
>>>
>>> AbstractAppImageBuilder:
>>> ?57: The constructor does not need to throw IOException
>>>
>>> 60:? are .diz files common enough to preemptively exclude (w/o 
>>> documentation)
>>>
>>> 89: Can the mix of old File API and new Path/Files APIs be avoided?
>>>
>>> Adding javadoc to the abstract builder methods will help future 
>>> maintainers.
>>>
>>> 203: is a bit more generous than most CLASSPATH parsing and might 
>>> lead to non-obvious bugs.
>>> ?? For example, a path component with a space in it!
>>>
>>> 229:? There is no mention of debugging support in JEP 343.
>>> ? Where is this functionality defined or is it to be identified as 
>>> undocumented internal implementation
>>>
>>> Regards, Roger
>>>
>>
>


From semyon.sadetsky at oracle.com  Fri May  3 19:08:53 2019
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Fri, 3 May 2019 12:08:53 -0700
Subject: RFR: JDK-8223318: jpackage --mac-bundle-name option doesn't work
Message-ID: <5573a04c-49a0-b615-4bb2-4b825756b15e@oracle.com>

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

webrev: http://cr.openjdk.java.net/~ssadetsky/8223318/webrev.00/

The fix adds reading of --mac-bundle-name option to the application 
image builder.

--Semyon


From andy.herrick at oracle.com  Fri May  3 19:23:03 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 3 May 2019 15:23:03 -0400
Subject: RFR: JDK-8223318: jpackage --mac-bundle-name option doesn't work
In-Reply-To: <5573a04c-49a0-b615-4bb2-4b825756b15e@oracle.com>
References: <5573a04c-49a0-b615-4bb2-4b825756b15e@oracle.com>
Message-ID: <cc70a50f-3ae0-fe9c-8d49-96fc34c94531@oracle.com>

Semyon:

This webrev also includes your fix for 8223038 
(http://cr.openjdk.java.net/~ssadetsky/8223038/).

Both fixes look good, but should wait till after JEP is targeted.

/Andy


On 5/3/2019 3:08 PM, semyon.sadetsky at oracle.com wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8223318
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8223318/webrev.00/
>
> The fix adds reading of --mac-bundle-name option to the application 
> image builder.
>
> --Semyon
>


From Alan.Bateman at oracle.com  Fri May  3 20:16:44 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 3 May 2019 21:16:44 +0100
Subject: JDK 13 RFR of JDK-8223178: Improve FileSystems.newFileSystem
 example with map factory methods
In-Reply-To: <86de9d15-d023-21a0-2869-5c4dee06cc7e@oracle.com>
References: <193181fd-a6a5-24d1-3bb1-7fec7780468b@oracle.com>
 <ef5734fd-13ae-e478-6ec1-ea9286570b58@oracle.com>
 <3dd3eaee-643c-6d35-151b-7bd932022fe9@oracle.com>
 <3d983664-dc0c-9b91-2bb3-6d6bd4c7258a@oracle.com>
 <86de9d15-d023-21a0-2869-5c4dee06cc7e@oracle.com>
Message-ID: <d16fdb48-7e29-0858-faff-52443b988800@oracle.com>

On 01/05/2019 21:48, Joe Darcy wrote:

> I'd prefer to push a version without the explicit map variable, but 
> the max line length is slightly longer:
>
> ????? * <pre>
> -???? *?? Map&lt;String,String&gt; env = new HashMap&lt;&gt;();
> -???? *?? env.put("capacity", "16G");
> -???? *?? env.put("blockSize", "4k");
> -???? *?? FileSystem fs = 
> FileSystems.newFileSystem(URI.create("memory:///?name=logfs"), env);
> +???? *? FileSystem fs = 
> FileSystems.newFileSystem(URI.create("memory:///?name=logfs"),
> +???? * Map.of("capacity", "16G", "blockSize", "4k"));
> ????? * </pre>
This version looks okay too.

-Alan

From Sergey.Bylokhov at oracle.com  Sat May  4 00:05:25 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 3 May 2019 17:05:25 -0700
Subject: <AWT Dev> RFR: 8222819: Remove setting of headless property on
 MacOS from launcher code.
In-Reply-To: <c59849f0-6d32-dbc1-19dd-fd518106844c@oracle.com>
References: <e3df55c0-e5c8-d84f-a7b9-1383a03d3af4@oracle.com>
 <c59849f0-6d32-dbc1-19dd-fd518106844c@oracle.com>
Message-ID: <a7b2e76c-3687-7566-67e5-15d80cee0476@oracle.com>

+1

On 03/05/2019 11:21, Roger Riggs wrote:
> Hi Phil,
> 
> Looks good, thanks for the cleanup.
> 
> Roger
> 
> 
> On 05/03/2019 02:08 PM, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222819
>> Webrev: http://cr.openjdk.java.net/~prr/8222819/
>>
>>
>> After fixing https://bugs.openjdk.java.net/browse/JDK-8130266 the code
>> in the launcher which sets the java.awt.headless property on MacOS is defunct
>> since the java.desktop module figures it out for itself.
>> I did manual verification that this is still true by ssh'ing into a Mac system
>>
>> So this is a clean up fix to remove the now unnecessary launcher code.
>>
>> -phil.
> 


-- 
Best regards, Sergey.

From ivan.gerasimov at oracle.com  Sat May  4 00:53:44 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 3 May 2019 17:53:44 -0700
Subject: RFR 8223174 : Pattern.compile() can throw confusing
 NegativeArraySizeException
Message-ID: <3db263aa-b3f0-1b07-13db-b61e08c07d96@oracle.com>

Hello!

A private method Pattern. RemoveQEQuoting() contains calculation of an 
array size, which can result in numeric overflow, and cause a confusing 
NegativeArraySizeException.

Would you please help review the fix?

Please note, that expressions `j + 2` and `pLen - i` cannot overflow 
(because j is the index of a substring "\Q", and i is an index < pLen), 
so they are not wrapped with exactXXX() methods.

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

-- 
With kind regards,
Ivan Gerasimov


From martinrb at google.com  Sat May  4 01:05:13 2019
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 3 May 2019 18:05:13 -0700
Subject: RFR 8223174 : Pattern.compile() can throw confusing
 NegativeArraySizeException
In-Reply-To: <3db263aa-b3f0-1b07-13db-b61e08c07d96@oracle.com>
References: <3db263aa-b3f0-1b07-13db-b61e08c07d96@oracle.com>
Message-ID: <CA+kOe08aOiDnb=XN1No_nFPds_bddrfOmZeu9CoJJecy5XOSoQ@mail.gmail.com>

Test should check that Pattern.compile does not return normally, e.g. by
throwing AssertionError.  Otherwise LGTM.

On Fri, May 3, 2019 at 5:54 PM Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Hello!
>
> A private method Pattern. RemoveQEQuoting() contains calculation of an
> array size, which can result in numeric overflow, and cause a confusing
> NegativeArraySizeException.
>
> Would you please help review the fix?
>
> Please note, that expressions `j + 2` and `pLen - i` cannot overflow
> (because j is the index of a substring "\Q", and i is an index < pLen),
> so they are not wrapped with exactXXX() methods.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223174
> WEBREV: http://cr.openjdk.java.net/~igerasim/8223174/00/webrev/
>
> --
> With kind regards,
> Ivan Gerasimov
>
>

From ivan.gerasimov at oracle.com  Sat May  4 01:32:53 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 3 May 2019 18:32:53 -0700
Subject: RFR 8223174 : Pattern.compile() can throw confusing
 NegativeArraySizeException
In-Reply-To: <CA+kOe08aOiDnb=XN1No_nFPds_bddrfOmZeu9CoJJecy5XOSoQ@mail.gmail.com>
References: <3db263aa-b3f0-1b07-13db-b61e08c07d96@oracle.com>
 <CA+kOe08aOiDnb=XN1No_nFPds_bddrfOmZeu9CoJJecy5XOSoQ@mail.gmail.com>
Message-ID: <7fc846cf-c227-e2e0-79ba-394d0f2fbac4@oracle.com>

Thank you Martin for review!


On 5/3/19 6:05 PM, Martin Buchholz wrote:
> Test should check that Pattern.compile does not return normally, e.g. 
> by throwing AssertionError.  Otherwise LGTM.
>
Well.  I think, that OOM in this scenario is a limitation of the current 
implementation.
If the implementation of Pattern changes, so that it won't need to 
allocate that temp array, then it will not have to necessarily throw, as 
the pattern is valid.

With kind regards,
Ivan

> On Fri, May 3, 2019 at 5:54 PM Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>     Hello!
>
>     A private method Pattern. RemoveQEQuoting() contains calculation
>     of an
>     array size, which can result in numeric overflow, and cause a
>     confusing
>     NegativeArraySizeException.
>
>     Would you please help review the fix?
>
>     Please note, that expressions `j + 2` and `pLen - i` cannot overflow
>     (because j is the index of a substring "\Q", and i is an index <
>     pLen),
>     so they are not wrapped with exactXXX() methods.
>
>     BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223174
>     WEBREV: http://cr.openjdk.java.net/~igerasim/8223174/00/webrev/
>     <http://cr.openjdk.java.net/%7Eigerasim/8223174/00/webrev/>
>
>     -- 
>     With kind regards,
>     Ivan Gerasimov
>

-- 
With kind regards,
Ivan Gerasimov


From martinrb at google.com  Sat May  4 05:18:09 2019
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 3 May 2019 22:18:09 -0700
Subject: RFR 8223174 : Pattern.compile() can throw confusing
 NegativeArraySizeException
In-Reply-To: <7fc846cf-c227-e2e0-79ba-394d0f2fbac4@oracle.com>
References: <3db263aa-b3f0-1b07-13db-b61e08c07d96@oracle.com>
 <CA+kOe08aOiDnb=XN1No_nFPds_bddrfOmZeu9CoJJecy5XOSoQ@mail.gmail.com>
 <7fc846cf-c227-e2e0-79ba-394d0f2fbac4@oracle.com>
Message-ID: <CA+kOe0-M1vt6tM+GgcGC=Yvwfrk5Nboi07QTdCHMRn55ma43hw@mail.gmail.com>

OK, sounds reasonable!

On Fri, May 3, 2019 at 6:32 PM Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Thank you Martin for review!
>
> On 5/3/19 6:05 PM, Martin Buchholz wrote:
>
> Test should check that Pattern.compile does not return normally, e.g. by
> throwing AssertionError.  Otherwise LGTM.
>
> Well.  I think, that OOM in this scenario is a limitation of the current
> implementation.
> If the implementation of Pattern changes, so that it won't need to
> allocate that temp array, then it will not have to necessarily throw, as
> the pattern is valid.
>
> With kind regards,
> Ivan
>
> On Fri, May 3, 2019 at 5:54 PM Ivan Gerasimov <ivan.gerasimov at oracle.com>
> wrote:
>
>> Hello!
>>
>> A private method Pattern. RemoveQEQuoting() contains calculation of an
>> array size, which can result in numeric overflow, and cause a confusing
>> NegativeArraySizeException.
>>
>> Would you please help review the fix?
>>
>> Please note, that expressions `j + 2` and `pLen - i` cannot overflow
>> (because j is the index of a substring "\Q", and i is an index < pLen),
>> so they are not wrapped with exactXXX() methods.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223174
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223174/00/webrev/
>>
>> --
>> With kind regards,
>> Ivan Gerasimov
>>
>>
> --
> With kind regards,
> Ivan Gerasimov
>
>

From patrick at os.amperecomputing.com  Sat May  4 07:21:43 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Sat, 4 May 2019 07:21:43 +0000
Subject: RFR(trivial): 8222394: HashMap.compute() throws CME on an empty
 Map if clear() called concurrently
In-Reply-To: <33a11459-830f-07cd-3ee0-743657f6a6b7@oracle.com>
References: <BL0PR01MB50445D4086CD13A9785367348F280@BL0PR01MB5044.prod.exchangelabs.com>
 <a4fdb034-df89-9d86-2e53-5413048bd637@oracle.com>
 <BYAPR01MB50464E833DF1E9918A8BE9348F2B0@BYAPR01MB5046.prod.exchangelabs.com>
 <520e1ee0-8f1c-ae46-2b45-24555c88aa05@oracle.com>
 <BYAPR01MB50465E819FB106ACABEC8E998F3D0@BYAPR01MB5046.prod.exchangelabs.com>
 <33a11459-830f-07cd-3ee0-743657f6a6b7@oracle.com>
Message-ID: <BYAPR01MB50464A5E78FB94F47120851C8F360@BYAPR01MB5046.prod.exchangelabs.com>

Hi Stuart,

Thank you very much for the detailed explanation and examples, which solved most of my previous questions and confusion. Really appreciate that. I agree with the opinion about "effort vs benefit".

Re-thought my original tests concerning CMEs that passed with jdk8u but failed with jdk11 (should be 9+, but I only checked LTS builds), I was struggling between "fixing" the "problems" in jdk11 and "making jdk8 fail similarly". However so far it looks these tests might be over strict, or "verifying CMEs" itself might be an invalid (or unreliable) operation, perhaps I should drop all of them. Lastly, a suggestion would be: adding more comments for this in case anyone else would revisit it with similar confusions, e.g. HashMap.clear. 

Regards
Patrick

-----Original Message-----
From: Stuart Marks <stuart.marks at oracle.com> 
Sent: Thursday, May 2, 2019 8:39 AM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR(trivial): 8222394: HashMap.compute() throws CME on an empty Map if clear() called concurrently


>> ...merely to serve as a discussion point about the policy for 
>> throwing ConcurrentModificationException?

> Yes, for the time being, I want to see and welcome more ideas on this. 
> It seems to me that the policy for throwing CME here is not a unified 
> one, mostly based on experience and testing. Clear, compute, and 
> computeIfAbsent are more special as I described.

OK. For reference, here are some of the words from the ConcurrentModificationException specification: [1]


> This exception may be thrown by methods that have detected concurrent 
> modification of an object when such modification is not permissible.
> 
> For example, it is not generally permissible for one thread to modify 
> a Collection while another thread is iterating over it. In general, 
> the results of the iteration are undefined under these circumstances. 
> Some Iterator implementations (including those of all the general 
> purpose collection implementations provided by the JRE) may choose to 
> throw this exception if this behavior is detected. Iterators that do 
> this are known as fail-fast iterators, as they fail quickly and 
> cleanly, rather that risking arbitrary, non-deterministic behavior at an undetermined time in the future.
> 
> Note that this exception does not always indicate that an object has 
> been concurrently modified by a different thread. If a single thread 
> issues a sequence of method invocations that violates the contract of 
> an object, the object may throw this exception. For example, if a 
> thread modifies a collection directly while it is iterating over the 
> collection with a fail-fast iterator, the iterator will throw this exception.
> 
> Note that fail-fast behavior cannot be guaranteed as it is, generally 
> speaking, impossible to make any hard guarantees in the presence of 
> unsynchronized concurrent modification. Fail-fast operations throw 
> ConcurrentModificationException on a best-effort basis. Therefore, it 
> would be wrong to write a program that depended on this exception for 
> its
> correctness: ConcurrentModificationException should be used only to 
> detect bugs.

[1]
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ConcurrentModificationException.html


Similar words are repeated in several different locations around the
specification, such as in the ArrayList and HashMap class specifications.

I'm not entirely sure what your concerns are with
ConcurrentModificationException (and the "fail-fast" concurrent modification
policy), but let me discuss a few points.

1. throwing of CME is not guaranteed - "best effort"

Unlike most Java specifications, the specification around CME is fairly 
indefinite. The wording is hedged -- "This exception may be thrown...." This 
implies that CME might or might not be thrown, even in cases where one might 
expect it to be.

It also says that CME is thrown on a "best effort" basis. This doesn't mean that 
the library makes the maximum possible effort to throw CME in every possible 
situation. Maybe "best effort" is somewhat misleading. Perhaps "reasonable" 
effort is more descriptive.

For example, ArrayList keeps a modCount field and increments and checks it 
occasionally. No synchronization is done. If the ArrayList is modified by 
another thread, the update to modCount might not be visible to all threads, 
which might result in data corruption instead of a CME.

One way to "fix" this would be to make access to modCount synchronized (or to 
make it volatile, or to make it an AtomicInteger or something) to improve the 
reliability of detecting concurrent modifications from other threads. This would 
add complexity to the code and also slow down common operations. Making this 
extra effort doesn't seem to be worthwhile.

2. throwing CME sometimes done even when not absolutely necessary

Another point is that the detection and throwing of a CME is an approximation of 
when concurrent modification would have any impact. In some cases CME will be 
thrown even when one wouldn't think it strictly necessary.

For example, consider a loop in the middle of iterating an ArrayList. 
ArrayList's iterator simply keeps an index to represent its current position. If 
an element is added to or removed from the front of the list, this would result 
in the iteration skipping or repeating elements. Thus, throwing CME seems 
warranted in this case.

Now consider an iteration in the middle of an ArrayList, and an addition or 
removal is made to the *end* of the list. This doesn't affect the current 
iteration; yet CME is thrown anyway. Why?

To avoid throwing CME in this case (but to throw it in the previous case) the 
ArrayList and its Iterators would have to keep track of more information about 
what changes were made and would have to do more checking at each iteration 
step. This could increase code complexity considerably. Again, this seems like 
it isn't worthwhile. Keeping a simple counter (modCount) and checking it at each 
iteration step is quite cheap, although it arguably does throw CME unnecessarily 
in this case.

Some of the cases you're talking about seem to fall into this category. A CME is 
thrown from compute() if an operation is merely attempted, even if the actual 
operation performed would have no ill effect.

3. state-dependent behavior

I discussed this in a previous message. My personal design style is to try to 
avoid this, although the library isn't wholly consistent in this regard. The 
discussion regarding CME and the compute() and similar methods is also related 
to state-dependent behavior.

4. edge cases

There are a number of edge cases that aren't treated wholly consistently across 
the libraries. Again with ArrayList, consider the following:

         List<Integer> list = new ArrayList<>(List.of(0, 1, 2))
     [0, 1, 2]
         var it = list.iterator()
         it.hasNext()
     true
         it.next()
     0
         it.hasNext()
     true
         it.next()
     1
         list.remove(0)
     0
         it.hasNext()
     false

Arguably, hasNext() should throw CME. If this were in a for-loop, the concurrent 
modification would be missed and the loop would terminate normally. Many 
iterators check for concurrent modification in their next() method but not in 
hasNext(). Perhaps this should be fixed, but it might break code that is 
apparently behaving well today, so we've left it unchanged.

There is also the case of JDK-8114832, where a failed attempt at modification 
will still cause a CME. This is more state-dependent behavior: should modCount 
be incremented when a modification is *attempted* or when modification 
*actually* occurs? (Martin says, "attempted murder is still a crime!")

This bug is still open, though Martin and I agree that no change should be made 
here. It's questionable to me whether we want to go through the old collections 
and update things to be more consistent. The effort is high, the benefit is 
fairly low, in my estimation, and there is a risk of breaking existing code. So 
we live with the inconsistencies.

*******

I'm kind of rambling here. Is this the kind of discussion you're interested in? 
Do you have any specific questions?

s'marks



From goetz.lindenmaier at sap.com  Mon May  6 09:02:54 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 6 May 2019 09:02:54 +0000
Subject: RFR(L): 8218628: Add detailed message to NullPointerException
 describing what is null.
In-Reply-To: <VI1PR02MB51835505401202E32518CD67EC280@VI1PR02MB5183.eurprd02.prod.outlook.com>
References: <7c4b0bc27961471e91195bef9e767226@sap.com>
 <a8b818e8-7833-bd5c-e527-da476d19c7ab@oracle.com>
 <a4b0c569ffd543ee844842f5a3ae64ad@sap.com>
 <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com>
 <bbfd9855f337445f9b0de88048f8e10b@sap.com>
 <d871303ade6c4ec594b55acca0a0ba00@sap.com>
 <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com>
 <e1917533-7298-6008-98a0-d494227e9ea1@oracle.com>
 <3245ec3cefe2471e8382048164c0ba6b@sap.com>
 <DB7PR02MB5178770C575AB211A8D1EEB2EC4B0@DB7PR02MB5178.eurprd02.prod.outlook.com>
 <VI1PR02MB51835505401202E32518CD67EC280@VI1PR02MB5183.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB4463E8CA5B15844849D0C011EC300@VI1PR02MB4463.eurprd02.prod.outlook.com>

Hi,

incorporating comments by Coleen, I prepared a new webrev:
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/08/ 
incremental webrev:
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/08-incremental/

I renamed the following new classes: 
  TrackingStackCreator  -> ExcpetionMessageBuilder
  SimulatedOperandStack -> SimulatedOperandStack
  StackSlotAnalysisData -> StackSlotAnalysisData
and moved their declaration to the .cpp file.

A new wrapper class BytecodeUtils contains the 
method that is called from jvm.cpp. Some code
is moved from jvm.cpp to bytecodeUtils.cpp
so the internal data structures are no more exposed.

StackSlotAnalysisData now has two fields getting
rid of / and %. This also makes debugging more simple.

Lots of comments were added or improved.

I adapted test langtools/jdk/jshell/ToolSimpleTest.java
to the new message.

Coleen, thanks for your help!

Best regards,
  Goetz.



> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Freitag, 12. April 2019 12:33
> To: Mandy Chung <mandy.chung at oracle.com>; Roger Riggs
> <Roger.Riggs at oracle.com>
> Cc: Java Core Libs <core-libs-dev at openjdk.java.net>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: RE: RFR(L): 8218628: Add detailed message to NullPointerException
> describing what is null.
> 
> Hi,
> 
> while waiting for progress on corresponding the JEP, I improved
> the implementation of generating the NPE message.  It now uses
> a single outputStream. This removes several allocations of temporary
> data. I also removed TrackingStackSource. The analysis code originally
> addressed several use cases, for NullPointerExceptions this is
> not needed.  I cleaned up bytecodeUtils from some code not (really) needed.
> 
> I split get_null_pointer_slot() into two methods: get_NPE_null_slot()
> and print_NPE_failed_action(). This simplifies the
> implementation, and streamlines it more with the text in the JEP.
> 
> I print methods using the code added in
> "8221470: Print methods in exception messages in java-like Syntax.",
> so it now prints 'void m(int)' instead of 'm(I)V'.
> 
> I implemented a row of new test cases, and rearranged the test
> to test the message part of print_NPE_failed_action() and
> print_NPE_cause() separated. I made sure all bytecodes
> handled in these methods are covered.
> Further I arranged the tests in methods according to the
> functional properties as discussed in the JEP.
> 
> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/07
> 
> Best regards,
>   Goetz.
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Lindenmaier, Goetz
> > Sent: Donnerstag, 14. M?rz 2019 21:56
> > To: 'Mandy Chung' <mandy.chung at oracle.com>; 'Roger Riggs'
> > <Roger.Riggs at oracle.com>
> > Cc: 'Java Core Libs' <core-libs-dev at openjdk.java.net>; 'hotspot-runtime-
> > dev at openjdk.java.net' <hotspot-runtime-dev at openjdk.java.net>
> > Subject: RE: RFR(L): 8218628: Add detailed message to NullPointerException
> > describing what is null.
> >
> > Hi,
> >
> > I had promised to work on a better wording of the messages.
> >
> > This I deliver with this webrev:
> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-
> > otherMessages/
> >
> > The test in the webrev is modified to just print messages along with the
> > code that raised the messages.
> >
> > Please have a look at these files with test output contained in the webrev:
> > Messages with debug information:
> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-
> > otherMessages/output_with_debug_info.txt
> > Messages without debug information:
> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/05-
> > otherMessages/output_no_debug_info.txt
> >
> > Especially look at the first few messages, they point out the usefulness
> > of this change.  They precisely say what was null in a chain of dereferences.
> >
> > Best regards,
> >   Goetz.
> >
> >
> > > -----Original Message-----
> > > From: Lindenmaier, Goetz
> > > Sent: Wednesday, February 13, 2019 10:09 AM
> > > To: 'Mandy Chung' <mandy.chung at oracle.com>; Roger Riggs
> > > <Roger.Riggs at oracle.com>
> > > Cc: Java Core Libs <core-libs-dev at openjdk.java.net>; hotspot-runtime-
> > > dev at openjdk.java.net
> > > Subject: RE: RFR(L): 8218628: Add detailed message to
> NullPointerException
> > > describing what is null.
> > >
> > > Hi Mandy,
> > >
> > > Thanks for supporting my intend of adding the message as such!
> > > I'll start implementing this in Java and come back with a webrev
> > > in a while.
> > >
> > > In parallel, I would like to continue discussing the other
> > > topics, e.g., the wording of the message. I will probably come up
> > > with a separate webrev for that.
> > >
> > > Best regards,
> > >   Goetz.
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> > > > Of Mandy Chung
> > > > Sent: Tuesday, February 12, 2019 7:32 PM
> > > > To: Roger Riggs <Roger.Riggs at oracle.com>
> > > > Cc: Java Core Libs <core-libs-dev at openjdk.java.net>; hotspot-runtime-
> > > > dev at openjdk.java.net
> > > > Subject: Re: RFR(L): 8218628: Add detailed message to
> > > NullPointerException
> > > > describing what is null.
> > > >
> > > > On 2/8/19 11:46 AM, Roger Riggs wrote:
> > > > > Hi,
> > > > >
> > > > > A few higher level issues should be considered, though the details
> > > > > of the webrev captured my immediate attention.
> > > > >
> > > > > Is this the right feature and is this the right level of implementation
> > > > > (C++/native)?
> > > > > :
> > > > > How much of this can be done in Java code with StackWalker and other
> > > > > java APIs?
> > > > > It would be a shame to add this much native code if there was a more
> > > > robust
> > > > > way to implement it using APIs with more leverage.
> > > >
> > > > Improving the NPE message for better diagnosability is helpful while
> > > > I share the same concern Roger raised.
> > > >
> > > > Implementing this feature in Java and the library would be a better
> > > > choice as this isn't absolutely required to be done in VM in native.
> > > >
> > > > NPE keeps a backtrace capturing the method id and bci of each stack
> > > > frame.  One option to explore is to have StackWalker to accept a
> > > > Throwable object that returns a stream of StackFrame which allows
> > > > you to get the method and BCI and also code source (I started a
> > > > prototype for JDK-8189752 some time ago).  It can use the bytecode
> > > > library e.g. ASM to read the bytecode.  For NPE message, you can
> > > > implement a specialized StackFrameTraverser just for building
> > > > an exception message purpose.
> > > >
> > > > Mandy

From raffaello.giulietti at gmail.com  Mon May  6 12:08:48 2019
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 6 May 2019 14:08:48 +0200
Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect
 results
Message-ID: <be75c5cb-4766-3224-c9dc-23e4e3f3f873@gmail.com>

Hi,

no new code this time, only a warm invitation to review the rather 
substantial patch submitted on 2019-04-18 [1] and the CSR [2].

I spent an insane amount of (unpaid) free time offering my contribution 
to solve a bug known since about 15 years. Thus, I think it is 
understandable that I'd like to see my efforts come to a successful 
conclusion, ideally for OpenJDK 13.


Greetings
Raffaello


P.S.
Some enjoyable properties of the novel algorithm:
* No objects are instantiated, except, of course, the resulting String.
* Loop-free core algorithm.
* Only int and long arithmetic.
* No divisions at all.
* 16x speedup (jmh).
* Randomized, yet reproducible deep diving tests (jtreg).
* Clear, unambiguous spec.
* All floats have been tested to fully meet the spec.
* Fully documented in [3] or in comments.

----

[1] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059783.html
[2] https://bugs.openjdk.java.net/browse/JDK-8202555
[3] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058

From naoto.sato at oracle.com  Mon May  6 17:24:18 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 6 May 2019 10:24:18 -0700
Subject: [13] RFR: 8220037: Inconsistencies of generated timezone files
 between Windows and Linux
Message-ID: <970a6046-f5b7-3e73-c9b1-72227be18e1e@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed fix is located at:

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

The inconsistency comes from the different enumeration order of CLDR 
source files on each platform. Fix is to sort its order uniquely.

Naoto

From Roger.Riggs at oracle.com  Mon May  6 18:59:12 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 6 May 2019 14:59:12 -0400
Subject: [13] RFR: 8220037: Inconsistencies of generated timezone files
 between Windows and Linux
In-Reply-To: <970a6046-f5b7-3e73-c9b1-72227be18e1e@oracle.com>
References: <970a6046-f5b7-3e73-c9b1-72227be18e1e@oracle.com>
Message-ID: <8f111812-401b-21ff-c59b-15dd6a591428@oracle.com>

Hi Naoto,

CLDRConverter:
 ?358-271: Is a lambda viable here?? Not significantly different, just a 
more contemporary style.
 ??? (o1, o2) -> {...}.

CLDRDisplayNamesTest.java:
 ?136-137, 155, 158:? Another option is to have the stream return the count
of the number of errors and use peek to print the markers.

errors += List.of(Locale.ROOT,
         Locale.CHINA,
         Locale.GERMANY,
         Locale.JAPAN,
         Locale.UK,
         Locale.US,
         Locale.forLanguageTag("hi-IN"),
         Locale.forLanguageTag("es-419")).stream()
         .peek(System.out::println)
         .map(l -> DateFormatSymbols.getInstance(l).getZoneStrings())
         .flatMap(zoneStrings -> Arrays.stream(zoneStrings))
         .filter(namesArray -> Arrays.stream(namesArray)
                 .anyMatch(aName -> aName.equals(NO_INHERITANCE_MARKER)))
         .peek(marker -> {
             System.err.println("No inheritance marker detected with tzid: " + marker[0]);
         })
         .count();


151:? findAny() short circuits the count and stream so no more than 1 
error would be counted.

$.02, Roger



On 05/06/2019 01:24 PM, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8220037
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8220037/webrev.00/
>
> The inconsistency comes from the different enumeration order of CLDR 
> source files on each platform. Fix is to sort its order uniquely.
>
> Naoto


From naoto.sato at oracle.com  Mon May  6 19:40:51 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 6 May 2019 12:40:51 -0700
Subject: [13] RFR: 8220037: Inconsistencies of generated timezone files
 between Windows and Linux
In-Reply-To: <8f111812-401b-21ff-c59b-15dd6a591428@oracle.com>
References: <970a6046-f5b7-3e73-c9b1-72227be18e1e@oracle.com>
 <8f111812-401b-21ff-c59b-15dd6a591428@oracle.com>
Message-ID: <df0af04f-8a63-0c96-2c53-43530469f374@oracle.com>

Thanks, Roger. Webrev is modified accordingly:

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

Naoto

On 5/6/19 11:59 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> CLDRConverter:
>  ?358-271: Is a lambda viable here?? Not significantly different, just a 
> more contemporary style.
>  ??? (o1, o2) -> {...}.
> 
> CLDRDisplayNamesTest.java:
>  ?136-137, 155, 158:? Another option is to have the stream return the count
> of the number of errors and use peek to print the markers.
> 
> errors += List.of(Locale.ROOT,
>  ??????? Locale.CHINA,
>  ??????? Locale.GERMANY,
>  ??????? Locale.JAPAN,
>  ??????? Locale.UK,
>  ??????? Locale.US,
>  ??????? Locale.forLanguageTag("hi-IN"),
>  ??????? Locale.forLanguageTag("es-419")).stream()
>  ??????? .peek(System.out::println)
>  ??????? .map(l -> DateFormatSymbols.getInstance(l).getZoneStrings())
>  ??????? .flatMap(zoneStrings -> Arrays.stream(zoneStrings))
>  ??????? .filter(namesArray -> Arrays.stream(namesArray)
>  ??????????????? .anyMatch(aName -> aName.equals(NO_INHERITANCE_MARKER)))
>  ??????? .peek(marker -> {
>  ??????????? System.err.println("No inheritance marker detected with 
> tzid: " + marker[0]);
>  ??????? })
>  ??????? .count();
> 
> 
> 151:? findAny() short circuits the count and stream so no more than 1 
> error would be counted.
> 
> $.02, Roger
> 
> 
> 
> On 05/06/2019 01:24 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8220037
>>
>> The proposed fix is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8220037/webrev.00/
>>
>> The inconsistency comes from the different enumeration order of CLDR 
>> source files on each platform. Fix is to sort its order uniquely.
>>
>> Naoto
> 

From ivan.gerasimov at oracle.com  Mon May  6 19:42:06 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 6 May 2019 12:42:06 -0700
Subject: RFR 8222955 : Optimize String.replace(CharSequence, CharSequence)
 for Latin1 encoded strings
In-Reply-To: <fc43a9b4-8a95-f6be-20b6-49aae070b5bd@oracle.com>
References: <b2ed6732-8eb1-3402-e6e4-4aba2bf6f46d@oracle.com>
 <2bb0ea29-9b92-f9d2-7b26-ad56f01203b5@oracle.com>
 <CAE+3fjakhV0J+j9OVG7j1mDq2arWGQTstirY0iJQtnTVS-gojA@mail.gmail.com>
 <fc43a9b4-8a95-f6be-20b6-49aae070b5bd@oracle.com>
Message-ID: <11193ad0-7e7d-1dc1-0ab7-f1f670530c59@oracle.com>

Hello everyone!

I'm seeking a (capital R) Reviewer to review/approve the fix, so I could 
go ahead and push it.

The latest webrev contains an additional testcase for OOM suggested by 
Tagir.

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

Thanks in advance!

Ivan


On 4/30/19 10:20 AM, Ivan Gerasimov wrote:
> Hello Tagir!
>
>
> On 4/30/19 8:57 AM, Tagir Valeev wrote:
>> Hello!
>>
>> New webrev looks good. Probably it worth adding a testcase for
>> overflow (assert that OOME is thrown)? I guess, something like
>> "1".repeat(65536).replace("1", "1".repeat(65536)) would produce OOME
>> quite fast and without allocating much memory.
>
> Good point!  Will do.
>
> With kind regards,
> Ivan
>
>> With best regards,
>> Tagir Valeev.
>>
>> On Tue, Apr 30, 2019 at 11:43 AM Ivan Gerasimov
>> <ivan.gerasimov at oracle.com> wrote:
>>> Hello everyone!
>>>
>>> Please help review the second version of the enhancement.
>>> A separate branch was added to handle UTF16 in the searched string 
>>> and/or in the target and replacement.
>>>
>>> Switching to Math.xxxExact() suggested by Tagir gave ~4% of 
>>> throughput on affected test cases.
>>>
>>> Also, allocating uninitialized array added ~7% for Latin1 strings.
>>> I used StringConcatHelper.newArray() to avoid bringing Unsafe into 
>>> StringLatin1.
>>> In the StringLatin1.replace(), the newly allocated array is 
>>> guaranteed to be filled up, and the filling code should never throw, 
>>> so I believe using uninitialized arrays here is justified.
>>>
>>> Here's the updated webrev:
>>> http://cr.openjdk.java.net/~igerasim/8222955/01/webrev/
>>>
>>> Below please find the benchmark numbers (with an additional column, 
>>> showing the improvement.)
>>>
>>> Surprisingly, in one test case a slowdown was observed:  Only for 
>>> Latin1 string, with 1-char target, when the target string was *not* 
>>> found.
>>> If I understood it correctly, this is because prior the fix the 
>>> intrinsified StringLatin1.indexOf(byte[], byte[]) was called on the 
>>> first place, so there were effectively a fast path for exactly this 
>>> pattern.
>>>
>>> I'm not quite sure what to do about it.
>>> Maybe this is fine as it is, since the *average* improvement across 
>>> different test cases is still good?
>>>
>>>
>>>   - prior fix:
>>> Benchmark                          Mode  Cnt    Score   Error Units
>>> StringReplace.replace0x1_1_Latin1  avgt   15    7.116 ? 0.060 ns/op
>>> StringReplace.replace0x1_1_UTF16   avgt   15   84.255 ? 3.381 ns/op
>>> StringReplace.replace1x1_0_Latin1  avgt   15   63.254 ? 0.973 ns/op
>>> StringReplace.replace1x1_0_UTF16   avgt   15   89.941 ? 3.210 ns/op
>>> StringReplace.replace1x1_1_Latin1  avgt   15   75.662 ? 0.344 ns/op
>>> StringReplace.replace1x1_1_UTF16   avgt   15   81.454 ? 1.986 ns/op
>>> StringReplace.replace1x1_2_Latin1  avgt   15   89.492 ? 1.889 ns/op
>>> StringReplace.replace1x1_2_UTF16   avgt   15   87.430 ? 1.341 ns/op
>>> StringReplace.replace2x1_0_Latin1  avgt   15   69.575 ? 0.368 ns/op
>>> StringReplace.replace2x1_0_UTF16   avgt   15  112.201 ? 2.836 ns/op
>>> StringReplace.replace2x1_1_Latin1  avgt   15   83.841 ? 0.940 ns/op
>>> StringReplace.replace2x1_1_UTF16   avgt   15  115.722 ? 2.267 ns/op
>>> StringReplace.replace2x1_2_Latin1  avgt   15   99.266 ? 1.008 ns/op
>>> StringReplace.replace2x1_2_UTF16   avgt   15  132.271 ? 2.365 ns/op
>>>
>>>
>>>   - after fix:
>>> Benchmark                          Mode  Cnt   Score   Error Units
>>> StringReplace.replace0x1_1_Latin1  avgt   15  10.541 ? 0.826 ns/op   
>>> x0.68
>>> StringReplace.replace0x1_1_UTF16   avgt   15  31.473 ? 0.389 ns/op   
>>> x2.68
>>> StringReplace.replace1x1_0_Latin1  avgt   15  50.455 ? 5.038 ns/op   
>>> x1.25
>>> StringReplace.replace1x1_0_UTF16   avgt   15  35.355 ? 0.074 ns/op   
>>> x2.54
>>> StringReplace.replace1x1_1_Latin1  avgt   15  22.868 ? 0.076 ns/op   
>>> x3.31
>>> StringReplace.replace1x1_1_UTF16   avgt   15  22.290 ? 1.913 ns/op   
>>> x3.65
>>> StringReplace.replace1x1_2_Latin1  avgt   15  51.362 ? 0.130 ns/op   
>>> x1.74
>>> StringReplace.replace1x1_2_UTF16   avgt   15  33.086 ? 0.088 ns/op   
>>> x2.64
>>> StringReplace.replace2x1_0_Latin1  avgt   15  57.169 ? 7.165 ns/op   
>>> x1.22
>>> StringReplace.replace2x1_0_UTF16   avgt   15  50.886 ? 1.193 ns/op   
>>> x2.20
>>> StringReplace.replace2x1_1_Latin1  avgt   15  23.320 ? 2.954 ns/op   
>>> x3.60
>>> StringReplace.replace2x1_1_UTF16   avgt   15  24.741 ? 0.229 ns/op   
>>> x4.68
>>> StringReplace.replace2x1_2_Latin1  avgt   15  56.045 ? 0.153 ns/op   
>>> x1.77
>>> StringReplace.replace2x1_2_UTF16   avgt   15  49.795 ? 0.178 ns/op   
>>> x2.66
>>>
>>> -- 
>>> With kind regards,
>>> Ivan Gerasimov
>

-- 
With kind regards,
Ivan Gerasimov


From claes.redestad at oracle.com  Mon May  6 19:53:14 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 6 May 2019 21:53:14 +0200
Subject: RFR 8222955 : Optimize String.replace(CharSequence, CharSequence)
 for Latin1 encoded strings
In-Reply-To: <11193ad0-7e7d-1dc1-0ab7-f1f670530c59@oracle.com>
References: <b2ed6732-8eb1-3402-e6e4-4aba2bf6f46d@oracle.com>
 <2bb0ea29-9b92-f9d2-7b26-ad56f01203b5@oracle.com>
 <CAE+3fjakhV0J+j9OVG7j1mDq2arWGQTstirY0iJQtnTVS-gojA@mail.gmail.com>
 <fc43a9b4-8a95-f6be-20b6-49aae070b5bd@oracle.com>
 <11193ad0-7e7d-1dc1-0ab7-f1f670530c59@oracle.com>
Message-ID: <5fdc43c4-dc65-ca8c-18ee-a97236297c24@oracle.com>

Looks ok to me.

/Claes

On 2019-05-06 21:42, Ivan Gerasimov wrote:
> Hello everyone!
> 
> I'm seeking a (capital R) Reviewer to review/approve the fix, so I could 
> go ahead and push it.
> 
> The latest webrev contains an additional testcase for OOM suggested by 
> Tagir.
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8222955
> WEBREV: http://cr.openjdk.java.net/~igerasim/8222955/02/webrev/
> 
> Thanks in advance!
> 
> Ivan

From ivan.gerasimov at oracle.com  Mon May  6 19:54:32 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 6 May 2019 12:54:32 -0700
Subject: RFR 8222955 : Optimize String.replace(CharSequence, CharSequence)
 for Latin1 encoded strings
In-Reply-To: <5fdc43c4-dc65-ca8c-18ee-a97236297c24@oracle.com>
References: <b2ed6732-8eb1-3402-e6e4-4aba2bf6f46d@oracle.com>
 <2bb0ea29-9b92-f9d2-7b26-ad56f01203b5@oracle.com>
 <CAE+3fjakhV0J+j9OVG7j1mDq2arWGQTstirY0iJQtnTVS-gojA@mail.gmail.com>
 <fc43a9b4-8a95-f6be-20b6-49aae070b5bd@oracle.com>
 <11193ad0-7e7d-1dc1-0ab7-f1f670530c59@oracle.com>
 <5fdc43c4-dc65-ca8c-18ee-a97236297c24@oracle.com>
Message-ID: <6c589645-86f3-8b8e-4f51-93529ca35ffa@oracle.com>

Thank you Claes!


On 5/6/19 12:53 PM, Claes Redestad wrote:
> Looks ok to me.
>
> /Claes
>
> On 2019-05-06 21:42, Ivan Gerasimov wrote:
>> Hello everyone!
>>
>> I'm seeking a (capital R) Reviewer to review/approve the fix, so I 
>> could go ahead and push it.
>>
>> The latest webrev contains an additional testcase for OOM suggested 
>> by Tagir.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8222955
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8222955/02/webrev/
>>
>> Thanks in advance!
>>
>> Ivan
>

-- 
With kind regards,
Ivan Gerasimov


From philip.race at oracle.com  Mon May  6 22:11:02 2019
From: philip.race at oracle.com (Phil Race)
Date: Mon, 6 May 2019 15:11:02 -0700
Subject: RFR: 8212700: Change the mechanism by which JDK loads the
 platform-specific AWT Toolkit
Message-ID: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8212700
CSR: https://bugs.openjdk.java.net/browse/JDK-8223417
Webrev: https://cr.openjdk.java.net/~prr/8212700

Please review this bug + CSR to remove the awt.headless system property.

This should be the last of the fixes to remove use of system
properties set in the launcher to specify per-platform
internal classes and/or behaviours of the java.desktop module.

Half of the change is removing code from the launcher, and
then some small changes in Toolkit.java to consult a new
method in the per-platform internal PlatformGraphicsInfo.java class.

However it was also necessary to update each of the platform toolkit class
constructor code since they all get/set a system property to support
extra mouse buttons (I don't know why this could not be shared in
SunToolkit but that is another matter than this fix), and two of them
access the root thread group. Previously they inherited privileges
from the code in java.awt.Toolkit which instantiated them but now
they need to assert the privileges directly - at to the point of use.

As well as adding a simple new regression test, all the automated
headless tests and many automated headful tests were run as well
as basic manual testing.

The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit()

-phil

From philip.race at oracle.com  Tue May  7 04:01:08 2019
From: philip.race at oracle.com (Philip Race)
Date: Mon, 06 May 2019 21:01:08 -0700
Subject: <AWT Dev> RFR: 8212700: Change the mechanism by which JDK loads
 the platform-specific AWT Toolkit
In-Reply-To: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com>
References: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com>
Message-ID: <5CD10304.5020300@oracle.com>



On 5/6/19, 3:11 PM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8212700
> CSR: https://bugs.openjdk.java.net/browse/JDK-8223417
> Webrev: https://cr.openjdk.java.net/~prr/8212700
>
> Please review this bug + CSR to remove the awt.headless system property.

That would be awt.toolkit (sorry - copy + paste from a previous bug email).

-phil
>
> This should be the last of the fixes to remove use of system
> properties set in the launcher to specify per-platform
> internal classes and/or behaviours of the java.desktop module.
>
> Half of the change is removing code from the launcher, and
> then some small changes in Toolkit.java to consult a new
> method in the per-platform internal PlatformGraphicsInfo.java class.
>
> However it was also necessary to update each of the platform toolkit 
> class
> constructor code since they all get/set a system property to support
> extra mouse buttons (I don't know why this could not be shared in
> SunToolkit but that is another matter than this fix), and two of them
> access the root thread group. Previously they inherited privileges
> from the code in java.awt.Toolkit which instantiated them but now
> they need to assert the privileges directly - at to the point of use.
>
> As well as adding a simple new regression test, all the automated
> headless tests and many automated headful tests were run as well
> as basic manual testing.
>
> The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit()
>
> -phil

From maurizio.cimadamore at oracle.com  Tue May  7 11:45:21 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 7 May 2019 12:45:21 +0100
Subject: RFR (CSR) - JDK-8218285 ClassDesc should have a full name method
In-Reply-To: <292EE734-25CF-4FA8-B48E-326A82F610C1@oracle.com>
References: <64194254-41EB-430C-A8AB-5E98084E33E7@oracle.com>
 <292EE734-25CF-4FA8-B48E-326A82F610C1@oracle.com>
Message-ID: <3ec46002-5660-1e09-92a4-c9bdac0a5e35@oracle.com>

Looks good - only minor quibble is that the javadoc doesn't make it 
crystal clear as to whether the qualified name uses dots or '/'. Should 
the javadoc point at the term 'canonical name', or at 
Class::getCanonicalName (or both) ?

https://docs.oracle.com/javase/specs/jls/se12/html/jls-6.html#jls-6.7

Note that there are examples where full qualified vs. canonical yield 
different results.

Maurizio

On 30/04/2019 19:41, Jim Laskey wrote:
> I've had no takers. Please take the time. Thank you.
>
> -- Jim
>
>
>> On Apr 26, 2019, at 2:57 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>>
>> Please review. Thank you.
>>
>> Cheers,
>>
>> -- Jim
>>
>>
>>
>> Summary: Add the method ClassDesc::displayFullName to return the fully qualified class name from a ClassDesc. Add a second method MethodTypeDesc::displayFullDescriptor which returns the MethodTypeDesc descriptor using fully qualified class names.
>>
>> csr: https://bugs.openjdk.java.net/browse/JDK-8218285
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8212975
>> webrev: http://cr.openjdk.java.net/~jlaskey/8212975/webrev-03/index.html
>>

From james.laskey at oracle.com  Tue May  7 11:50:04 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 7 May 2019 08:50:04 -0300
Subject: RFR (CSR) - JDK-8218285 ClassDesc should have a full name method
In-Reply-To: <3ec46002-5660-1e09-92a4-c9bdac0a5e35@oracle.com>
References: <64194254-41EB-430C-A8AB-5E98084E33E7@oracle.com>
 <292EE734-25CF-4FA8-B48E-326A82F610C1@oracle.com>
 <3ec46002-5660-1e09-92a4-c9bdac0a5e35@oracle.com>
Message-ID: <58770420-BCC2-4588-9CB1-5E311B0BBDBF@oracle.com>

Thank you.

> On May 7, 2019, at 8:45 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Looks good - only minor quibble is that the javadoc doesn't make it crystal clear as to whether the qualified name uses dots or '/'. Should the javadoc point at the term 'canonical name', or at Class::getCanonicalName (or both) ?
> 
> https://docs.oracle.com/javase/specs/jls/se12/html/jls-6.html#jls-6.7
> 
> Note that there are examples where full qualified vs. canonical yield different results.
> 
> Maurizio
> 
> On 30/04/2019 19:41, Jim Laskey wrote:
>> I've had no takers. Please take the time. Thank you.
>> 
>> -- Jim
>> 
>> 
>>> On Apr 26, 2019, at 2:57 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>>> 
>>> Please review. Thank you.
>>> 
>>> Cheers,
>>> 
>>> -- Jim
>>> 
>>> 
>>> 
>>> Summary: Add the method ClassDesc::displayFullName to return the fully qualified class name from a ClassDesc. Add a second method MethodTypeDesc::displayFullDescriptor which returns the MethodTypeDesc descriptor using fully qualified class names.
>>> 
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8218285
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8212975
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8212975/webrev-03/index.html
>>> 


From bob.vandette at oracle.com  Tue May  7 12:56:40 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 7 May 2019 08:56:40 -0400
Subject: RFR: 8221340 - [TESTBUG] TestCgroupMetrics.java fails after fix for
 JDK-8219562
Message-ID: <96BEE19C-9950-48E9-9B11-9EA6EADE9123@oracle.com>

Please review this change to the Container Metrics implementation.

Change were made in JDK-8219562 [1] to osContainer_linux.cpp to correct
the parsing of of the /proc/self/mountinfo file but corresponding changes to the
Metrics API and Container tests shou,d have been done to match this change. 

BUG: 
https://bugs.openjdk.java.net/browse/JDK-8221340

WEBREV:
http://cr.openjdk.java.net/~bobv/8221340/webrev.00/

TESTING:
These changes were verified by running Mach5  tier1 and 2 tests and the jtreg container 
tests on a Linux x64 system.

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

Bob.


From goetz.lindenmaier at sap.com  Tue May  7 13:36:58 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 7 May 2019 13:36:58 +0000
Subject: RFR(L): 8218628: Add detailed message to NullPointerException
 describing what is null.
In-Reply-To: <AM0PR02MB450071BA4ECF288D0D68F7409F310@AM0PR02MB4500.eurprd02.prod.outlook.com>
References: <7c4b0bc27961471e91195bef9e767226@sap.com>
 <a8b818e8-7833-bd5c-e527-da476d19c7ab@oracle.com>
 <a4b0c569ffd543ee844842f5a3ae64ad@sap.com>
 <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com>
 <bbfd9855f337445f9b0de88048f8e10b@sap.com>
 <d871303ade6c4ec594b55acca0a0ba00@sap.com>
 <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com>
 <e1917533-7298-6008-98a0-d494227e9ea1@oracle.com>
 <3245ec3cefe2471e8382048164c0ba6b@sap.com>
 <DB7PR02MB5178770C575AB211A8D1EEB2EC4B0@DB7PR02MB5178.eurprd02.prod.outlook.com>
 <VI1PR02MB51835505401202E32518CD67EC280@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB4463E8CA5B15844849D0C011EC300@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <AM0PR02MB450071BA4ECF288D0D68F7409F310@AM0PR02MB4500.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB44636E249A2445FF4B538871EC310@VI1PR02MB4463.eurprd02.prod.outlook.com>

Hi,

Please have a look at this further improved webrev:
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09/
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09-incremental/

Harold, Coleen, thanks for pointing me to those methods.
I'm using them now. This simplifies the helper methods
considerably.

Ralf, thanks for looking at the messages!
I now suppress the "static " and 
"The return value of '" strings in the array subscript
expressions and added corresponding test cases.

About "can not" versus "cannot", what I find in the 
net "cannot" is to be preferred.  Any comments on that?
By native speakers?
See example messages here: 
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09/output_with_debug_info.txt

Further, I fixed a build issue with the solaris compiler.
All handling of bci is now unsigned.

Best regards,
  Goetz.




> -----Original Message-----
> From: Schmelter, Ralf
> Sent: Dienstag, 7. Mai 2019 14:35
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Java Core Libs <core-
> libs-dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net; Coleen
> Phillimore (coleen.phillimore at oracle.com) <coleen.phillimore at oracle.com>
> Subject: RE: RFR(L): 8218628: Add detailed message to NullPointerException
> describing what is null.
> 
> Hi Goetz,
> 
> I've played with the messages a little bit and they generally look good. But I've
> come across two which look strange:
>  - 'o[static Test.INDEX]' is null. Can not invoke method 'int
> java.lang.Object.hashCode()'
>  - 'o[The return value of 'int java.lang.String.hashCode()]' is null. Can not invoke
> method 'int java.lang.Object.hashCode()'.
> 
> Here is the test program to reproduce these:
> public class Test {
>     public static int INDEX = 2;
> 
>     public static void main(String[] args) {
>         Object[] o = new Object[10];
>         try {
>              o[INDEX].hashCode();
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>         try {
>              o["".hashCode()].hashCode();
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
> }
> 
> And 'Can not' should be 'Cannot'?
> 
> Best regards,
> Ralf

From Roger.Riggs at oracle.com  Tue May  7 13:38:20 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 7 May 2019 09:38:20 -0400
Subject: [13] RFR: 8220037: Inconsistencies of generated timezone files
 between Windows and Linux
In-Reply-To: <df0af04f-8a63-0c96-2c53-43530469f374@oracle.com>
References: <970a6046-f5b7-3e73-c9b1-72227be18e1e@oracle.com>
 <8f111812-401b-21ff-c59b-15dd6a591428@oracle.com>
 <df0af04f-8a63-0c96-2c53-43530469f374@oracle.com>
Message-ID: <49995fcc-ed44-e002-d4f0-d64d994dad5f@oracle.com>

Looks fine.

Thanks, Roger

On 05/06/2019 03:40 PM, naoto.sato at oracle.com wrote:
> Thanks, Roger. Webrev is modified accordingly:
>
> http://cr.openjdk.java.net/~naoto/8220037/webrev.01/
>
> Naoto
>
> On 5/6/19 11:59 AM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> CLDRConverter:
>> ??358-271: Is a lambda viable here?? Not significantly different, 
>> just a more contemporary style.
>> ???? (o1, o2) -> {...}.
>>
>> CLDRDisplayNamesTest.java:
>> ??136-137, 155, 158:? Another option is to have the stream return the 
>> count
>> of the number of errors and use peek to print the markers.
>>
>> errors += List.of(Locale.ROOT,
>> ???????? Locale.CHINA,
>> ???????? Locale.GERMANY,
>> ???????? Locale.JAPAN,
>> ???????? Locale.UK,
>> ???????? Locale.US,
>> ???????? Locale.forLanguageTag("hi-IN"),
>> ???????? Locale.forLanguageTag("es-419")).stream()
>> ???????? .peek(System.out::println)
>> ???????? .map(l -> DateFormatSymbols.getInstance(l).getZoneStrings())
>> ???????? .flatMap(zoneStrings -> Arrays.stream(zoneStrings))
>> ???????? .filter(namesArray -> Arrays.stream(namesArray)
>> ???????????????? .anyMatch(aName -> 
>> aName.equals(NO_INHERITANCE_MARKER)))
>> ???????? .peek(marker -> {
>> ???????????? System.err.println("No inheritance marker detected with 
>> tzid: " + marker[0]);
>> ???????? })
>> ???????? .count();
>>
>>
>> 151:? findAny() short circuits the count and stream so no more than 1 
>> error would be counted.
>>
>> $.02, Roger
>>
>>
>>
>> On 05/06/2019 01:24 PM, naoto.sato at oracle.com wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8220037
>>>
>>> The proposed fix is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8220037/webrev.00/
>>>
>>> The inconsistency comes from the different enumeration order of CLDR 
>>> source files on each platform. Fix is to sort its order uniquely.
>>>
>>> Naoto
>>


From Roger.Riggs at oracle.com  Tue May  7 14:44:03 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 7 May 2019 10:44:03 -0400
Subject: <AWT Dev> RFR: 8212700: Change the mechanism by which JDK loads
 the platform-specific AWT Toolkit
In-Reply-To: <5CD10304.5020300@oracle.com>
References: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com>
 <5CD10304.5020300@oracle.com>
Message-ID: <8d22cdfb-00b2-0661-5f05-7304811c72e4@oracle.com>

Hi Phil,

The changes look fine.

Thanks for the cleanup, Roger


On 05/07/2019 12:01 AM, Philip Race wrote:
>
>
> On 5/6/19, 3:11 PM, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212700
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223417
>> Webrev: https://cr.openjdk.java.net/~prr/8212700
>>
>> Please review this bug + CSR to remove the awt.headless system property.
>
> That would be awt.toolkit (sorry - copy + paste from a previous bug 
> email).
>
> -phil
>>
>> This should be the last of the fixes to remove use of system
>> properties set in the launcher to specify per-platform
>> internal classes and/or behaviours of the java.desktop module.
>>
>> Half of the change is removing code from the launcher, and
>> then some small changes in Toolkit.java to consult a new
>> method in the per-platform internal PlatformGraphicsInfo.java class.
>>
>> However it was also necessary to update each of the platform toolkit 
>> class
>> constructor code since they all get/set a system property to support
>> extra mouse buttons (I don't know why this could not be shared in
>> SunToolkit but that is another matter than this fix), and two of them
>> access the root thread group. Previously they inherited privileges
>> from the code in java.awt.Toolkit which instantiated them but now
>> they need to assert the privileges directly - at to the point of use.
>>
>> As well as adding a simple new regression test, all the automated
>> headless tests and many automated headful tests were run as well
>> as basic manual testing.
>>
>> The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit()
>>
>> -phil


From pavel.rappo at oracle.com  Tue May  7 15:21:54 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 7 May 2019 16:21:54 +0100
Subject: RFR (M): JDK-6394757: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <a55aaa5c-d530-4080-06c5-887af283bec0@oracle.com>
References: <a55aaa5c-d530-4080-06c5-887af283bec0@oracle.com>
Message-ID: <8E01DCD7-5C19-417E-8EE5-9D4EF9527024@oracle.com>

Stuart,

That looks good.

A tiny note on your FIXME comment [1]:

  68     // FIXME: the first paragraph below is copied from Set.equals, because
  69     // {@inheritDoc} will include text from Object.equals.

You might want to check if it is the same as [2] or [3]. If it is the same,
consider adding a reference to the appropriate issue to that FIXME comment for
future maintainers. It looks like there are some problems when inheriting
documentation from methods defined in java.lang.Object.

Thanks,
-Pavel

-------------------------------------------------------------------------------
[1] http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.0/src/java.base/share/classes/java/util/AbstractSet.java.sdiff.html
[2] https://bugs.openjdk.java.net/browse/JDK-8144034
[3] https://bugs.openjdk.java.net/browse/JDK-6376959


From semyon.sadetsky at oracle.com  Tue May  7 16:59:11 2019
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Tue, 7 May 2019 09:59:11 -0700
Subject: RFR: 8223402: Create tests for some Mac installer specific options
Message-ID: <adaa5f7b-a70a-5736-9391-70948dfd09ca@oracle.com>

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

webrev: http://cr.openjdk.java.net/~ssadetsky/8223402/webrev.00/

By this change tests added for jpackage Mac specific options:

--mac-bundle-name <name string>
--mac-bundle-identifier <ID string>
--mac-app-store-category <category string>

--Semyon


From ralf.schmelter at sap.com  Tue May  7 12:34:49 2019
From: ralf.schmelter at sap.com (Schmelter, Ralf)
Date: Tue, 7 May 2019 12:34:49 +0000
Subject: RFR(L): 8218628: Add detailed message to NullPointerException
 describing what is null.
In-Reply-To: <VI1PR02MB4463E8CA5B15844849D0C011EC300@VI1PR02MB4463.eurprd02.prod.outlook.com>
References: <7c4b0bc27961471e91195bef9e767226@sap.com>
 <a8b818e8-7833-bd5c-e527-da476d19c7ab@oracle.com>
 <a4b0c569ffd543ee844842f5a3ae64ad@sap.com>
 <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com>
 <bbfd9855f337445f9b0de88048f8e10b@sap.com>
 <d871303ade6c4ec594b55acca0a0ba00@sap.com>
 <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com>
 <e1917533-7298-6008-98a0-d494227e9ea1@oracle.com>
 <3245ec3cefe2471e8382048164c0ba6b@sap.com>
 <DB7PR02MB5178770C575AB211A8D1EEB2EC4B0@DB7PR02MB5178.eurprd02.prod.outlook.com>
 <VI1PR02MB51835505401202E32518CD67EC280@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB4463E8CA5B15844849D0C011EC300@VI1PR02MB4463.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB450071BA4ECF288D0D68F7409F310@AM0PR02MB4500.eurprd02.prod.outlook.com>

Hi Goetz,

I've played with the messages a little bit and they generally look good. But I've come across two which look strange:
 - 'o[static Test.INDEX]' is null. Can not invoke method 'int java.lang.Object.hashCode()'
 - 'o[The return value of 'int java.lang.String.hashCode()]' is null. Can not invoke method 'int java.lang.Object.hashCode()'.

Here is the test program to reproduce these:
public class Test {
    public static int INDEX = 2;

    public static void main(String[] args) {
        Object[] o = new Object[10];
        try {
             o[INDEX].hashCode();
        } catch (Exception e) {
            e.printStackTrace();
        }
        try {
             o["".hashCode()].hashCode();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

And 'Can not' should be 'Cannot'?

Best regards,
Ralf

From timothy2 at iastate.edu  Tue May  7 12:58:05 2019
From: timothy2 at iastate.edu (Timothy Schommer)
Date: Tue, 7 May 2019 07:58:05 -0500
Subject: An Interface equivalent for reflection
Message-ID: <CAOBeXKzqR1O-RxnyJSRLe8x2dK2G7fULUotM5SZtAns_qMHz7g@mail.gmail.com>

I would like to request the addition of an Interface equivalent usable for
reflection. Sometimes when writing a program it is desirable to have the
client program specify how your program should behave in a specific
scenario. Java's reflection can be used to obtain this method, but only if
the client implements it. In this case, a structure for guaranteeing that
the client implements the method is desirable. Interfaces come to mind for
this usage, as the program can type-check the client to ensure that they
implement it. However, what is not always so desirable about using an
Interface for this is the fact that all Interface methods must be public.
You may want to guarantee that the client has access to a method, but you
might not necessarily want every class that uses the client to have access
to the method. Having the client use reflection to pass the method in,
while providing a default implementation yourself is another possibility,
but it is impossible to completely type-check the method passed in until
you try to run it and throw an exception if it doesn't match. For
this reason I would like to request an Interface equivalent designed for
use with Java's reflection.

I understand that, in general, reflection is intended as a bit of a
last-ditch back door access, and that you may not wish to encourage more
general usage of reflection, but I feel that implementing this will make it
so that if people do choose to use reflection for something along the lines
of what I described above, then they can do so while minimizing the
likelihood of of throwing an exception due to an improper of non-existent
method.

Thank you for your time,
Timothy Schommer

From forax at univ-mlv.fr  Tue May  7 17:58:44 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 7 May 2019 19:58:44 +0200 (CEST)
Subject: An Interface equivalent for reflection
In-Reply-To: <CAOBeXKzqR1O-RxnyJSRLe8x2dK2G7fULUotM5SZtAns_qMHz7g@mail.gmail.com>
References: <CAOBeXKzqR1O-RxnyJSRLe8x2dK2G7fULUotM5SZtAns_qMHz7g@mail.gmail.com>
Message-ID: <968929224.747149.1557251924566.JavaMail.zimbra@u-pem.fr>

This is the wrong list, this list is about about the implementation of the core Java libraries, you are looking for the santa mailing list.

Anyway, in your case, Java has already the notion of functional interface, an interface with one abstract method that can be used to store a reference to a method.

@FunctionalInterface
interface Transform {
  String apply(String s);
}

class Main {
  private static String highlight(String s) {
    return "*" + s + "*";
  }  

  public static void algorithm(Transform transform) {
    ...
  }

  public static void main(String s) {
    Transform transform = Main::highlight;
    // or
    algorithm(Main::highlight);
  }
}

[if you have more questions, i will be happy to answer on my direct email address]

regards,
R?mi


----- Mail original -----
> De: "Timothy Schommer" <timothy2 at iastate.edu>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 7 Mai 2019 14:58:05
> Objet: An Interface equivalent for reflection

> I would like to request the addition of an Interface equivalent usable for
> reflection. Sometimes when writing a program it is desirable to have the
> client program specify how your program should behave in a specific
> scenario. Java's reflection can be used to obtain this method, but only if
> the client implements it. In this case, a structure for guaranteeing that
> the client implements the method is desirable. Interfaces come to mind for
> this usage, as the program can type-check the client to ensure that they
> implement it. However, what is not always so desirable about using an
> Interface for this is the fact that all Interface methods must be public.
> You may want to guarantee that the client has access to a method, but you
> might not necessarily want every class that uses the client to have access
> to the method. Having the client use reflection to pass the method in,
> while providing a default implementation yourself is another possibility,
> but it is impossible to completely type-check the method passed in until
> you try to run it and throw an exception if it doesn't match. For
> this reason I would like to request an Interface equivalent designed for
> use with Java's reflection.
> 
> I understand that, in general, reflection is intended as a bit of a
> last-ditch back door access, and that you may not wish to encourage more
> general usage of reflection, but I feel that implementing this will make it
> so that if people do choose to use reflection for something along the lines
> of what I described above, then they can do so while minimizing the
> likelihood of of throwing an exception due to an improper of non-existent
> method.
> 
> Thank you for your time,
> Timothy Schommer

From alexander.matveev at oracle.com  Tue May  7 18:17:31 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 7 May 2019 11:17:31 -0700
Subject: RFR: 8223402: Create tests for some Mac installer specific options
In-Reply-To: <adaa5f7b-a70a-5736-9391-70948dfd09ca@oracle.com>
References: <adaa5f7b-a70a-5736-9391-70948dfd09ca@oracle.com>
Message-ID: <98830c41-be0d-39d0-1379-059a7b7ebc12@oracle.com>

Hi Semyon,

Looks good. Add space after several if statements.

Thanks,
Alexander

On 5/7/2019 9:59 AM, semyon.sadetsky at oracle.com wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8223402
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8223402/webrev.00/
>
> By this change tests added for jpackage Mac specific options:
>
> --mac-bundle-name <name string>
> --mac-bundle-identifier <ID string>
> --mac-app-store-category <category string>
>
> --Semyon
>


From martinrb at google.com  Tue May  7 18:46:26 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 May 2019 11:46:26 -0700
Subject: RFR: JDK-8222930: ConcurrentSkipListMapTest.clone() broken since
 jdk10
In-Reply-To: <OFCC74609B.71E17DFC-ON002583EB.0034F227-802583EB.003866E6@notes.na.collabserv.com>
References: <OF0F3C0275.09074503-ON002583E6.005924D3-802583E6.0059CA9B@notes.na.collabserv.com>
 <c20351a5-1162-1372-d5c4-819239ac6d0f@oracle.com>
 <OFDCA121B3.C010014C-ON002583E7.00460715-802583E7.00463DFA@LocalDomain>
 <OFCC74609B.71E17DFC-ON002583EB.0034F227-802583EB.003866E6@notes.na.collabserv.com>
Message-ID: <CA+kOe0_UdjSzKCR2siuarg+S5CFeByt3n32WLgV8HxnVoX2d=A@mail.gmail.com>

Thanks!  Fix is now committed to jdk11, jdk12, jdk13.

*From: *Adam Farley8 <adam.farley at uk.ibm.com>
*Date: *Mon, Apr 29, 2019 at 3:16 AM
*To: * <martinrb at google.com>
*Cc: *Java Core Libs

Hi All,
>
> Reviews and feedback requested for the fix.
>
> *http://cr.openjdk.java.net/~afarley/8222930.1/jdk13/webrev*
> <http://cr.openjdk.java.net/~afarley/8222930.1/jdk13/webrev>
>
> Martin: Thanks for the testcase. I've replaced the old test in the webrev
> with your generalized one. :)
>
> Best Regards
>
> Adam Farley
> IBM Runtimes
>
>
> Adam Farley8/UK/IBM wrote on 25/04/2019 13:47:13:
>
> > From: Adam Farley8/UK/IBM
> > To: Stuart Marks <stuart.marks at oracle.com>
> > Cc: Java Core Libs <core-libs-dev at openjdk.java.net>
> > Date: 25/04/2019 13:47
> > Subject: Re: RFR: JDK-8222930: ConcurrentSkipListMapTest.clone()
> > broken since jdk10
> >
> > Hi Stuart,
> >
> > Whoops, typo. Thanks for catching that.
> >
> > Ditto for Martin, who has modified the bug. :)
> >
> > Best Regards
> >
> > Adam Farley
> > IBM Runtimes
>
> >
> > Stuart Marks <stuart.marks at oracle.com> wrote on 24/04/2019 17:59:17:
> >
> > > From: Stuart Marks <stuart.marks at oracle.com>
> > > To: Adam Farley8 <adam.farley at uk.ibm.com>
> > > Cc: Java Core Libs <core-libs-dev at openjdk.java.net>
> > > Date: 24/04/2019 17:59
> > > Subject: Re: RFR: JDK-8222930: ConcurrentSkipListMapTest.clone()
> > > broken since jdk10
> > >
> > > Hi Adam,
> > >
> > > Thanks for finding this bug!
> > >
> > > This is a bug in ConcurrentSkipListMap itself, not some test named
> > > ConcurrentSkipListMapTest. I'd suggest changing the bug summary
> > line and the
> > > commit message accordingly.
> > >
> > > Thanks,
> > >
> > > s'marks
> > >
> > > On 4/24/19 9:20 AM, Adam Farley8 wrote:
> > > > ConcurrentSkipListMapTest.clone() produces a clone that shares the
> array
> > > > size variable of the original, and then doubles it.
> > > >
> > > > So both arrays, original and clone, tell the user that each is twice
> as
> > > > big as it actually is.
> > > >
> > > > The proposed fix is to simply set the clone's array size variable to
> null
> > > > during creation.
> > > >
> > > > Fix and test code available.
> > > >
> > > > Reviews and sponsor requested.
> > > >
> > > > Webrev: https://urldefense.proofpoint.com/v2/url?
> > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8222930.
> > > 0_jdk13_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-
> > >
> >
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=9_BHLxc2OwO4OJABunATso0Ej3_keQ0c5uQJZ4AwSfk&s=0gBgd8gUhNlM26eNWxBbpnIAsFJPwnOtsmT6qH72NPM&e=
> > > >
> > > > Bug: https://urldefense.proofpoint.com/v2/url?
> > >
> >
> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8222930&d=DwICaQ&c=jf_iaSHvJObTbx-
> > > siA1ZOg&r=P5m8KWUXJf-
> > >
> >
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=9_BHLxc2OwO4OJABunATso0Ej3_keQ0c5uQJZ4AwSfk&s=vNk7C72hr8FqiYLJEVvCR69vlhPuT7zSIAiJ9Tl91JQ&e=
> > > >
> > > > Best Regards
> > > >
> > > > Adam Farley
> > > > IBM Runtimes
> > > >
> > > > P.S. Apparently this has been broken since JDK 10, so we should look
> at
> > > > backporting (at least to 11 and 12) once this is in.
> > > >
> > > > Unless stated otherwise above:
> > > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > > 741598.
> > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
> > > >
> > >
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>

From naoto.sato at oracle.com  Tue May  7 20:12:00 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 7 May 2019 13:12:00 -0700
Subject: [13] RFR: 8221432: Upgrade CLDR to Version 35.1
Message-ID: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8221432/webrev.02/

The webrev is big, but the large amount of the changes is simply 
replacing the CLDR data files from v33 to v35.1, which includes the 
translations for the Japanese new era, Reiwa.

Naoto

From bob.vandette at oracle.com  Tue May  7 20:25:58 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 7 May 2019 16:25:58 -0400
Subject: RFR:  8222533 - jtreg test
 jdk/internal/platform/cgroup/TestCgroupMetrics.java fails on SLES12.3 linux
 ppc64le machine
Message-ID: <76D43E76-B917-4EF5-9C30-B94F3DD8BC18@oracle.com>

Please review this simple fix for a TestCgroupMetrics.java test failure.

--- a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
+++ b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
@@ -108,7 +108,7 @@
         try {
             List<String> lines = Files.readAllLines(Paths.get(subsystem.path(), param));
             for (String line: lines) {
-                if (line.contains(match)) {
+                if (line.startsWith(match)) {
                     retval = conversion.apply(line);
                     break;
                 }

Under docker we typically only see a single block I/O device so 
the test passed since both lines containing ?Total? are the same value.

8:16 Read 4452352
8:16 Write 0
8:16 Sync 0
8:16 Async 4452352
8:16 Total 4452352
Total 4452352

It?s possible and likely that there will be multiple devices causing failures
since the test and the Metrics API are not examining the same lines.

249:0 Read 10477568
249:0 Write 294431895552
249:0 Sync 17292476416
249:0 Async 277149896704
249:0 Total 294442373120 <??? The API was returning this
8:16 Read 19017216
8:16 Write 326780178432
8:16 Sync 17398915072
8:16 Async 309400280576
8:16 Total 326799195648
8:0 Read 27092992
8:0 Write 31070281728
8:0 Sync 10728873984
8:0 Async 20368500736
8:0 Total 31097374720
Total 652338943488 <?? Test test was comparing to this

We are after the line that ?startsWith? ?Total?.

Bob.


From Roger.Riggs at oracle.com  Tue May  7 20:39:35 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 7 May 2019 16:39:35 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
Message-ID: <e9c71491-fbe0-3874-4f6f-06cc839e5990@oracle.com>

Hi,

Additional comments/observations on the jpackage webrev.
Cleanup opportunities for more maintainable code.


When using the ToolProvider API in an application that has a security 
manager,
what permissions must be available?? Properties, files, ...?


Main:

 ?91: "processArguments" seems misnamed for the method that does 
*everything*.

BundleParams:

 ?- 116: Why type-variable "C" instead of the conventional T?

StandardBundlerParam:

 ?- Many unused imports (according to IntelliJ) including some in the 
same jdk.jpackage.internal that are not needed.

138: TODO and typo in comment.
148:? when does the pathSep get replaced with spaces?? Will that cause 
an issue in re-parsing the string?

661-662: escaped is never set to true,? so escaping is not supported?

747: System.getProperty can require permissions to get properties if run 
under a security manager.

CLIHelp:
 ?- 58, 65, 72, 80: Indentation of pLaunchOptions does not line up.

IOUtils:
 ?- 262: why the mix of ProcessBuilder and Runtime.exec? - stick to 
ProcessBuilder

Log:
 ?? "JPACKAGE_DEBUG" environment variable - ? uppercase, documented?

ValidOptions: 46: typo in comment:? "in the a"

VersionExtractor.java seems to be dead code.

Dead code in RelativeFileset:? upshift(), contains(), copy constructor().

Platform.java:
 ?- should use System Runtime.Version class.

Params.java: Dead code? does not seem to be used in DeployParams
 ? (and would probably be better as a map than an individual object).
 ?? setParams is unused.

DeployParams:

 ?- If there are accessor methods, use them!

 ?- Lots of unused methods. (According to IntelliJ)

 ?- setSystemWide should use primitive boolean, not Boolean; conversions 
will be done as needed.

 ?- Ditto installDirChooser

 ?- Ditto SignBundle flag

Many .java files that pass a map of parameters use the argument name "p" 
but using "params"
would communicate better and be more consistent across the different files.

LinuxDebBundler and LinuxRpmBundler should share more code.

MacAppBundler.java:
 ?- list of categories will need maintenance to stay in sync with 
Apple.? Can the list be derived from the installed Mac tool chain?
 ?- or don't validate the argument until it is built and let the mac app 
builder do the checking.

Regards, Roger


On 04/29/2019 05:58 PM, Andy Herrick wrote:
> jpackage reviewers:
>
> We hope to move JEP 343 to "Proposed to Target" next week, so we would 
> like expedite the review process as much as possible.
>


From naoto.sato at oracle.com  Tue May  7 20:43:54 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 7 May 2019 13:43:54 -0700
Subject: <i18n dev> [13] RFR: 8221432: Upgrade CLDR to Version 35.1
In-Reply-To: <18F4381E-FBD2-4306-B5BB-F69CA847943D@icu-project.org>
References: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com>
 <18F4381E-FBD2-4306-B5BB-F69CA847943D@icu-project.org>
Message-ID: <43c14b37-26ba-34ee-6415-b7ca572ac0a4@oracle.com>

Hi Steven,

Thanks for your comments. My comments are embedded below.

On 5/7/19 1:32 PM, Steven R. Loomis wrote:
> Hi Naoto,
>  ? The comment in 
> http://cr.openjdk.java.net/~naoto/8221432/webrev.02/make/jdk/src/classes/build/tools/cldrconverter/Bundle.java.udiff.html 
> "fix up 'Reiwa' era, which can be missing in some locales? seems to 
> imply that fallback resolution isn?t working properly, because that data 
> (R) is present in root.xml.
> 

Right. Currently it is a known restriction, as Java holds the Japanese 
era names as a string array in the resource bundle, and it won't 
fallback per array elements. Thus it is fixed using the names in root on 
resource bundle generation.

>  ?The deleted comment in the same file, "Some locale data has no default 
> script for numbering even with mutiple scripts? is not true for the same 
> reason.

Contrary to the above, now this is working as you would expect as this 
is a single resource bundle element. If the default numbering system is 
missing, it is retrieved from the parent resource bundle (thus the 
comment is deleted).

Naoto

> 
>  ?Otherwise the changes look as expected on a spot check.
> 
> --
> Steven R. Loomis | @srl295 | git.io/srl295 <http://git.io/srl295>
> 
> 
> 
>> El may. 7, 2019, a las 1:12 p. m., naoto.sato at oracle.com 
>> <mailto:naoto.sato at oracle.com> escribi?:
>>
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8221432
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8221432/webrev.02/
>>
>> The webrev is big, but the large amount of the changes is simply 
>> replacing the CLDR data files from v33 to v35.1, which includes the 
>> translations for the Japanese new era, Reiwa.
>>
>> Naoto
> 

From mikhailo.seledtsov at oracle.com  Tue May  7 20:51:16 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Tue, 7 May 2019 13:51:16 -0700
Subject: RFR: 8222533 - jtreg test
 jdk/internal/platform/cgroup/TestCgroupMetrics.java fails on SLES12.3 linux
 ppc64le machine
In-Reply-To: <76D43E76-B917-4EF5-9C30-B94F3DD8BC18@oracle.com>
References: <76D43E76-B917-4EF5-9C30-B94F3DD8BC18@oracle.com>
Message-ID: <ab0a4ab8-78cc-9705-cc3a-0df52109e492@oracle.com>

Looks good,

Misha


On 5/7/19 1:25 PM, Bob Vandette wrote:
> Please review this simple fix for a TestCgroupMetrics.java test failure.
>
> --- a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
> +++ b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
> @@ -108,7 +108,7 @@
>           try {
>               List<String> lines = Files.readAllLines(Paths.get(subsystem.path(), param));
>               for (String line: lines) {
> -                if (line.contains(match)) {
> +                if (line.startsWith(match)) {
>                       retval = conversion.apply(line);
>                       break;
>                   }
>
> Under docker we typically only see a single block I/O device so
> the test passed since both lines containing ?Total? are the same value.
>
> 8:16 Read 4452352
> 8:16 Write 0
> 8:16 Sync 0
> 8:16 Async 4452352
> 8:16 Total 4452352
> Total 4452352
>
> It?s possible and likely that there will be multiple devices causing failures
> since the test and the Metrics API are not examining the same lines.
>
> 249:0 Read 10477568
> 249:0 Write 294431895552
> 249:0 Sync 17292476416
> 249:0 Async 277149896704
> 249:0 Total 294442373120 <??? The API was returning this
> 8:16 Read 19017216
> 8:16 Write 326780178432
> 8:16 Sync 17398915072
> 8:16 Async 309400280576
> 8:16 Total 326799195648
> 8:0 Read 27092992
> 8:0 Write 31070281728
> 8:0 Sync 10728873984
> 8:0 Async 20368500736
> 8:0 Total 31097374720
> Total 652338943488 <?? Test test was comparing to this
>
> We are after the line that ?startsWith? ?Total?.
>
> Bob.
>


From mikhailo.seledtsov at oracle.com  Tue May  7 20:55:24 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Tue, 7 May 2019 13:55:24 -0700
Subject: RFR: 8222533 - jtreg test
 jdk/internal/platform/cgroup/TestCgroupMetrics.java fails on SLES12.3 linux
 ppc64le machine
In-Reply-To: <ab0a4ab8-78cc-9705-cc3a-0df52109e492@oracle.com>
References: <76D43E76-B917-4EF5-9C30-B94F3DD8BC18@oracle.com>
 <ab0a4ab8-78cc-9705-cc3a-0df52109e492@oracle.com>
Message-ID: <b68ca144-4b91-d7f0-ac11-e4d5e18195bc@oracle.com>

Please make sure to update copyright year on the SubSystem.java before 
integration.

Thank you,

Misha


On 5/7/19 1:51 PM, mikhailo.seledtsov at oracle.com wrote:
> Looks good,
>
> Misha
>
>
> On 5/7/19 1:25 PM, Bob Vandette wrote:
>> Please review this simple fix for a TestCgroupMetrics.java test failure.
>>
>> --- 
>> a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
>> +++ 
>> b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
>> @@ -108,7 +108,7 @@
>> ????????? try {
>> ????????????? List<String> lines = 
>> Files.readAllLines(Paths.get(subsystem.path(), param));
>> ????????????? for (String line: lines) {
>> -??????????????? if (line.contains(match)) {
>> +??????????????? if (line.startsWith(match)) {
>> ????????????????????? retval = conversion.apply(line);
>> ????????????????????? break;
>> ????????????????? }
>>
>> Under docker we typically only see a single block I/O device so
>> the test passed since both lines containing ?Total? are the same value.
>>
>> 8:16 Read 4452352
>> 8:16 Write 0
>> 8:16 Sync 0
>> 8:16 Async 4452352
>> 8:16 Total 4452352
>> Total 4452352
>>
>> It?s possible and likely that there will be multiple devices causing 
>> failures
>> since the test and the Metrics API are not examining the same lines.
>>
>> 249:0 Read 10477568
>> 249:0 Write 294431895552
>> 249:0 Sync 17292476416
>> 249:0 Async 277149896704
>> 249:0 Total 294442373120 <??? The API was returning this
>> 8:16 Read 19017216
>> 8:16 Write 326780178432
>> 8:16 Sync 17398915072
>> 8:16 Async 309400280576
>> 8:16 Total 326799195648
>> 8:0 Read 27092992
>> 8:0 Write 31070281728
>> 8:0 Sync 10728873984
>> 8:0 Async 20368500736
>> 8:0 Total 31097374720
>> Total 652338943488 <?? Test test was comparing to this
>>
>> We are after the line that ?startsWith? ?Total?.
>>
>> Bob.
>>
>


From brent.christian at oracle.com  Tue May  7 23:33:40 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 7 May 2019 16:33:40 -0700
Subject: RFR (M): JDK-6394757: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <a55aaa5c-d530-4080-06c5-887af283bec0@oracle.com>
References: <a55aaa5c-d530-4080-06c5-887af283bec0@oracle.com>
Message-ID: <6e929517-702c-e1e1-9b7a-baf6a1c29d08@oracle.com>

Hi, Stuart.

That all looks pretty good to me.  I think, "membership semantics" is a 
good term.

Just a few minor comments:

Collection.java:

  110  * that use different membership semantics. For operations that 
involve more than
  111  * one collection, it is specified which collection's membership 
semantics are
  112  * used by the operation.

addAll() and copyOf() involve more than one collection, though I agree 
that they do not need to be updated to specify membership semantics.


AbstractCollection.java:


404 * obtaining an iterator from the {@code iterator} method. Each element
405 * is passed to the {@code contains} method of the specified collection.
406 * If this call returns {@code false}, the element is removed from
          ^^^^^^^^^

Is "this call" a little ambiguous?  Maybe:

"If contains() returns false..."
or
"If false is returned..."

?

List.java:

Should containsAll(), removeAll(), retainAll() have the @implNote about 
contains() performance?

Thanks,
-Brent

On 5/2/19 6:36 PM, Stuart Marks wrote:
> Hi all,
> 
> Please review these spec and implementation changes to remove the 
> "optimization" to AbstractSet.removeAll. Briefly, this method was 
> specified (and implemented) to iterate one collection or the other 
> depending on the relative sizes of the collections. The problem is that 
> this would cause an unexpected semantic shift, since one or the other 
> collection's contains() method would be called depending on their 
> relative sizes, and the contains() methods might implement different 
> semantics depending upon the kind of collection.
> 
> The fix is to remove the specification and implementation of 
> AbstractSet.removeAll and to inherit AbstractCollection.removeAll, which 
> does the iteration one way consistently.
> 
> I've removed overriding removeAll method implementations from 
> IdentityHashMap's view sets which were added in order to avoid the 
> "optimization" inherited from AbstractSet.removeAll.
> 
> I've added some words to the Collection interface to introduce the term 
> "membership semantics" for a concept that's been around for a long time 
> but which never had a name, essentially the contains() method. I've then 
> updated the specifications of containsAll, removeAll, retainAll, and 
> (where necessary) equals to specify which collection's membership 
> semantics are used.
> 
> Finally, since this change may introduce some performance issues the 
> optimization was intended to avoid, I've added some implementation notes 
> to the various methods to warn about potential performance issues if 
> this collection's (or the other's) contains() method is linear or worse.
> 
> There have been various discussions in the past (see JDK-8178425 for 
> example) that propose optimizations to the various bulk operations. They 
> usually involve modifying the decision criteria for iterating this 
> collection vs iterating the other collection. However, as we concluded 
> previously, doing this introduces semantic problems. Another approach to 
> optimizating the bulk cases is to copy the other collection into an 
> intermediate collection that has an O(1) contains() method; however, 
> this also changes the semantics and thus must be ruled out. Such 
> approaches should be left to the caller.
> 
> Bug:
> 
>  ??? https://bugs.openjdk.java.net/browse/JDK-6394757
> 
> Previous discussions:
> 
>      
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html 
> 
>      
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html 
> 
> 
>  ??? (see also additional bugs and linked to the above bug)
> 
> Webrev:
> 
>  ??? http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.0/
> 
> Thanks,
> 
> s'marks

From mikhailo.seledtsov at oracle.com  Wed May  8 00:49:30 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Tue, 7 May 2019 17:49:30 -0700
Subject: RFR: 8221340 - [TESTBUG] TestCgroupMetrics.java fails after fix
 for JDK-8219562
In-Reply-To: <96BEE19C-9950-48E9-9B11-9EA6EADE9123@oracle.com>
References: <96BEE19C-9950-48E9-9B11-9EA6EADE9123@oracle.com>
Message-ID: <d5e50bb5-7752-2437-1583-27391afa85ca@oracle.com>

Changes look good to me,

Misha


On 5/7/19 5:56 AM, Bob Vandette wrote:
> Please review this change to the Container Metrics implementation.
>
> Change were made in JDK-8219562 [1] to osContainer_linux.cpp to correct
> the parsing of of the /proc/self/mountinfo file but corresponding changes to the
> Metrics API and Container tests shou,d have been done to match this change.
>
> BUG:
> https://bugs.openjdk.java.net/browse/JDK-8221340
>
> WEBREV:
> http://cr.openjdk.java.net/~bobv/8221340/webrev.00/
>
> TESTING:
> These changes were verified by running Mach5  tier1 and 2 tests and the jtreg container
> tests on a Linux x64 system.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8219562
>
> Bob.
>


From Sergey.Bylokhov at oracle.com  Wed May  8 02:47:24 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 7 May 2019 19:47:24 -0700
Subject: <AWT Dev> RFR: 8212700: Change the mechanism by which JDK loads
 the platform-specific AWT Toolkit
In-Reply-To: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com>
References: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com>
Message-ID: <2dca6e1f-2eda-96bf-ce02-cc3205f6a393@oracle.com>

Hi, Phil.

Looks fine, but probably it will be worth to rename PlatformGraphicsInfo to PlatformInfo?

On 06/05/2019 15:11, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8212700
> CSR: https://bugs.openjdk.java.net/browse/JDK-8223417
> Webrev: https://cr.openjdk.java.net/~prr/8212700
> 
> Please review this bug + CSR to remove the awt.headless system property.
> 
> This should be the last of the fixes to remove use of system
> properties set in the launcher to specify per-platform
> internal classes and/or behaviours of the java.desktop module.
> 
> Half of the change is removing code from the launcher, and
> then some small changes in Toolkit.java to consult a new
> method in the per-platform internal PlatformGraphicsInfo.java class.
> 
> However it was also necessary to update each of the platform toolkit class
> constructor code since they all get/set a system property to support
> extra mouse buttons (I don't know why this could not be shared in
> SunToolkit but that is another matter than this fix), and two of them
> access the root thread group. Previously they inherited privileges
> from the code in java.awt.Toolkit which instantiated them but now
> they need to assert the privileges directly - at to the point of use.
> 
> As well as adding a simple new regression test, all the automated
> headless tests and many automated headful tests were run as well
> as basic manual testing.
> 
> The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit()
> 
> -phil


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed May  8 03:29:52 2019
From: philip.race at oracle.com (Philip Race)
Date: Tue, 07 May 2019 20:29:52 -0700
Subject: <AWT Dev> RFR: 8212700: Change the mechanism by which JDK loads
 the platform-specific AWT Toolkit
In-Reply-To: <2dca6e1f-2eda-96bf-ce02-cc3205f6a393@oracle.com>
References: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com>
 <2dca6e1f-2eda-96bf-ce02-cc3205f6a393@oracle.com>
Message-ID: <5CD24D30.8040106@oracle.com>



On 5/7/19, 7:47 PM, Sergey Bylokhov wrote:
> Hi, Phil.
>
> Looks fine, but probably it will be worth to rename 
> PlatformGraphicsInfo to PlatformInfo?

I don't want (or intend) to do that. I already knew I was going
to re-use this class for this purpose when I created it and adjusted
the classname then to be reasonably acceptable. There is no ideal
and PlatformInfo isn't it either.

-phil.

>
> On 06/05/2019 15:11, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212700
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223417
>> Webrev: https://cr.openjdk.java.net/~prr/8212700
>>
>> Please review this bug + CSR to remove the awt.headless system property.
>>
>> This should be the last of the fixes to remove use of system
>> properties set in the launcher to specify per-platform
>> internal classes and/or behaviours of the java.desktop module.
>>
>> Half of the change is removing code from the launcher, and
>> then some small changes in Toolkit.java to consult a new
>> method in the per-platform internal PlatformGraphicsInfo.java class.
>>
>> However it was also necessary to update each of the platform toolkit 
>> class
>> constructor code since they all get/set a system property to support
>> extra mouse buttons (I don't know why this could not be shared in
>> SunToolkit but that is another matter than this fix), and two of them
>> access the root thread group. Previously they inherited privileges
>> from the code in java.awt.Toolkit which instantiated them but now
>> they need to assert the privileges directly - at to the point of use.
>>
>> As well as adding a simple new regression test, all the automated
>> headless tests and many automated headful tests were run as well
>> as basic manual testing.
>>
>> The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit()
>>
>> -phil
>
>

From david.holmes at oracle.com  Wed May  8 03:36:50 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 8 May 2019 13:36:50 +1000
Subject: RFR: 8222533 - jtreg test
 jdk/internal/platform/cgroup/TestCgroupMetrics.java fails on SLES12.3 linux
 ppc64le machine
In-Reply-To: <76D43E76-B917-4EF5-9C30-B94F3DD8BC18@oracle.com>
References: <76D43E76-B917-4EF5-9C30-B94F3DD8BC18@oracle.com>
Message-ID: <fe3cc5be-7d5b-3da0-bed3-5ad0d9828e87@oracle.com>

Hi Bob,

This fix seems quite reasonable.

Thanks,
David

On 8/05/2019 6:25 am, Bob Vandette wrote:
> Please review this simple fix for a TestCgroupMetrics.java test failure.
> 
> --- a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
> +++ b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
> @@ -108,7 +108,7 @@
>           try {
>               List<String> lines = Files.readAllLines(Paths.get(subsystem.path(), param));
>               for (String line: lines) {
> -                if (line.contains(match)) {
> +                if (line.startsWith(match)) {
>                       retval = conversion.apply(line);
>                       break;
>                   }
> 
> Under docker we typically only see a single block I/O device so
> the test passed since both lines containing ?Total? are the same value.
> 
> 8:16 Read 4452352
> 8:16 Write 0
> 8:16 Sync 0
> 8:16 Async 4452352
> 8:16 Total 4452352
> Total 4452352
> 
> It?s possible and likely that there will be multiple devices causing failures
> since the test and the Metrics API are not examining the same lines.
> 
> 249:0 Read 10477568
> 249:0 Write 294431895552
> 249:0 Sync 17292476416
> 249:0 Async 277149896704
> 249:0 Total 294442373120 <??? The API was returning this
> 8:16 Read 19017216
> 8:16 Write 326780178432
> 8:16 Sync 17398915072
> 8:16 Async 309400280576
> 8:16 Total 326799195648
> 8:0 Read 27092992
> 8:0 Write 31070281728
> 8:0 Sync 10728873984
> 8:0 Async 20368500736
> 8:0 Total 31097374720
> Total 652338943488 <?? Test test was comparing to this
> 
> We are after the line that ?startsWith? ?Total?.
> 
> Bob.
> 

From Sergey.Bylokhov at oracle.com  Wed May  8 06:38:02 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 7 May 2019 23:38:02 -0700
Subject: <AWT Dev> RFR: 8212700: Change the mechanism by which JDK loads
 the platform-specific AWT Toolkit
In-Reply-To: <5CD24D30.8040106@oracle.com>
References: <1c8f20b7-cba3-0978-d805-4465c1e80fb2@oracle.com>
 <2dca6e1f-2eda-96bf-ce02-cc3205f6a393@oracle.com>
 <5CD24D30.8040106@oracle.com>
Message-ID: <8ca7dc39-1cce-0da8-8e75-57e73f9e2418@oracle.com>

OK, looks fine then.

> On 5/7/19, 7:47 PM, Sergey Bylokhov wrote:
>> Hi, Phil.
>>
>> Looks fine, but probably it will be worth to rename PlatformGraphicsInfo to PlatformInfo?
> 
> I don't want (or intend) to do that. I already knew I was going
> to re-use this class for this purpose when I created it and adjusted
> the classname then to be reasonably acceptable. There is no ideal
> and PlatformInfo isn't it either.
> 
> -phil.
> 
>>
>> On 06/05/2019 15:11, Phil Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212700
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223417
>>> Webrev: https://cr.openjdk.java.net/~prr/8212700
>>>
>>> Please review this bug + CSR to remove the awt.headless system property.
>>>
>>> This should be the last of the fixes to remove use of system
>>> properties set in the launcher to specify per-platform
>>> internal classes and/or behaviours of the java.desktop module.
>>>
>>> Half of the change is removing code from the launcher, and
>>> then some small changes in Toolkit.java to consult a new
>>> method in the per-platform internal PlatformGraphicsInfo.java class.
>>>
>>> However it was also necessary to update each of the platform toolkit class
>>> constructor code since they all get/set a system property to support
>>> extra mouse buttons (I don't know why this could not be shared in
>>> SunToolkit but that is another matter than this fix), and two of them
>>> access the root thread group. Previously they inherited privileges
>>> from the code in java.awt.Toolkit which instantiated them but now
>>> they need to assert the privileges directly - at to the point of use.
>>>
>>> As well as adding a simple new regression test, all the automated
>>> headless tests and many automated headful tests were run as well
>>> as basic manual testing.
>>>
>>> The CSR also covers updating the javadoc of Toolkit.getDefaultToolkit()
>>>
>>> -phil
>>
>>


-- 
Best regards, Sergey.

From christoph.langer at sap.com  Wed May  8 08:02:58 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 8 May 2019 08:02:58 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
Message-ID: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

please review a small change that I'd like to see in OpenJDK to get rid of compilation errors in the Eclipse IDE.

It seems the root cause for the compilation errors is that javac would sometimes widen capture variables and is hence able to compile the places that I touch here. The EC4J compiler claims that it's following the spec more strictly and bails out at these places. I had posted about this on compiler-dev but got no reaction [0].

So, as this seems to be some field of open work for the compiler/spec folks, I'd like to get EC4J quiesced by introducing some slight modifications to the original places which makes the code appeal a bit less elegant and fluent but will get rid of the compile errors.

Please review:
Bug: https://bugs.openjdk.java.net/browse/JDK-8223553
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/

The modification to src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java belongs to JSR-166, so I don't know if it needs some special handling.

Thanks & Best regards
Christoph

[0] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013054.html


From adam.farley at uk.ibm.com  Wed May  8 12:43:12 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Wed, 8 May 2019 13:43:12 +0100
Subject: RFR: JDK-8222930: ConcurrentSkipListMapTest.clone() broken since
 jdk10
In-Reply-To: <CA+kOe0_UdjSzKCR2siuarg+S5CFeByt3n32WLgV8HxnVoX2d=A@mail.gmail.com>
References: <OF0F3C0275.09074503-ON002583E6.005924D3-802583E6.0059CA9B@notes.na.collabserv.com>
 <c20351a5-1162-1372-d5c4-819239ac6d0f@oracle.com>
 <OFDCA121B3.C010014C-ON002583E7.00460715-802583E7.00463DFA@LocalDomain>
 <OFCC74609B.71E17DFC-ON002583EB.0034F227-802583EB.003866E6@notes.na.collabserv.com>
 <CA+kOe0_UdjSzKCR2siuarg+S5CFeByt3n32WLgV8HxnVoX2d=A@mail.gmail.com>
Message-ID: <OFF23D1D99.375A50A0-ON002583F4.0045D3C1-802583F4.0045E0B1@notes.na.collabserv.com>

Good job. :)

On to the next bug! Hehe.

Best Regards

Adam Farley 
IBM Runtimes


Martin Buchholz <martinrb at google.com> wrote on 07/05/2019 19:46:26:

> From: Martin Buchholz <martinrb at google.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>
> Cc: Java Core Libs <core-libs-dev at openjdk.java.net>
> Date: 07/05/2019 19:46
> Subject: Re: RFR: JDK-8222930: ConcurrentSkipListMapTest.clone() 
> broken since jdk10
> 
> Thanks!  Fix is now committed to jdk11, jdk12, jdk13.
> 
> From: Adam Farley8 <adam.farley at uk.ibm.com>
> Date: Mon, Apr 29, 2019 at 3:16 AM
> To: <martinrb at google.com>
> Cc: Java Core Libs

> Hi All, 
> 
> Reviews and feedback requested for the fix. 
> 
> http://cr.openjdk.java.net/~afarley/8222930.1/jdk13/webrev 
> 
> Martin: Thanks for the testcase. I've replaced the old test in the 
> webrev with your generalized one. :) 
> 
> Best Regards
> 
> Adam Farley 
> IBM Runtimes
> 
> 
> Adam Farley8/UK/IBM wrote on 25/04/2019 13:47:13:
> 
> > From: Adam Farley8/UK/IBM 
> > To: Stuart Marks <stuart.marks at oracle.com> 
> > Cc: Java Core Libs <core-libs-dev at openjdk.java.net> 
> > Date: 25/04/2019 13:47 
> > Subject: Re: RFR: JDK-8222930: ConcurrentSkipListMapTest.clone() 
> > broken since jdk10 
> > 
> > Hi Stuart, 
> > 
> > Whoops, typo. Thanks for catching that. 
> > 
> > Ditto for Martin, who has modified the bug. :)
> > 
> > Best Regards
> > 
> > Adam Farley 
> > IBM Runtimes
> 
> > 
> > Stuart Marks <stuart.marks at oracle.com> wrote on 24/04/2019 17:59:17:
> > 
> > > From: Stuart Marks <stuart.marks at oracle.com> 
> > > To: Adam Farley8 <adam.farley at uk.ibm.com> 
> > > Cc: Java Core Libs <core-libs-dev at openjdk.java.net> 
> > > Date: 24/04/2019 17:59 
> > > Subject: Re: RFR: JDK-8222930: ConcurrentSkipListMapTest.clone() 
> > > broken since jdk10 
> > > 
> > > Hi Adam,
> > > 
> > > Thanks for finding this bug!
> > > 
> > > This is a bug in ConcurrentSkipListMap itself, not some test named 
> > > ConcurrentSkipListMapTest. I'd suggest changing the bug summary 
> > line and the 
> > > commit message accordingly.
> > > 
> > > Thanks,
> > > 
> > > s'marks
> > > 
> > > On 4/24/19 9:20 AM, Adam Farley8 wrote:
> > > > ConcurrentSkipListMapTest.clone() produces a clone that sharesthe 
array
> > > > size variable of the original, and then doubles it.
> > > > 
> > > > So both arrays, original and clone, tell the user that each is 
twice as
> > > > big as it actually is.
> > > > 
> > > > The proposed fix is to simply set the clone's array size 
> variable to null
> > > > during creation.
> > > > 
> > > > Fix and test code available.
> > > > 
> > > > Reviews and sponsor requested.
> > > > 
> > > > Webrev: https://urldefense.proofpoint.com/v2/url?
> > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8222930.
> > > 0_jdk13_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-
> > > 
> > 
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=9_BHLxc2OwO4OJABunATso0Ej3_keQ0c5uQJZ4AwSfk&s=0gBgd8gUhNlM26eNWxBbpnIAsFJPwnOtsmT6qH72NPM&e=
> > > > 
> > > > Bug: https://urldefense.proofpoint.com/v2/url?
> > > 
> > 
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8222930&d=DwICaQ&c=jf_iaSHvJObTbx-
> > > siA1ZOg&r=P5m8KWUXJf-
> > > 
> > 
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=9_BHLxc2OwO4OJABunATso0Ej3_keQ0c5uQJZ4AwSfk&s=vNk7C72hr8FqiYLJEVvCR69vlhPuT7zSIAiJ9Tl91JQ&e=
> > > > 
> > > > Best Regards
> > > > 
> > > > Adam Farley
> > > > IBM Runtimes
> > > > 
> > > > P.S. Apparently this has been broken since JDK 10, so we should 
look at
> > > > backporting (at least to 11 and 12) once this is in.
> > > > 
> > > > Unless stated otherwise above:
> > > > IBM United Kingdom Limited - Registered in England and Wales with 
number
> > > > 741598.
> > > > Registered office: PO Box 41, North Harbour, Portsmouth, 
> Hampshire PO6 3AU
> > > > 
> > > 
> > 
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with 
> > number 741598. 
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
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 sergei.tsypanov at yandex.ru  Wed May  8 12:55:45 2019
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Wed, 08 May 2019 14:55:45 +0200
Subject: inconsistency between ArrayList.modCount and logic of
 ArrayList::addAll
Message-ID: <8678411557320145@myt5-9da6df248f4a.qloud-c.yandex.net>

Hello,

javadoc for AbstractList.modCount is described as 

> The number of times this list has been <i>structurally modified</i>.
> Structural modifications are those that change the size of the
> list, or otherwise perturb it in such a fashion that iterations in
> progress may yield incorrect results.

However when we execute this

------------------------
ArrayList<Object> objects = new ArrayList<>();
boolean result = objects.addAll(Collections.emptyList());
------------------------

modCount is 1, not 0 while result is false. I.e. returned value claims the list is not modified, but the inner state of the same list demonstrates the opposite.

The reason is implementation of List::addAll method:

public boolean addAll(Collection<? extends E> c) {
    Object[] a = c.toArray();
    modCount++;                                                                         // <------
    int numNew = a.length;
    if (numNew == 0)
        return false;                                                                        // <------
    Object[] elementData;
    final int s;
    if (numNew > (elementData = this.elementData).length - (s = size))
        elementData = grow(s + numNew);
    System.arraycopy(a, 0, elementData, s, numNew);
    size = s + numNew;
    return true;
}

I think modCount++;  should be placed after value of numNew is checked. Then it's incremented only when underlying array is actually changed.

Regards,

Sergei Tsypanov

From bob.vandette at oracle.com  Wed May  8 14:24:24 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 8 May 2019 10:24:24 -0400
Subject: RFR: 8221340 - [TESTBUG] TestCgroupMetrics.java fails after fix
 for JDK-8219562
In-Reply-To: <d5e50bb5-7752-2437-1583-27391afa85ca@oracle.com>
References: <96BEE19C-9950-48E9-9B11-9EA6EADE9123@oracle.com>
 <d5e50bb5-7752-2437-1583-27391afa85ca@oracle.com>
Message-ID: <72AC2E0E-DECA-4F48-83E6-B05E1D32B981@oracle.com>

Thanks Misha!

Could I get a ?Review? from someone in core libs, please?

Bob.

> On May 7, 2019, at 8:49 PM, mikhailo.seledtsov at oracle.com wrote:
> 
> Changes look good to me,
> 
> Misha
> 
> 
> On 5/7/19 5:56 AM, Bob Vandette wrote:
>> Please review this change to the Container Metrics implementation.
>> 
>> Change were made in JDK-8219562 [1] to osContainer_linux.cpp to correct
>> the parsing of of the /proc/self/mountinfo file but corresponding changes to the
>> Metrics API and Container tests shou,d have been done to match this change.
>> 
>> BUG:
>> https://bugs.openjdk.java.net/browse/JDK-8221340
>> 
>> WEBREV:
>> http://cr.openjdk.java.net/~bobv/8221340/webrev.00/
>> 
>> TESTING:
>> These changes were verified by running Mach5  tier1 and 2 tests and the jtreg container
>> tests on a Linux x64 system.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8219562
>> 
>> Bob.
>> 
> 


From pavel.rappo at oracle.com  Wed May  8 14:44:56 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 8 May 2019 15:44:56 +0100
Subject: inconsistency between ArrayList.modCount and logic of
 ArrayList::addAll
In-Reply-To: <8678411557320145@myt5-9da6df248f4a.qloud-c.yandex.net>
References: <8678411557320145@myt5-9da6df248f4a.qloud-c.yandex.net>
Message-ID: <B8718703-47CA-4A80-9BEC-93C3B025A2F9@oracle.com>

We will certainly hear from Stuart on this very soon. Meanwhile, I have to say
that the situation you've described is not that clear-cut in my opinion.

I understand there might be a discrepancy between how the `modCount` field is
described and how it is actually used.

Incrementing `modCount` unconditionally makes more sense to me. The whole
purpose of this mechanism is to fail fast, exposing possible bugs in the client
code. I believe it should be incremented on an attempt to modify the collection,
rather than on the effective result of that attempt.

It's somewhat similar to the following question: should Collections.emptyList
(or Collections.emptySet) throw an exception on an attempt to call `clear` (or
`remove(e)` where `e` is not a member of the said collection)?

-Pavel



From claes.redestad at oracle.com  Wed May  8 14:49:34 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 8 May 2019 16:49:34 +0200
Subject: RFR: 8223454: Reduce String concatenation shapes by folding
 initialLengthCoder into last mixer
Message-ID: <9356390f-7c52-3b2e-9a13-620b92bfb023@oracle.com>

Hi,

yet another String concat startup/footprint optimization.

As the subject implies, we could fold the initialLengthCoder it into the
final mixer. This way we end up with one less bound argument into the
larger method handle combinator tree, with fewer species classes and
lambda forms generated as a result. This means a significant speed-up on
several startup and footprint tests, and especially noticeable on
realistic workloads that just have a few different small concat shapes.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8223454
Webrev: http://cr.openjdk.java.net/~redestad/8223454/open.00/

Thanks!

/Claes

From coleen.phillimore at oracle.com  Wed May  8 15:31:37 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 8 May 2019 11:31:37 -0400
Subject: RFR(L): 8218628: Add detailed message to NullPointerException
 describing what is null.
In-Reply-To: <VI1PR02MB44636E249A2445FF4B538871EC310@VI1PR02MB4463.eurprd02.prod.outlook.com>
References: <7c4b0bc27961471e91195bef9e767226@sap.com>
 <a8b818e8-7833-bd5c-e527-da476d19c7ab@oracle.com>
 <a4b0c569ffd543ee844842f5a3ae64ad@sap.com>
 <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com>
 <bbfd9855f337445f9b0de88048f8e10b@sap.com>
 <d871303ade6c4ec594b55acca0a0ba00@sap.com>
 <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com>
 <e1917533-7298-6008-98a0-d494227e9ea1@oracle.com>
 <3245ec3cefe2471e8382048164c0ba6b@sap.com>
 <DB7PR02MB5178770C575AB211A8D1EEB2EC4B0@DB7PR02MB5178.eurprd02.prod.outlook.com>
 <VI1PR02MB51835505401202E32518CD67EC280@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB4463E8CA5B15844849D0C011EC300@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <AM0PR02MB450071BA4ECF288D0D68F7409F310@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <VI1PR02MB44636E249A2445FF4B538871EC310@VI1PR02MB4463.eurprd02.prod.outlook.com>
Message-ID: <538ca28f-333f-3a2b-d661-1f1454953b79@oracle.com>



On 5/7/19 9:36 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> Please have a look at this further improved webrev:
> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09/
> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09-incremental/
>
> Harold, Coleen, thanks for pointing me to those methods.
> I'm using them now. This simplifies the helper methods
> considerably.
>
> Ralf, thanks for looking at the messages!
> I now suppress the "static " and
> "The return value of '" strings in the array subscript
> expressions and added corresponding test cases.
>
> About "can not" versus "cannot", what I find in the
> net "cannot" is to be preferred.  Any comments on that?
> By native speakers?
> See example messages here:
> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09/output_with_debug_info.txt

Cannot is apparently preferable in English.? Native speaker (only 
language) but somebody had to tell me.

Coleen
>
> Further, I fixed a build issue with the solaris compiler.
> All handling of bci is now unsigned.
>
> Best regards,
>    Goetz.
>
>
>
>
>> -----Original Message-----
>> From: Schmelter, Ralf
>> Sent: Dienstag, 7. Mai 2019 14:35
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Java Core Libs <core-
>> libs-dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net; Coleen
>> Phillimore (coleen.phillimore at oracle.com) <coleen.phillimore at oracle.com>
>> Subject: RE: RFR(L): 8218628: Add detailed message to NullPointerException
>> describing what is null.
>>
>> Hi Goetz,
>>
>> I've played with the messages a little bit and they generally look good. But I've
>> come across two which look strange:
>>   - 'o[static Test.INDEX]' is null. Can not invoke method 'int
>> java.lang.Object.hashCode()'
>>   - 'o[The return value of 'int java.lang.String.hashCode()]' is null. Can not invoke
>> method 'int java.lang.Object.hashCode()'.
>>
>> Here is the test program to reproduce these:
>> public class Test {
>>      public static int INDEX = 2;
>>
>>      public static void main(String[] args) {
>>          Object[] o = new Object[10];
>>          try {
>>               o[INDEX].hashCode();
>>          } catch (Exception e) {
>>              e.printStackTrace();
>>          }
>>          try {
>>               o["".hashCode()].hashCode();
>>          } catch (Exception e) {
>>              e.printStackTrace();
>>          }
>>      }
>> }
>>
>> And 'Can not' should be 'Cannot'?
>>
>> Best regards,
>> Ralf


From srl at icu-project.org  Tue May  7 20:32:32 2019
From: srl at icu-project.org (Steven R. Loomis)
Date: Tue, 7 May 2019 13:32:32 -0700
Subject: <i18n dev> [13] RFR: 8221432: Upgrade CLDR to Version 35.1
In-Reply-To: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com>
References: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com>
Message-ID: <18F4381E-FBD2-4306-B5BB-F69CA847943D@icu-project.org>

Hi Naoto,
  The comment in http://cr.openjdk.java.net/~naoto/8221432/webrev.02/make/jdk/src/classes/build/tools/cldrconverter/Bundle.java.udiff.html "fix up 'Reiwa' era, which can be missing in some locales? seems to imply that fallback resolution isn?t working properly, because that data (R) is present in root.xml.

 The deleted comment in the same file, "Some locale data has no default script for numbering even with mutiple scripts? is not true for the same reason.

 Otherwise the changes look as expected on a spot check.

--
Steven R. Loomis | @srl295 | git.io/srl295



> El may. 7, 2019, a las 1:12 p. m., naoto.sato at oracle.com escribi?:
> 
> Hello,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8221432
> 
> The proposed changeset is located at:
> 
> http://cr.openjdk.java.net/~naoto/8221432/webrev.02/
> 
> The webrev is big, but the large amount of the changes is simply replacing the CLDR data files from v33 to v35.1, which includes the translations for the Japanese new era, Reiwa.
> 
> Naoto


From Roger.Riggs at oracle.com  Wed May  8 16:32:12 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 8 May 2019 12:32:12 -0400
Subject: [13] RFR: 8221432: Upgrade CLDR to Version 35.1
In-Reply-To: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com>
References: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com>
Message-ID: <d91f4d90-6e51-f919-ce56-45cb581c270f@oracle.com>

Hi Naoto,

The changes look fine.

Thanks, Roger

On 05/07/2019 04:12 PM, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8221432
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8221432/webrev.02/
>
> The webrev is big, but the large amount of the changes is simply 
> replacing the CLDR data files from v33 to v35.1, which includes the 
> translations for the Japanese new era, Reiwa.
>
> Naoto


From andy.herrick at oracle.com  Wed May  8 20:28:49 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 8 May 2019 16:28:49 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <e9c71491-fbe0-3874-4f6f-06cc839e5990@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
 <e9c71491-fbe0-3874-4f6f-06cc839e5990@oracle.com>
Message-ID: <75e4b0f4-0403-a565-c20d-7143957578af@oracle.com>



On 5/7/2019 4:39 PM, Roger Riggs wrote:
> Hi,
>
> Additional comments/observations on the jpackage webrev.
> Cleanup opportunities for more maintainable code.
>
>
> When using the ToolProvider API in an application that has a security 
> manager,
> what permissions must be available?? Properties, files, ...?
>
>
> Main:
>
> ?91: "processArguments" seems misnamed for the method that does 
> *everything*.
I quite agree. Perhaps this can be done in conjunction with JDK-8223322 
<https://bugs.openjdk.java.net/browse/JDK-8223322> which will revise the 
flow of Main and ToolProvider.
(adding comment in JDK-8223322) 
<https://bugs.openjdk.java.net/browse/JDK-8223322>
>
> BundleParams:
>
> ?- 116: Why type-variable "C" instead of the conventional T?
I don't know the history of this, but it seems reasonable to change to 
"T" like other classes.
(added as a line item 19 in JDK-8223241 
<https://bugs.openjdk.java.net/browse/JDK-8223241>)
>
> StandardBundlerParam:
>
> ?- Many unused imports (according to IntelliJ) including some in the 
> same jdk.jpackage.internal that are not needed.
already listed as item 1 in JDK-8223241 
<https://bugs.openjdk.java.net/browse/JDK-8223241>
>
> 138: TODO and typo in comment.
remove todo - this has been tested
(added line item 20 in JDK-8223241 
<https://bugs.openjdk.java.net/browse/JDK-8223241>)

> 148: when does the pathSep get replaced with spaces?? Will that cause 
> an issue in re-parsing the string?
>
> 661-662: escaped is never set to true,? so escaping is not supported?
need to look into this - (added to JDK-8223334)
>
> 747: System.getProperty can require permissions to get properties if 
> run under a security manager.
Many of the operations performed by jpackage too would require 
all-permissions if run under security manager.
>
> CLIHelp:
> ?- 58, 65, 72, 80: Indentation of pLaunchOptions does not line up.
I don't see what you mean here.? Looks lined up to me
>
> IOUtils:
> ?- 262: why the mix of ProcessBuilder and Runtime.exec? - stick to 
> ProcessBuilder
added to this case to JDK-8223334
>
> Log:
> ?? "JPACKAGE_DEBUG" environment variable - ? uppercase, documented?
implemented as strictly upper case, what do we have to do to document ?
>
> ValidOptions: 46: typo in comment:? "in the a"
several problems with this comment - added to JDK-8223241 
<https://bugs.openjdk.java.net/browse/JDK-8223241>
>
> VersionExtractor.java seems to be dead code.
>
> Dead code in RelativeFileset:? upshift(), contains(), copy constructor().
>
> Platform.java:
> ?- should use System Runtime.Version class.
>
> Params.java: Dead code? does not seem to be used in DeployParams
> ? (and would probably be better as a map than an individual object).
> ?? setParams is unused.
new JBS issue to remove dead code. (JDK-8223586 
<https://bugs.openjdk.java.net/browse/JDK-8223586>)

>
> DeployParams:
>
> ?- If there are accessor methods, use them!
>
> ?- Lots of unused methods. (According to IntelliJ)
>
> ?- setSystemWide should use primitive boolean, not Boolean; 
> conversions will be done as needed.
>
> ?- Ditto installDirChooser
>
> ?- Ditto SignBundle flag
>
> Many .java files that pass a map of parameters use the argument name 
> "p" but using "params"
> would communicate better and be more consistent across the different 
> files.
>
> LinuxDebBundler and LinuxRpmBundler should share more code.
>
> MacAppBundler.java:
> ?- list of categories will need maintenance to stay in sync with 
> Apple.? Can the list be derived from the installed Mac tool chain?
> ?- or don't validate the argument until it is built and let the mac 
> app builder do the checking.
>
All above added to JDK-8223586 
<https://bugs.openjdk.java.net/browse/JDK-8223586>

/Andy

> Regards, Roger
>
>
> On 04/29/2019 05:58 PM, Andy Herrick wrote:
>> jpackage reviewers:
>>
>> We hope to move JEP 343 to "Proposed to Target" next week, so we 
>> would like expedite the review process as much as possible.
>>
>


From lance.andersen at oracle.com  Wed May  8 20:30:54 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 8 May 2019 16:30:54 -0400
Subject: RFR(JDK 13/java.xml) 8222991: Xerces 2.12.0: Validation
In-Reply-To: <5CC774CC.6040008@oracle.com>
References: <5CC774CC.6040008@oracle.com>
Message-ID: <F36A757F-8DFA-4314-98D9-81D7CD3443EF@oracle.com>

Hi Joe,

Sorry for the delay.  The patch looks good.

Best
Lance
> On Apr 29, 2019, at 6:03 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Please review an update on the Validation implementation.  All XML tests and JCK passed.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8222991
> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8222991/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  Wed May  8 20:39:09 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 8 May 2019 13:39:09 -0700
Subject: RFR (M): JDK-6394757: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <CAE+3fjZe5DazuM2Mm1hLp+kZYu+mWjZS6mRF7p6TJb26GL+dFQ@mail.gmail.com>
References: <a55aaa5c-d530-4080-06c5-887af283bec0@oracle.com>
 <CAE+3fjZe5DazuM2Mm1hLp+kZYu+mWjZS6mRF7p6TJb26GL+dFQ@mail.gmail.com>
Message-ID: <3eb5a8ec-51dc-8871-331f-d5df88dd8842@oracle.com>



On 5/3/19 6:20 AM, Tagir Valeev wrote:
> I'm not a Reviewer, but strongly support this change. Simpler is better. Thanks!

[capitalization adjusted]

Hi Tagir,

Thanks for looking at this! I appreciate the review.

As an aside for other readers, there's no requirement that one be a (capital-R) 
Reviewer in order to review code or changes. If you see a mistake or some issue, 
please point it out, even if you're not a Reviewer. This can be a useful 
contribution. The requirement for integration is that there be a review from 
least one Reviewer. There can be any number of reviews from non-Reviewers.

s'marks


From stuart.marks at oracle.com  Wed May  8 20:42:01 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 8 May 2019 13:42:01 -0700
Subject: RFR (M): JDK-6394757: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <8E01DCD7-5C19-417E-8EE5-9D4EF9527024@oracle.com>
References: <a55aaa5c-d530-4080-06c5-887af283bec0@oracle.com>
 <8E01DCD7-5C19-417E-8EE5-9D4EF9527024@oracle.com>
Message-ID: <940482ee-a682-d6ee-47dd-ded6c04468e6@oracle.com>



On 5/7/19 8:21 AM, Pavel Rappo wrote:
> That looks good.
> 
> A tiny note on your FIXME comment [1]:
> 
>    68     // FIXME: the first paragraph below is copied from Set.equals, because
>    69     // {@inheritDoc} will include text from Object.equals.
> 
> You might want to check if it is the same as [2] or [3]. If it is the same,
> consider adding a reference to the appropriate issue to that FIXME comment for
> future maintainers. It looks like there are some problems when inheriting
> documentation from methods defined in java.lang.Object.

> [1] http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.0/src/java.base/share/classes/java/util/AbstractSet.java.sdiff.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8144034
> [3] https://bugs.openjdk.java.net/browse/JDK-6376959

Thanks Pavel. I looked at this and it does seem related to javadoc bug 
JDK-6396959. I've added some notes to that bug report. I'll add a reference to 
this bug report in the changeset near FIXME.

There are a couple other places in the collections doc that have this same 
pathology (i.e., text is copied instead of @inheritDoc). I'll see if I can find 
them and note them with a FIXME as well.

Thanks also for your misc markup changes sent offline.

s'marks

From stuart.marks at oracle.com  Wed May  8 21:01:26 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 8 May 2019 14:01:26 -0700
Subject: RFR(trivial): 8222394: HashMap.compute() throws CME on an empty
 Map if clear() called concurrently
In-Reply-To: <BYAPR01MB50464A5E78FB94F47120851C8F360@BYAPR01MB5046.prod.exchangelabs.com>
References: <BL0PR01MB50445D4086CD13A9785367348F280@BL0PR01MB5044.prod.exchangelabs.com>
 <a4fdb034-df89-9d86-2e53-5413048bd637@oracle.com>
 <BYAPR01MB50464E833DF1E9918A8BE9348F2B0@BYAPR01MB5046.prod.exchangelabs.com>
 <520e1ee0-8f1c-ae46-2b45-24555c88aa05@oracle.com>
 <BYAPR01MB50465E819FB106ACABEC8E998F3D0@BYAPR01MB5046.prod.exchangelabs.com>
 <33a11459-830f-07cd-3ee0-743657f6a6b7@oracle.com>
 <BYAPR01MB50464A5E78FB94F47120851C8F360@BYAPR01MB5046.prod.exchangelabs.com>
Message-ID: <2434bc38-cc3f-b668-f95a-7994563de058@oracle.com>



On 5/4/19 12:21 AM, Patrick Zhang OS wrote:
> Thank you very much for the detailed explanation and examples, which solved most of my previous questions and confusion. Really appreciate that. I agree with the opinion about "effort vs benefit".
> 
> Re-thought my original tests concerning CMEs that passed with jdk8u but failed with jdk11 (should be 9+, but I only checked LTS builds), I was struggling between "fixing" the "problems" in jdk11 and "making jdk8 fail similarly". However so far it looks these tests might be over strict, or "verifying CMEs" itself might be an invalid (or unreliable) operation, perhaps I should drop all of them. Lastly, a suggestion would be: adding more comments for this in case anyone else would revisit it with similar confusions, e.g. HashMap.clear.

Great, I'm glad this was helpful.

Regarding the tests, yes, I'm afraid those might be overly strict. The 
specification is admittedly quite loose in this area. This means that the exact 
behavior may vary from release to release. If a collection is optimized, for 
example, sometimes it's quite difficult to preserve the exact same behavior in 
all cases. It's for this reason we avoid specifying the exact behaviors around 
CME. Of course, when making any changes, we usually do try to preserve the 
general behavior, just not every specific edge case.

I generally welcome code comments to improve clarity, but I'm not sure one is 
warranted for HashMap.clear(). The placement of modCount++ seems quite 
reasonable. There are other cases where the choice of 
conditional-vs-unconditional is made (see [1]) and I don't think we want to go 
sprinkling explanations of this all around the code.

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060068.html

s'marks

From stuart.marks at oracle.com  Wed May  8 22:31:43 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 8 May 2019 15:31:43 -0700
Subject: inconsistency between ArrayList.modCount and logic of
 ArrayList::addAll
In-Reply-To: <B8718703-47CA-4A80-9BEC-93C3B025A2F9@oracle.com>
References: <8678411557320145@myt5-9da6df248f4a.qloud-c.yandex.net>
 <B8718703-47CA-4A80-9BEC-93C3B025A2F9@oracle.com>
Message-ID: <70a5b0a0-e98b-0260-6359-04cb0c6bfdfb@oracle.com>



On 5/8/19 7:44 AM, Pavel Rappo wrote:
> We will certainly hear from Stuart on this very soon.

Heh.

On 5/8/19 5:55 AM, ?????? ??????? wrote:
> javadoc for AbstractList.modCount is described as 
> 
>> The number of times this list has been <i>structurally modified</i>.
>> Structural modifications are those that change the size of the
>> list, or otherwise perturb it in such a fashion that iterations in
>> progress may yield incorrect results.
> 
> However when we execute this
> 
> ------------------------
> ArrayList<Object> objects = new ArrayList<>();
> boolean result = objects.addAll(Collections.emptyList());
> ------------------------
> 
> modCount is 1, not 0 while result is false. I.e. returned value claims the list is not modified, but the inner state of the same list demonstrates the opposite.

I think Pavel has the right point here, which is whether modCount should be 
incremented if the list is *actually* modified or whether an *attempt* to modify 
it is made. On the one hand, a strict reading seems to indicate incrementing 
only actual modifications. However, if the goal is to catch programming errors, 
then incrementing on any modification *attempt* seems preferable.

I described this as "state-dependent" behavior in a message in this recent thread:

     https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059708.html
     https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/059979.html

Briefly, consider code like

     for (Object obj : objects) {
         ...
         objects.addAll(getAdditionalObjects());
         ...
     }

This is clearly bad code because it modifies the list during iteration. We want 
ConcurrentModificationException to be thrown regardless of whether 
getAdditionalObjects() returns an empty collection.

In general, the incrementing of modCount (and the consequential throwing of CME) 
is an approximation. We usually want to it catch as many errors as feasible, but 
not at the cost of unreasonable performance or code complexity.

s'marks

From stuart.marks at oracle.com  Wed May  8 23:07:24 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 8 May 2019 16:07:24 -0700
Subject: RFR (M): JDK-6394757: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <6e929517-702c-e1e1-9b7a-baf6a1c29d08@oracle.com>
References: <a55aaa5c-d530-4080-06c5-887af283bec0@oracle.com>
 <6e929517-702c-e1e1-9b7a-baf6a1c29d08@oracle.com>
Message-ID: <234b04b6-6f2b-5c29-3f54-6e7d217f055b@oracle.com>



On 5/7/19 4:33 PM, Brent Christian wrote:
> Collection.java:
> 
>  ?110? * that use different membership semantics. For operations that involve 
> more than
>  ?111? * one collection, it is specified which collection's membership semantics 
> are
>  ?112? * used by the operation.
> 
> addAll() and copyOf() involve more than one collection, though I agree that they 
> do not need to be updated to specify membership semantics.

Yeah. Maybe I can be more specific here... operations that involve membership in 
both collections, or something.

> AbstractCollection.java:
> 
> 
> 404 * obtaining an iterator from the {@code iterator} method. Each element
> 405 * is passed to the {@code contains} method of the specified collection.
> 406 * If this call returns {@code false}, the element is removed from
>  ???????? ^^^^^^^^^
> 
> Is "this call" a little ambiguous?? Maybe:
> 
> "If contains() returns false..."
> or
> "If false is returned..."
> 
> ?

Yeah I agree it's a bit clumsy. I'll tweak it to be better.

> List.java:
> 
> Should containsAll(), removeAll(), retainAll() have the @implNote about 
> contains() performance?

Good question.

I started to go and add them, but then I thought that it didn't make sense. 
List.contains() is almost unavoidably linear in performance -- at least our 
built-in List implementations are -- so the note on containsAll() is mostly 
pointless.

However, the bulk removals (removeAll and retainAll) on ArrayList are optimized 
to make a single pass over the list elements (i.e., they don't do repeated 
copying) so the performance of contains() on the specified collection is indeed 
relevant. I'll add the notes to those methods.

s'marks

From ivan.gerasimov at oracle.com  Thu May  9 01:50:25 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 8 May 2019 18:50:25 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
Message-ID: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>

Hello!

Jdk has several places with similar logic:  an array needs to be 
reallocated (by at least some defined amount), taking into account the 
maximum allowed size of arrays.

There's clearly an opportunity for refactoring, so it is proposed to 
introduce a dedicated utility method for calculating the best new size 
of an array.

Would you please help review this enhancement?

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

Mach5 job ran fine.

Thanks in advance!

-- 
With kind regards,
Ivan Gerasimov


From ying.z.zhou at oracle.com  Thu May  9 05:01:26 2019
From: ying.z.zhou at oracle.com (Ying Zhou)
Date: Thu, 9 May 2019 13:01:26 +0800
Subject: [13]RFR 8222969 : Migrate RuleBasedCollatorTest to JDK Repo
Message-ID: <327de3c2-0e22-1a44-262b-2f35be351822@oracle.com>

Hello,

Please help to review this patch for migrating RuleBasedCollatorTest 
from Tong to Jtreg.

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

webrev: http://cr.openjdk.java.net/~yzhou/8222969/webrev.03/

Thanks,

Daisy



From patrick at os.amperecomputing.com  Thu May  9 06:29:30 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Thu, 9 May 2019 06:29:30 +0000
Subject: RFR(trivial): 8222394: HashMap.compute() throws CME on an empty
 Map if clear() called concurrently
In-Reply-To: <2434bc38-cc3f-b668-f95a-7994563de058@oracle.com>
References: <BL0PR01MB50445D4086CD13A9785367348F280@BL0PR01MB5044.prod.exchangelabs.com>
 <a4fdb034-df89-9d86-2e53-5413048bd637@oracle.com>
 <BYAPR01MB50464E833DF1E9918A8BE9348F2B0@BYAPR01MB5046.prod.exchangelabs.com>
 <520e1ee0-8f1c-ae46-2b45-24555c88aa05@oracle.com>
 <BYAPR01MB50465E819FB106ACABEC8E998F3D0@BYAPR01MB5046.prod.exchangelabs.com>
 <33a11459-830f-07cd-3ee0-743657f6a6b7@oracle.com>
 <BYAPR01MB50464A5E78FB94F47120851C8F360@BYAPR01MB5046.prod.exchangelabs.com>
 <2434bc38-cc3f-b668-f95a-7994563de058@oracle.com>
Message-ID: <BL0PR01MB50443F38BF643B03BBAB04148F330@BL0PR01MB5044.prod.exchangelabs.com>

> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060068.html
Thanks for sharing this thread. 
I saw Pavel's comments: "I believe it should be incremented on an attempt to modify the collection, rather than on the effective result of that attempt"
It can be true for bulk modifications like addAll, clear, while for single-entry modifications like put, remove, merge, etc. it depends, some are unconditional ++ and most are conditional ++. 
So the clarification should be not specific to clear or addAll, but at a common place (if possible) in a higher level javadoc for modCount, or for "fail fast".

Regards
Patrick

-----Original Message-----
From: Stuart Marks <stuart.marks at oracle.com> 
Sent: Thursday, May 9, 2019 5:01 AM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR(trivial): 8222394: HashMap.compute() throws CME on an empty Map if clear() called concurrently



On 5/4/19 12:21 AM, Patrick Zhang OS wrote:
> Thank you very much for the detailed explanation and examples, which solved most of my previous questions and confusion. Really appreciate that. I agree with the opinion about "effort vs benefit".
> 
> Re-thought my original tests concerning CMEs that passed with jdk8u but failed with jdk11 (should be 9+, but I only checked LTS builds), I was struggling between "fixing" the "problems" in jdk11 and "making jdk8 fail similarly". However so far it looks these tests might be over strict, or "verifying CMEs" itself might be an invalid (or unreliable) operation, perhaps I should drop all of them. Lastly, a suggestion would be: adding more comments for this in case anyone else would revisit it with similar confusions, e.g. HashMap.clear.

Great, I'm glad this was helpful.

Regarding the tests, yes, I'm afraid those might be overly strict. The specification is admittedly quite loose in this area. This means that the exact behavior may vary from release to release. If a collection is optimized, for example, sometimes it's quite difficult to preserve the exact same behavior in all cases. It's for this reason we avoid specifying the exact behaviors around CME. Of course, when making any changes, we usually do try to preserve the general behavior, just not every specific edge case.

I generally welcome code comments to improve clarity, but I'm not sure one is warranted for HashMap.clear(). The placement of modCount++ seems quite reasonable. There are other cases where the choice of conditional-vs-unconditional is made (see [1]) and I don't think we want to go sprinkling explanations of this all around the code.

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060068.html

s'marks

From goetz.lindenmaier at sap.com  Thu May  9 06:55:19 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 9 May 2019 06:55:19 +0000
Subject: RFR(L): 8218628: Add detailed message to NullPointerException
 describing what is null.
In-Reply-To: <538ca28f-333f-3a2b-d661-1f1454953b79@oracle.com>
References: <7c4b0bc27961471e91195bef9e767226@sap.com>
 <a8b818e8-7833-bd5c-e527-da476d19c7ab@oracle.com>
 <a4b0c569ffd543ee844842f5a3ae64ad@sap.com>
 <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com>
 <bbfd9855f337445f9b0de88048f8e10b@sap.com>
 <d871303ade6c4ec594b55acca0a0ba00@sap.com>
 <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com>
 <e1917533-7298-6008-98a0-d494227e9ea1@oracle.com>
 <3245ec3cefe2471e8382048164c0ba6b@sap.com>
 <DB7PR02MB5178770C575AB211A8D1EEB2EC4B0@DB7PR02MB5178.eurprd02.prod.outlook.com>
 <VI1PR02MB51835505401202E32518CD67EC280@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB4463E8CA5B15844849D0C011EC300@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <AM0PR02MB450071BA4ECF288D0D68F7409F310@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <VI1PR02MB44636E249A2445FF4B538871EC310@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <538ca28f-333f-3a2b-d661-1f1454953b79@oracle.com>
Message-ID: <VI1PR02MB4463E8DA3BA66DFD9DA09763EC330@VI1PR02MB4463.eurprd02.prod.outlook.com>

Hi,

> Cannot is apparently preferable in English.  
OK, changed. 

Best regards,
  Goetz.


> -----Original Message-----
> From: coleen.phillimore at oracle.com <coleen.phillimore at oracle.com>
> Sent: Mittwoch, 8. Mai 2019 17:32
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Schmelter, Ralf
> <ralf.schmelter at sap.com>; Java Core Libs <core-libs-dev at openjdk.java.net>;
> hotspot-runtime-dev at openjdk.java.net; Harold David Seigel
> <harold.seigel at oracle.com>
> Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException
> describing what is null.
> 
> 
> 
> On 5/7/19 9:36 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Please have a look at this further improved webrev:
> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09/
> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09-
> incremental/
> >
> > Harold, Coleen, thanks for pointing me to those methods.
> > I'm using them now. This simplifies the helper methods
> > considerably.
> >
> > Ralf, thanks for looking at the messages!
> > I now suppress the "static " and
> > "The return value of '" strings in the array subscript
> > expressions and added corresponding test cases.
> >
> > About "can not" versus "cannot", what I find in the
> > net "cannot" is to be preferred.  Any comments on that?
> > By native speakers?
> > See example messages here:
> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-
> NPE/09/output_with_debug_info.txt
> 
> Cannot is apparently preferable in English.? Native speaker (only
> language) but somebody had to tell me.
> 
> Coleen
> >
> > Further, I fixed a build issue with the solaris compiler.
> > All handling of bci is now unsigned.
> >
> > Best regards,
> >    Goetz.
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Schmelter, Ralf
> >> Sent: Dienstag, 7. Mai 2019 14:35
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Java Core Libs
> <core-
> >> libs-dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net;
> Coleen
> >> Phillimore (coleen.phillimore at oracle.com) <coleen.phillimore at oracle.com>
> >> Subject: RE: RFR(L): 8218628: Add detailed message to NullPointerException
> >> describing what is null.
> >>
> >> Hi Goetz,
> >>
> >> I've played with the messages a little bit and they generally look good. But
> I've
> >> come across two which look strange:
> >>   - 'o[static Test.INDEX]' is null. Can not invoke method 'int
> >> java.lang.Object.hashCode()'
> >>   - 'o[The return value of 'int java.lang.String.hashCode()]' is null. Can not
> invoke
> >> method 'int java.lang.Object.hashCode()'.
> >>
> >> Here is the test program to reproduce these:
> >> public class Test {
> >>      public static int INDEX = 2;
> >>
> >>      public static void main(String[] args) {
> >>          Object[] o = new Object[10];
> >>          try {
> >>               o[INDEX].hashCode();
> >>          } catch (Exception e) {
> >>              e.printStackTrace();
> >>          }
> >>          try {
> >>               o["".hashCode()].hashCode();
> >>          } catch (Exception e) {
> >>              e.printStackTrace();
> >>          }
> >>      }
> >> }
> >>
> >> And 'Can not' should be 'Cannot'?
> >>
> >> Best regards,
> >> Ralf


From goetz.lindenmaier at sap.com  Thu May  9 08:04:04 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 9 May 2019 08:04:04 +0000
Subject: RFR(L): 8218628: Add detailed message to NullPointerException
 describing what is null.
In-Reply-To: <VI1PR02MB4463E8DA3BA66DFD9DA09763EC330@VI1PR02MB4463.eurprd02.prod.outlook.com>
References: <7c4b0bc27961471e91195bef9e767226@sap.com>
 <a8b818e8-7833-bd5c-e527-da476d19c7ab@oracle.com>
 <a4b0c569ffd543ee844842f5a3ae64ad@sap.com>
 <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com>
 <bbfd9855f337445f9b0de88048f8e10b@sap.com>
 <d871303ade6c4ec594b55acca0a0ba00@sap.com>
 <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com>
 <e1917533-7298-6008-98a0-d494227e9ea1@oracle.com>
 <3245ec3cefe2471e8382048164c0ba6b@sap.com>
 <DB7PR02MB5178770C575AB211A8D1EEB2EC4B0@DB7PR02MB5178.eurprd02.prod.outlook.com>
 <VI1PR02MB51835505401202E32518CD67EC280@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB4463E8CA5B15844849D0C011EC300@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <AM0PR02MB450071BA4ECF288D0D68F7409F310@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <VI1PR02MB44636E249A2445FF4B538871EC310@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <538ca28f-333f-3a2b-d661-1f1454953b79@oracle.com>
 <VI1PR02MB4463E8DA3BA66DFD9DA09763EC330@VI1PR02MB4463.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB4463DCC183035F1F3E1B5942EC330@VI1PR02MB4463.eurprd02.prod.outlook.com>

Hi,

here a webrev which uses 'cannot'. Nothing else changed.
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/10-cannot/

Best regards,
  Goetz.

> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 9. Mai 2019 08:55
> To: coleen.phillimore at oracle.com; Schmelter, Ralf <ralf.schmelter at sap.com>;
> Java Core Libs <core-libs-dev at openjdk.java.net>; hotspot-runtime-
> dev at openjdk.java.net; Harold David Seigel <harold.seigel at oracle.com>
> Subject: RE: RFR(L): 8218628: Add detailed message to NullPointerException
> describing what is null.
> 
> Hi,
> 
> > Cannot is apparently preferable in English.
> OK, changed.
> 
> Best regards,
>   Goetz.
> 
> 
> > -----Original Message-----
> > From: coleen.phillimore at oracle.com <coleen.phillimore at oracle.com>
> > Sent: Mittwoch, 8. Mai 2019 17:32
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Schmelter, Ralf
> > <ralf.schmelter at sap.com>; Java Core Libs <core-libs-dev at openjdk.java.net>;
> > hotspot-runtime-dev at openjdk.java.net; Harold David Seigel
> > <harold.seigel at oracle.com>
> > Subject: Re: RFR(L): 8218628: Add detailed message to NullPointerException
> > describing what is null.
> >
> >
> >
> > On 5/7/19 9:36 AM, Lindenmaier, Goetz wrote:
> > > Hi,
> > >
> > > Please have a look at this further improved webrev:
> > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09/
> > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09-
> > incremental/
> > >
> > > Harold, Coleen, thanks for pointing me to those methods.
> > > I'm using them now. This simplifies the helper methods
> > > considerably.
> > >
> > > Ralf, thanks for looking at the messages!
> > > I now suppress the "static " and
> > > "The return value of '" strings in the array subscript
> > > expressions and added corresponding test cases.
> > >
> > > About "can not" versus "cannot", what I find in the
> > > net "cannot" is to be preferred.  Any comments on that?
> > > By native speakers?
> > > See example messages here:
> > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-
> > NPE/09/output_with_debug_info.txt
> >
> > Cannot is apparently preferable in English.? Native speaker (only
> > language) but somebody had to tell me.
> >
> > Coleen
> > >
> > > Further, I fixed a build issue with the solaris compiler.
> > > All handling of bci is now unsigned.
> > >
> > > Best regards,
> > >    Goetz.
> > >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Schmelter, Ralf
> > >> Sent: Dienstag, 7. Mai 2019 14:35
> > >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Java Core Libs
> > <core-
> > >> libs-dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net;
> > Coleen
> > >> Phillimore (coleen.phillimore at oracle.com)
> <coleen.phillimore at oracle.com>
> > >> Subject: RE: RFR(L): 8218628: Add detailed message to
> NullPointerException
> > >> describing what is null.
> > >>
> > >> Hi Goetz,
> > >>
> > >> I've played with the messages a little bit and they generally look good. But
> > I've
> > >> come across two which look strange:
> > >>   - 'o[static Test.INDEX]' is null. Can not invoke method 'int
> > >> java.lang.Object.hashCode()'
> > >>   - 'o[The return value of 'int java.lang.String.hashCode()]' is null. Can not
> > invoke
> > >> method 'int java.lang.Object.hashCode()'.
> > >>
> > >> Here is the test program to reproduce these:
> > >> public class Test {
> > >>      public static int INDEX = 2;
> > >>
> > >>      public static void main(String[] args) {
> > >>          Object[] o = new Object[10];
> > >>          try {
> > >>               o[INDEX].hashCode();
> > >>          } catch (Exception e) {
> > >>              e.printStackTrace();
> > >>          }
> > >>          try {
> > >>               o["".hashCode()].hashCode();
> > >>          } catch (Exception e) {
> > >>              e.printStackTrace();
> > >>          }
> > >>      }
> > >> }
> > >>
> > >> And 'Can not' should be 'Cannot'?
> > >>
> > >> Best regards,
> > >> Ralf


From claes.redestad at oracle.com  Thu May  9 11:26:45 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 9 May 2019 13:26:45 +0200
Subject: RFR: 8223454: Reduce String concatenation shapes by folding
 initialLengthCoder into last mixer
In-Reply-To: <9356390f-7c52-3b2e-9a13-620b92bfb023@oracle.com>
References: <9356390f-7c52-3b2e-9a13-620b92bfb023@oracle.com>
Message-ID: <f23aeba8-11c6-2500-4008-47baae1fc8b0@oracle.com>

To give some context ("Why are you doing this to us?!")

I've extracted a few simple concatenation expressions (most of these are 
commonly seen in the JDK sources) to create a reasonably realistic test
to assess String concat bootstrap overheads[1] (timings for a simple
noop and difference within parentheses):

JDK 8:    60ms  (60ms, +0ms)
JDK 9:   215ms  (86ms, +129ms)
JDK 12:  111ms  (43ms, +68ms)
jdk/jdk:  97ms  (40ms, +57ms)
+ this:   86ms  (40ms, +46ms)

So on a test like this, this little optimization is surprisingly large.
Since we need fewer generated classes under the hood to make up
these expressions, it's also a nice little static and dynamic
footprint improvement.

This also shows there's still some lengths to go to make ISC bootstraps
perfectly neutral relative the StringBuilder chains emitted on earlier
targets. We probably won't get _that_ far, but I also thought we
wouldn't be able to improve much after the optimizations delivered in
JDK 12, so who knows...

Thanks!

/Claes

On 2019-05-08 16:49, Claes Redestad wrote:
> Hi,
> 
> yet another String concat startup/footprint optimization.
> 
> As the subject implies, we could fold the initialLengthCoder it into the
> final mixer. This way we end up with one less bound argument into the
> larger method handle combinator tree, with fewer species classes and
> lambda forms generated as a result. This means a significant speed-up on
> several startup and footprint tests, and especially noticeable on
> realistic workloads that just have a few different small concat shapes.
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8223454
> Webrev: http://cr.openjdk.java.net/~redestad/8223454/open.00/
> 
> Thanks!
> 
> /Claes

[1]
public class StringConcatMix {
     public static void main(String ... args) {
         String s = String.valueOf(args.length);
         String concat;

         concat = s + s;
         concat = "c" + s + "c";
         concat = s + "c" + s;
         concat = "c" + s + "c" + s;
         concat = "c" + s + s + "c";
         concat = s + "c" + s + s + "c";
         concat = "c" + s + "c" + args.length;
         concat = "c" + s + "c" + s + "c" + s;
     }
}

From james.laskey at oracle.com  Thu May  9 11:47:29 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 9 May 2019 08:47:29 -0300
Subject: RFR: 8223454: Reduce String concatenation shapes by folding
 initialLengthCoder into last mixer
In-Reply-To: <9356390f-7c52-3b2e-9a13-620b92bfb023@oracle.com>
References: <9356390f-7c52-3b2e-9a13-620b92bfb023@oracle.com>
Message-ID: <A8CA59E8-13DA-42CE-89AA-23D27AEB0B04@oracle.com>

+1


> On May 8, 2019, at 11:49 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> yet another String concat startup/footprint optimization.
> 
> As the subject implies, we could fold the initialLengthCoder it into the
> final mixer. This way we end up with one less bound argument into the
> larger method handle combinator tree, with fewer species classes and
> lambda forms generated as a result. This means a significant speed-up on
> several startup and footprint tests, and especially noticeable on
> realistic workloads that just have a few different small concat shapes.
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8223454
> Webrev: http://cr.openjdk.java.net/~redestad/8223454/open.00/
> 
> Thanks!
> 
> /Claes


From claes.redestad at oracle.com  Thu May  9 11:53:20 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 9 May 2019 13:53:20 +0200
Subject: RFR: 8223454: Reduce String concatenation shapes by folding
 initialLengthCoder into last mixer
In-Reply-To: <A8CA59E8-13DA-42CE-89AA-23D27AEB0B04@oracle.com>
References: <9356390f-7c52-3b2e-9a13-620b92bfb023@oracle.com>
 <A8CA59E8-13DA-42CE-89AA-23D27AEB0B04@oracle.com>
Message-ID: <790a7ca6-5bcf-039e-273c-6d1be1b1fed8@oracle.com>

Thanks Jim!

/Claes

On 2019-05-09 13:47, Jim Laskey wrote:
> +1
> 
> 
>> On May 8, 2019, at 11:49 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> yet another String concat startup/footprint optimization.
>>
>> As the subject implies, we could fold the initialLengthCoder it into the
>> final mixer. This way we end up with one less bound argument into the
>> larger method handle combinator tree, with fewer species classes and
>> lambda forms generated as a result. This means a significant speed-up on
>> several startup and footprint tests, and especially noticeable on
>> realistic workloads that just have a few different small concat shapes.
>>
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8223454
>> Webrev: http://cr.openjdk.java.net/~redestad/8223454/open.00/
>>
>> Thanks!
>>
>> /Claes
> 

From pavel.rappo at oracle.com  Thu May  9 12:09:06 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 9 May 2019 13:09:06 +0100
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
Message-ID: <FE93EE7B-B6C7-4E3C-9203-1E141A1F795E@oracle.com>

Ivan,

Many thanks for doing this! This code is both error-prone and abundant in the
JDK, which indeed makes it a perfect candidate for refactoring.

Since that particular change touches quite a few foundational parts of the
libraries I felt the urge to make sure the change doesn't introduce any
artifacts. I couldn't find any degradation in amortized performances in the
worst case scenarios. You seem to have carefully preserved all the growth (3/2,
2) factors, and +1's for eventual increase. The fact that the tests have passed
adds a lot of confidence too.

Nevertheless, I would strongly suggest you wait for reviews from the experts in
the areas the change touches. At least for Collections and String. Even though
the core of the change seems to be area-agnostic.

On a separate note. I wonder why all assertion statements were commented out
from ArraysSupport in the first place?

Nits:

1. If `ArraysSupport` is the right place for this functionality, then I think we
should respect its formatting and align methods' arguments into a column:

    public static int newCapacity(int oldCapacity,
                                  int growAtLeastBy,
                                  int preferredGrowBy)

2. A typo:

    * @throws OutOfMemoryError if increasing {@code oldCapacity) by
    *                          {@code growAtLeastBy} overfows.
                                                     ~~~~~^

3. I know that this is not new and has been copied from the old code. However,
I'm not sure I understand the meaning of "unless necessary" here:

    /**
     * The maximum size of array to allocate (unless necessary).

-Pavel


From christoph.langer at sap.com  Thu May  9 14:47:49 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 9 May 2019 14:47:49 +0000
Subject: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for
 JDK-8213031
In-Reply-To: <AM6PR02MB519262684DA223A733C7D41B8A3A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <HE1PR0201MB226656E770657D840E1FEF228A2F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <AM6PR02MB51929210FF0E3A73571569138A3E0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB519262684DA223A733C7D41B8A3A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB5192C231B13810C8EF1F3E708A330@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

after exchanging a few mails with Lance, I have a new version ready: http://cr.openjdk.java.net/~clanger/webrevs/8222276.2/

I stepped back from changing the class hierarchy for ZipFileSystem.IndexNode and ZipFileSystem.Entry. It?s not a prerequisite for my current proposal for JDK-8213031 anymore. I?ve added further cleanups and implemented feedback I got from Lance.

Please get me some reviews ??

Thanks
Christoph


From: Langer, Christoph
Sent: Dienstag, 30. April 2019 11:54
To: core-libs-dev <core-libs-dev at openjdk.java.net>; nio-dev <nio-dev at openjdk.java.net>; Alan Bateman <Alan.Bateman at oracle.com>; Lance Andersen <lance.andersen at oracle.com>
Subject: RE: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031

Hi,

it turned out that there was a regression in my last version. I needed to fix some initializations in the constructor of Entry. I also added some other fixes found by the IDE?s code analysis to ZipFileSystem.java.

By accident, I updated the last webrev in-place. So, please find my most current version here: http://cr.openjdk.java.net/~clanger/webrevs/8222276.1/

Now it passes all testing.

Thank you
Christoph

From: Langer, Christoph
Sent: Freitag, 26. April 2019 17:37
To: core-libs-dev <core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>>; nio-dev <nio-dev at openjdk.java.net<mailto:nio-dev at openjdk.java.net>>; Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>>; Lance Andersen <lance.andersen at oracle.com<mailto:lance.andersen at oracle.com>>
Subject: RE: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031

Hi,

ping ??

I?ve rebased this change after the latest zipfs updates. I also made some further modifications. Apart from minor things, I modified the constructors of the ZipFileSystem.Entry class and I also made some post JDK-8222440 cleanup.

Please find the new webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8222276.1/

The jtreg tests for zipfs are all passing.

Thanks
Christoph

From: Langer, Christoph
Sent: Donnerstag, 11. April 2019 16:06
To: core-libs-dev <core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>>; nio-dev <nio-dev at openjdk.java.net<mailto:nio-dev at openjdk.java.net>>; Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>>; Lance Andersen <lance.andersen at oracle.com<mailto:lance.andersen at oracle.com>>
Subject: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031

Hi,

working on JDK-8213031 to add posix file permission support for the zipfs, I thought it makes sense to factor out some of the changes into a separate change. Those changes reorganize and clean up some parts of the code which I think makes sense in any case.

Please review:
Bug: https://bugs.openjdk.java.net/browse/JDK-8222276
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8222276.0/

In detail:
The main change is to the hierarchy of inner classes ZipFileSystem.IndexNode and ZipFileSystem.Entry (the latter extends the former). Both classes are static classes currently. It makes sense, though, to have those associated with the ZipFileSystem they belong to.
To do that, I need to add a static superclass named ZFSNode which only holds a node name and its hashcode. This class needs to exist because of the lookup implementation to find specific nodes of tze ZipFileSystem in its node map. Then the classes IndexNode extends ZFSNode and Entry extends IndexNode can be made non-static.

Further changes are:
Improve error handling for ZipFileAttributeView::get methods
improve handling for zip64 attribute/version
minor clenaups such as adding @Override annotations, whitespace fixes, private method visibility etc.

Furthermore, there is some suspicious coding in JarFileSystem:: createVersionedLinks where a temporary key node is inserted into the alias map. However, this is a singleton instance which always gets new values. I?ll open a separate bug for that and I?ll try to create a test case which demonstrates an issue with the current code.

I ran the zipfs jtreg tests successfully and will put it into our internal system as well as run it through jdk-submit.

Thanks
Christoph


From christoph.langer at sap.com  Thu May  9 15:16:46 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 9 May 2019 15:16:46 +0000
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <CA+3eh102cMGphPPbABv2ef_M5Py5+Mg-FRU94HcpKUH3gaV6+w@mail.gmail.com>
 <fd756aff51134b15a40fe55247d4a87e@sap.com>
 <CA+3eh13dP-tCdq4H4z3KWJZQzfMJYqDNkx9fMh3tNfL08RCtDg@mail.gmail.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <a3e64312-d902-b751-d55d-0af1c4c6e3c5@oracle.com>
 <953449f0913340f6a94ae3d83611fd92@sap.com>
 <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>
 <HE1PR0201MB2266326D98F5119796990BFC8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
Message-ID: <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Alan,

I've got a new iteration for the zipfs POSIX support and addressed your concerns: http://cr.openjdk.java.net/~clanger/webrevs/8213031.9/

The new change bases on the proposal for JDK-8222276, which I created to factor out changes unrelated to POSIX to facilitate easier reviewing of this patch.

In details:

> One thing that is puzzling is that
> ZipFileAttributeView/ZipFileAttributes extend
> PosixFileAttributeView/PosixFileAttributes. I don't think that will work
> because the "zip" view is supported by default whereas "posix" view
> needs the file system to be created with enablePosixFileAttributes=true.

I separated ZipFileAttributeView and ZipFileAttributeViewPosix. I also created a class EntryPosix inside ZipFileSystem.java that extends the default Entry class and additionally implements PosixFileAttributes. It is used, depending on whether Posix support is turned on or not. I unfortunately had to touch all the places where new Entry objects are created and either create a Posix entry or a default Entry.


> I saw your comment about naming the file permissions attribute
> "storedPermissions" in the zip view but if the zip and posix view are
> separated then I think it would be clearer to name it "permissions" in
> the zip view. If code is using Files.getAttribute then it will need the
> view name so they won't get mixed up.

It's always "permissions" now. In case, it is a default ZipFileSystem, the attribute is optional. If supportPosix is true, it'll always be available using default values.

> You asked about the fallback when defaultOwner/defaultGroup aren't set.
> If getOwner fails with an IOException then I think that exception should
> be propagated. The UOE case will fallback to the value of "user.name". I
> think the fallback for the group owner should be the file owner rather
> than "
> "<zipfs_default>". The default.policy file will need to be updated to
> grant jdk.zipfs RuntimePermission("accessUserInfo") so that you won't
> need to deal with security exceptions.

Ok, done that ??

> As regards next steps then I think we need to agree the spec changes, as
> in the the javadoc in module-info.java. Once we have the spec agreed
> then the CSR can be updated and finalized. The code review can be done
> in parallel of course. I think Lance is going to help review the changes.

I have updated module-info a little bit to reflect the latest changes. Is it now time to focus on the CSR?

Thanks
Christoph


From daniel.fuchs at oracle.com  Thu May  9 15:23:31 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 May 2019 16:23:31 +0100
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>

Hi Christoph,

I'm only commenting on the HttpClient changes, I'll let
others comment on the other changes...

http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html

I have a profound dislike for using @SuppressedWarnings, unless
it's the only alternative. My preference would be to introduce
local variables, if that can make the compiler happy, until such time
where the issue is actually resolved...

For instance, it seems that the following would work:

     // Use local variable assignments to keep other java compilers
     // happy and avoid unchecked casts warnings
     BiFunction<Http2Connection, Throwable, CompletableFuture<? extends 
ExchangeImpl<U>>>
         factory = (h2c, t) -> createExchangeImpl(h2c, t, exchange, 
connection);
     Function<CompletableFuture<? extends ExchangeImpl<U>>, 
CompletableFuture<? extends ExchangeImpl<U>>>
         identity = (cf) -> cf;
     return c2f.handle(factory).thenCompose(identity);


best regards,

-- daniel

On 08/05/2019 09:02, Langer, Christoph wrote:
> Hi,
> 
> please review a small change that I?d like to see in OpenJDK to get rid 
> of compilation errors in the Eclipse IDE.
> 
> It seems the root cause for the compilation errors is that javac would 
> sometimes widen capture variables and is hence able to compile the 
> places that I touch here. The EC4J compiler claims that it?s following 
> the spec more strictly and bails out at these places. I had posted about 
> this on compiler-dev but got no reaction [0].
> 
> So, as this seems to be some field of open work for the compiler/spec 
> folks, I?d like to get EC4J quiesced by introducing some slight 
> modifications to the original places which makes the code appeal a bit 
> less elegant and fluent but will get rid of the compile errors.
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223553
> 
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/
> 
> The modification to 
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
> belongs to JSR-166, so I don?t know if it needs some special handling.
> 
> Thanks & Best regards
> 
> Christoph
> 
> [0] 
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013054.html
> 


From naoto.sato at oracle.com  Thu May  9 15:33:00 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 9 May 2019 08:33:00 -0700
Subject: <i18n dev> [13]RFR 8222969 : Migrate RuleBasedCollatorTest to JDK
 Repo
In-Reply-To: <327de3c2-0e22-1a44-262b-2f35be351822@oracle.com>
References: <327de3c2-0e22-1a44-262b-2f35be351822@oracle.com>
Message-ID: <0d00bf8a-4a2b-8b6f-8dc9-d8cc478a2f33@oracle.com>

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

Naoto

On 5/8/19 10:01 PM, Ying Zhou wrote:
> Hello,
> 
> Please help to review this patch for migrating RuleBasedCollatorTest 
> from Tong to Jtreg.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222969
> 
> webrev: http://cr.openjdk.java.net/~yzhou/8222969/webrev.03/
> 
> Thanks,
> 
> Daisy
> 
> 

From iris.clark at oracle.com  Thu May  9 16:15:43 2019
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 9 May 2019 09:15:43 -0700 (PDT)
Subject: RFR(L): 8218628: Add detailed message to NullPointerException
 describing what is null.
In-Reply-To: <VI1PR02MB4463DCC183035F1F3E1B5942EC330@VI1PR02MB4463.eurprd02.prod.outlook.com>
References: <7c4b0bc27961471e91195bef9e767226@sap.com>
 <a8b818e8-7833-bd5c-e527-da476d19c7ab@oracle.com>
 <a4b0c569ffd543ee844842f5a3ae64ad@sap.com>
 <5c445ea9-24fb-0007-78df-41b94aadde2a@oracle.com>
 <bbfd9855f337445f9b0de88048f8e10b@sap.com>
 <d871303ade6c4ec594b55acca0a0ba00@sap.com>
 <8d1cc0b0-4a01-4564-73a9-4c635bfbfbaf@oracle.com>
 <e1917533-7298-6008-98a0-d494227e9ea1@oracle.com>
 <3245ec3cefe2471e8382048164c0ba6b@sap.com>
 <DB7PR02MB5178770C575AB211A8D1EEB2EC4B0@DB7PR02MB5178.eurprd02.prod.outlook.com>
 <VI1PR02MB51835505401202E32518CD67EC280@VI1PR02MB5183.eurprd02.prod.outlook.com>
 <VI1PR02MB4463E8CA5B15844849D0C011EC300@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <AM0PR02MB450071BA4ECF288D0D68F7409F310@AM0PR02MB4500.eurprd02.prod.outlook.com>
 <VI1PR02MB44636E249A2445FF4B538871EC310@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <538ca28f-333f-3a2b-d661-1f1454953b79@oracle.com>
 <VI1PR02MB4463E8DA3BA66DFD9DA09763EC330@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <VI1PR02MB4463DCC183035F1F3E1B5942EC330@VI1PR02MB4463.eurprd02.prod.outlook.com>
Message-ID: <7fd44bcf-78a7-46c0-a40b-04547e163696@default>

Hi, Goetz.

The error messages using "cannot", the preferred word according to the Chicago Manual of Style [0], look good to me.

Thanks,
Iris

[0] https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Usage/faq0010.html

-----Original Message-----
From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com> 
Sent: Thursday, May 9, 2019 1:04 AM
To: Coleen Phillimore <coleen.phillimore at oracle.com>; Schmelter, Ralf <ralf.schmelter at sap.com>; Java Core Libs <core-libs-dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net; Harold David Seigel <harold.seigel at oracle.com>
Subject: RE: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

Hi,

here a webrev which uses 'cannot'. Nothing else changed.
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/10-cannot/

Best regards,
  Goetz.

> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 9. Mai 2019 08:55
> To: coleen.phillimore at oracle.com; Schmelter, Ralf 
> <ralf.schmelter at sap.com>; Java Core Libs 
> <core-libs-dev at openjdk.java.net>; hotspot-runtime- 
> dev at openjdk.java.net; Harold David Seigel <harold.seigel at oracle.com>
> Subject: RE: RFR(L): 8218628: Add detailed message to 
> NullPointerException describing what is null.
> 
> Hi,
> 
> > Cannot is apparently preferable in English.
> OK, changed.
> 
> Best regards,
>   Goetz.
> 
> 
> > -----Original Message-----
> > From: coleen.phillimore at oracle.com <coleen.phillimore at oracle.com>
> > Sent: Mittwoch, 8. Mai 2019 17:32
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Schmelter, Ralf 
> > <ralf.schmelter at sap.com>; Java Core Libs 
> > <core-libs-dev at openjdk.java.net>; 
> > hotspot-runtime-dev at openjdk.java.net; Harold David Seigel 
> > <harold.seigel at oracle.com>
> > Subject: Re: RFR(L): 8218628: Add detailed message to 
> > NullPointerException describing what is null.
> >
> >
> >
> > On 5/7/19 9:36 AM, Lindenmaier, Goetz wrote:
> > > Hi,
> > >
> > > Please have a look at this further improved webrev:
> > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09/
> > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09-
> > incremental/
> > >
> > > Harold, Coleen, thanks for pointing me to those methods.
> > > I'm using them now. This simplifies the helper methods 
> > > considerably.
> > >
> > > Ralf, thanks for looking at the messages!
> > > I now suppress the "static " and
> > > "The return value of '" strings in the array subscript expressions 
> > > and added corresponding test cases.
> > >
> > > About "can not" versus "cannot", what I find in the net "cannot" 
> > > is to be preferred.  Any comments on that?
> > > By native speakers?
> > > See example messages here:
> > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-
> > NPE/09/output_with_debug_info.txt
> >
> > Cannot is apparently preferable in English.? Native speaker (only
> > language) but somebody had to tell me.
> >
> > Coleen
> > >
> > > Further, I fixed a build issue with the solaris compiler.
> > > All handling of bci is now unsigned.
> > >
> > > Best regards,
> > >    Goetz.
> > >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Schmelter, Ralf
> > >> Sent: Dienstag, 7. Mai 2019 14:35
> > >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Java Core 
> > >> Libs
> > <core-
> > >> libs-dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net;
> > Coleen
> > >> Phillimore (coleen.phillimore at oracle.com)
> <coleen.phillimore at oracle.com>
> > >> Subject: RE: RFR(L): 8218628: Add detailed message to
> NullPointerException
> > >> describing what is null.
> > >>
> > >> Hi Goetz,
> > >>
> > >> I've played with the messages a little bit and they generally 
> > >> look good. But
> > I've
> > >> come across two which look strange:
> > >>   - 'o[static Test.INDEX]' is null. Can not invoke method 'int 
> > >> java.lang.Object.hashCode()'
> > >>   - 'o[The return value of 'int java.lang.String.hashCode()]' is 
> > >> null. Can not
> > invoke
> > >> method 'int java.lang.Object.hashCode()'.
> > >>
> > >> Here is the test program to reproduce these:
> > >> public class Test {
> > >>      public static int INDEX = 2;
> > >>
> > >>      public static void main(String[] args) {
> > >>          Object[] o = new Object[10];
> > >>          try {
> > >>               o[INDEX].hashCode();
> > >>          } catch (Exception e) {
> > >>              e.printStackTrace();
> > >>          }
> > >>          try {
> > >>               o["".hashCode()].hashCode();
> > >>          } catch (Exception e) {
> > >>              e.printStackTrace();
> > >>          }
> > >>      }
> > >> }
> > >>
> > >> And 'Can not' should be 'Cannot'?
> > >>
> > >> Best regards,
> > >> Ralf


From kfriese at dataplan.de  Thu May  9 11:50:47 2019
From: kfriese at dataplan.de (Klaus Friese)
Date: Thu, 9 May 2019 13:50:47 +0200
Subject: Problem with jpackage/Windows and using a different runtime
Message-ID: <d70b4b99-71f5-6430-c1c0-45400a456ca5@dataplan.de>

Hi,

I downloaded the jpackage EA version from https://jdk.java.net/jpackage/ 
for some tests and I run into problems when using a different runtime 
(OpenJDK12) on Windows.

This is my setting:
OpenJDK12 installed in c:\Program Files\OpenJDK12
OpenJDK13 with jpackage installed c:\Program Files\OpenJDK13

I created runtimes for both versions with:

    jlink --output myruntime
     ??? --module-path ../jmods
     ??? --add-modules ALL-MODULE-PATH
     ??? --bind-services
     ??? --compress=2
     ??? --strip-native-commands

I created the app with

    jpackage create-app-image ^
     ??? -o "/MyProject" ^
     ??? -i /MyProject/path/to/my/jars ^
     ??? -n application ^
     ??? --runtime-image ..\..\OpenJDK12\bin\myruntime ^
     ??? --main-class my.application.main.class ^
     ??? --main-jar main.jar

On Windows:
When using the OpenJDK13 runtime everything is fine.
When using the OpenJDK12 runtime the app doesn't start and I just get 
the message "Failed to load JVM"

On MacOS
OpenJDK12 and OpenJDK13 are working fine.

Is this an error in jpackage or is the error on my side?

Best regards
dataplan GmbH
Klaus Friese
System Engineer Applications
------------------------------------------------------------------------


*dataplan GmbH*
Stahltwiete 23
22761 Hamburg

Gesch?ftsf?hrer: Dr. Wolfgang Zetsche
HRB 31 083
Gerichtsstand: Hamburg
St. Nr.: DE118540281

Tel: +49 40 398 44 20
Fax: +49 40 390 26 39

www.dataplan.de <http://www.dataplan.de/>
www.facebook.de/dataplangmbh <http://www.facebook.de/dataplangmbh>
www.twitter.com/dataplangmbh <https://twitter.com/dataplangmbh>
kfriese at dataplan.de <mailto:kmueller at dataplan.de>

From temp325 at live.fr  Thu May  9 16:19:09 2019
From: temp325 at live.fr (Cyril F)
Date: Thu, 9 May 2019 16:19:09 +0000
Subject: Inno setup 6 broke javapacker/jpackage
Message-ID: <AM0PR06MB50449427CC4A8662DD8C9E35C9330@AM0PR06MB5044.eurprd06.prod.outlook.com>

On 2019-04-27 jrsoftware release innosetup-6.0.2.exe. I am using the old javapackager and I see that it perform a check to version 5 or newer.

But it check the version by looking for a number in the output of iscc /? wich now return Nothing in version 6 and iscc is detected as version 0.

By digging i can see this check is performed in jdk.jpackage.internal.WinExeBundler.java. I now that javapackager will be replaced by jpackage but i can see the same check is done in jpackage so it will also be broken !!


I started a thread  to see if inno setup can reintroduce a number in iscc /? to repare the old javapackager but it seems an bad idea to perform this check according to news.jrsoftware.org/read/article.php?id=107406&group=jrsoftware.innosetup#107406


From huizhe.wang at oracle.com  Thu May  9 16:25:07 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 09 May 2019 09:25:07 -0700
Subject: RFR(JDK 13/java.xml) 8222991: Xerces 2.12.0: Validation
In-Reply-To: <F36A757F-8DFA-4314-98D9-81D7CD3443EF@oracle.com>
References: <5CC774CC.6040008@oracle.com>
 <F36A757F-8DFA-4314-98D9-81D7CD3443EF@oracle.com>
Message-ID: <5CD45463.7010803@oracle.com>

Thanks Lance!  I re-ran all of tests (inc JCK), they all still pass. 
Pushed the patch now.

Best,
Joe

On 5/8/19, 1:30 PM, Lance Andersen wrote:
> Hi Joe,
>
> Sorry for the delay.  The patch looks good.
>
> Best
> Lance
>> On Apr 29, 2019, at 6:03 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> Please review an update on the Validation implementation.  All XML 
>> tests and JCK passed.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8222991
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8222991/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk13/8222991/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 andy.herrick at oracle.com  Thu May  9 16:52:40 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 9 May 2019 12:52:40 -0400
Subject: Inno setup 6 broke javapacker/jpackage
In-Reply-To: <AM0PR06MB50449427CC4A8662DD8C9E35C9330@AM0PR06MB5044.eurprd06.prod.outlook.com>
References: <AM0PR06MB50449427CC4A8662DD8C9E35C9330@AM0PR06MB5044.eurprd06.prod.outlook.com>
Message-ID: <c4169417-8b91-136e-9531-9aa47bdcad7e@oracle.com>

Although we plan to remove dependency on Inno Setup in the future, if 
that is not done soon after initial integration we can fix this in 
WinExeBundler.java by handling this case.? I will add line item to one 
of the post integration fix CR's to do this.

Thanks.

/Andy


On 5/9/2019 12:19 PM, Cyril F wrote:
> On 2019-04-27 jrsoftware release innosetup-6.0.2.exe. I am using the old javapackager and I see that it perform a check to version 5 or newer.
>
> But it check the version by looking for a number in the output of iscc /? wich now return Nothing in version 6 and iscc is detected as version 0.
>
> By digging i can see this check is performed in jdk.jpackage.internal.WinExeBundler.java. I now that javapackager will be replaced by jpackage but i can see the same check is done in jpackage so it will also be broken !!
>
>
> I started a thread  to see if inno setup can reintroduce a number in iscc /? to repare the old javapackager but it seems an bad idea to perform this check according to news.jrsoftware.org/read/article.php?id=107406&group=jrsoftware.innosetup#107406
>


From Roger.Riggs at oracle.com  Thu May  9 17:47:50 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 9 May 2019 13:47:50 -0400
Subject: RFR: 8221340 - [TESTBUG] TestCgroupMetrics.java fails after fix
 for JDK-8219562
In-Reply-To: <72AC2E0E-DECA-4F48-83E6-B05E1D32B981@oracle.com>
References: <96BEE19C-9950-48E9-9B11-9EA6EADE9123@oracle.com>
 <d5e50bb5-7752-2437-1583-27391afa85ca@oracle.com>
 <72AC2E0E-DECA-4F48-83E6-B05E1D32B981@oracle.com>
Message-ID: <b6a77fc4-a26e-cfe4-af00-0882578f71e8@oracle.com>

Hi Bob,

jdk/internal/platform/cgroupv1/SubSystem.java:
64: Is that the same as cgroupPath.startsWith(root)?? That might be 
slightly more readable.

Regardless, that looks fine.

Roger

On 05/08/2019 10:24 AM, Bob Vandette wrote:
> Thanks Misha!
>
> Could I get a ?Review? from someone in core libs, please?
>
> Bob.
>
>> On May 7, 2019, at 8:49 PM, mikhailo.seledtsov at oracle.com wrote:
>>
>> Changes look good to me,
>>
>> Misha
>>
>>
>> On 5/7/19 5:56 AM, Bob Vandette wrote:
>>> Please review this change to the Container Metrics implementation.
>>>
>>> Change were made in JDK-8219562 [1] to osContainer_linux.cpp to correct
>>> the parsing of of the /proc/self/mountinfo file but corresponding changes to the
>>> Metrics API and Container tests shou,d have been done to match this change.
>>>
>>> BUG:
>>> https://bugs.openjdk.java.net/browse/JDK-8221340
>>>
>>> WEBREV:
>>> http://cr.openjdk.java.net/~bobv/8221340/webrev.00/
>>>
>>> TESTING:
>>> These changes were verified by running Mach5  tier1 and 2 tests and the jtreg container
>>> tests on a Linux x64 system.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8219562
>>>
>>> Bob.
>>>


From ivan.gerasimov at oracle.com  Thu May  9 18:07:32 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 9 May 2019 11:07:32 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <FE93EE7B-B6C7-4E3C-9203-1E141A1F795E@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <FE93EE7B-B6C7-4E3C-9203-1E141A1F795E@oracle.com>
Message-ID: <14bb1a84-a375-ef00-90ae-a7f044a367a8@oracle.com>

Thank you Pavel for careful review.


On 5/9/19 5:09 AM, Pavel Rappo wrote:
> Ivan,
>
> Many thanks for doing this! This code is both error-prone and abundant in the
> JDK, which indeed makes it a perfect candidate for refactoring.
>
> Since that particular change touches quite a few foundational parts of the
> libraries I felt the urge to make sure the change doesn't introduce any
> artifacts. I couldn't find any degradation in amortized performances in the
> worst case scenarios.

Intent was to have a fast path for the common case:  I.e. when the 
capacity is increased by the 'preferred' amount.

In this scenario, work amount is minimum:  One summation and two checks 
if the new capacity is 1) large enough and 2) not too large.

>   You seem to have carefully preserved all the growth (3/2,
> 2) factors, and +1's for eventual increase. The fact that the tests have passed
> adds a lot of confidence too.
>
> Nevertheless, I would strongly suggest you wait for reviews from the experts in
> the areas the change touches. At least for Collections and String. Even though
> the core of the change seems to be area-agnostic.
>
> On a separate note. I wonder why all assertion statements were commented out
> from ArraysSupport in the first place?
>
> Nits:
>
> 1. If `ArraysSupport` is the right place for this functionality, then I think we
> should respect its formatting and align methods' arguments into a column:
>
>      public static int newCapacity(int oldCapacity,
>                                    int growAtLeastBy,
>                                    int preferredGrowBy)
>
> 2. A typo:
>
>      * @throws OutOfMemoryError if increasing {@code oldCapacity) by
>      *                          {@code growAtLeastBy} overfows.
>                                                       ~~~~~^
Thanks!  Both formatting and the typo are fixed in-place.

> 3. I know that this is not new and has been copied from the old code. However,
> I'm not sure I understand the meaning of "unless necessary" here:
>
>      /**
>       * The maximum size of array to allocate (unless necessary).
It means that if the minimum requested new capacity (oldCapacity + 
growAtLeastBy) is greater than MAX_ARRAY_SIZE (though still not greater 
than Integer.MAX_VALUE) then the result *will* be greater than 
MAX_ARRAY_SIZE.

Current implementation returns Integer.MAX_VALUE in this case.  I was 
thinking about changing it to returning the actual sum (oldCapacity + 
growAtLeastBy), but decided not to do that to preserve the behavior.

Practically, it shouldn't matter much, as both variants would likely 
lead to OOM anyway.

With kind regards,
Ivan

> -Pavel
>
>

-- 
With kind regards,
Ivan Gerasimov


From bob.vandette at oracle.com  Thu May  9 18:11:58 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Thu, 9 May 2019 14:11:58 -0400
Subject: RFR: 8221340 - [TESTBUG] TestCgroupMetrics.java fails after fix
 for JDK-8219562
In-Reply-To: <b6a77fc4-a26e-cfe4-af00-0882578f71e8@oracle.com>
References: <96BEE19C-9950-48E9-9B11-9EA6EADE9123@oracle.com>
 <d5e50bb5-7752-2437-1583-27391afa85ca@oracle.com>
 <72AC2E0E-DECA-4F48-83E6-B05E1D32B981@oracle.com>
 <b6a77fc4-a26e-cfe4-af00-0882578f71e8@oracle.com>
Message-ID: <5F53F597-9A5A-4A90-BF79-683304B80595@oracle.com>


> On May 9, 2019, at 1:47 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Hi Bob,
> 
> jdk/internal/platform/cgroupv1/SubSystem.java:
> 64: Is that the same as cgroupPath.startsWith(root)?  That might be slightly more readable.
> 

Sure, that works.  I?ll change it.

> Regardless, that looks fine.
> 
Thanks,
Bob.

> Roger
> 
> On 05/08/2019 10:24 AM, Bob Vandette wrote:
>> Thanks Misha!
>> 
>> Could I get a ?Review? from someone in core libs, please?
>> 
>> Bob.
>> 
>>> On May 7, 2019, at 8:49 PM, mikhailo.seledtsov at oracle.com <mailto:mikhailo.seledtsov at oracle.com> wrote:
>>> 
>>> Changes look good to me,
>>> 
>>> Misha
>>> 
>>> 
>>> On 5/7/19 5:56 AM, Bob Vandette wrote:
>>>> Please review this change to the Container Metrics implementation.
>>>> 
>>>> Change were made in JDK-8219562 [1] to osContainer_linux.cpp to correct
>>>> the parsing of of the /proc/self/mountinfo file but corresponding changes to the
>>>> Metrics API and Container tests shou,d have been done to match this change.
>>>> 
>>>> BUG:
>>>> https://bugs.openjdk.java.net/browse/JDK-8221340 <https://bugs.openjdk.java.net/browse/JDK-8221340>
>>>> 
>>>> WEBREV:
>>>> http://cr.openjdk.java.net/~bobv/8221340/webrev.00/ <http://cr.openjdk.java.net/~bobv/8221340/webrev.00/>
>>>> 
>>>> TESTING:
>>>> These changes were verified by running Mach5  tier1 and 2 tests and the jtreg container
>>>> tests on a Linux x64 system.
>>>> 
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8219562 <https://bugs.openjdk.java.net/browse/JDK-8219562>
>>>> 
>>>> Bob.
>>>> 
> 


From martinrb at google.com  Fri May 10 06:58:51 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 9 May 2019 23:58:51 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
Message-ID: <CA+kOe08mamtxfF0p0vJ4HU6v3TeZ-sqs7F536LkD-RrCWRTzNQ@mail.gmail.com>

History: I was responsible for some of these.  I considered refactoring but
did not because
- this was pre-module so no good way to share infrastructure.
- growth algorithm differed slightly between instances (looks like you've
solved this)

I agree this code is errorprone.

I might have more time to review later.

*From: *Ivan Gerasimov <ivan.gerasimov at oracle.com>
*Date: *Wed, May 8, 2019 at 6:50 PM
*To: *core-libs-dev

Hello!
>
> Jdk has several places with similar logic:  an array needs to be
> reallocated (by at least some defined amount), taking into account the
> maximum allowed size of arrays.
>
> There's clearly an opportunity for refactoring, so it is proposed to
> introduce a dedicated utility method for calculating the best new size
> of an array.
>
> Would you please help review this enhancement?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>
> Mach5 job ran fine.
>
> Thanks in advance!
>
> --
> With kind regards,
> Ivan Gerasimov
>
>

From peter.levart at gmail.com  Fri May 10 08:52:58 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 10 May 2019 10:52:58 +0200
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <14bb1a84-a375-ef00-90ae-a7f044a367a8@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <FE93EE7B-B6C7-4E3C-9203-1E141A1F795E@oracle.com>
 <14bb1a84-a375-ef00-90ae-a7f044a367a8@oracle.com>
Message-ID: <8430c4a7-2c67-0c79-a9bb-b1dd326338ff@gmail.com>

Hi Ivan,

On 5/9/19 8:07 PM, Ivan Gerasimov wrote:
>> 3. I know that this is not new and has been copied from the old code. 
>> However,
>> I'm not sure I understand the meaning of "unless necessary" here:
>>
>> ???? /**
>> ????? * The maximum size of array to allocate (unless necessary).
> It means that if the minimum requested new capacity (oldCapacity + 
> growAtLeastBy) is greater than MAX_ARRAY_SIZE (though still not 
> greater than Integer.MAX_VALUE) then the result *will* be greater than 
> MAX_ARRAY_SIZE.
>
> Current implementation returns Integer.MAX_VALUE in this case.? I was 
> thinking about changing it to returning the actual sum (oldCapacity + 
> growAtLeastBy), but decided not to do that to preserve the behavior.
>
> Practically, it shouldn't matter much, as both variants would likely 
> lead to OOM anyway.
>
> With kind regards,
> Ivan 

Is there a case where returning > MAX_ARRAY_SIZE will not lead to OOME?

If this utility method is meant for re-sizing arrays only (currently it 
is only used for that), then perhaps the method could throw OOME 
explicitly in this case. You already throw OOME for the overflow case, 
so currently the method is not uniform in returning exceptional values 
(i.e. values that lead to exceptions).

Unless you expect some VMs to tolerate arrays as large as 
Integer.MAX_VALUE ?

These lines:

 ?607???????? int newCapacity = oldCapacity + preferredGrowBy;
 ?608???????? if (preferredGrowBy < growAtLeastBy) {
 ?609???????????? newCapacity = oldCapacity + growAtLeastBy;
 ?610???????? }

...could perhaps be more easily grasped as:

int newCapacity = oldCapacity + Math.max(preferredGrowBy, growAtLeastBy);


Regards, Peter



From christoph.langer at sap.com  Fri May 10 09:17:29 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 10 May 2019 09:17:29 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
Message-ID: <AM6PR02MB5192FEC67CFDBA7821A0448E8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Daniel,

I fully agree, @SuppressWarnings should be avoided wherever possible.

So, thanks for coming up with this alternative suggestion. It works and so I updated my webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.1/  

Any reviews for the other 3 files?

Thanks
Christoph

> -----Original Message-----
> From: Daniel Fuchs <daniel.fuchs at oracle.com>
> Sent: Donnerstag, 9. Mai 2019 17:24
> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> Cc: compiler-dev at openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
> 
> Hi Christoph,
> 
> I'm only commenting on the HttpClient changes, I'll let
> others comment on the other changes...
> 
> http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/s
> hare/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html
> 
> I have a profound dislike for using @SuppressedWarnings, unless
> it's the only alternative. My preference would be to introduce
> local variables, if that can make the compiler happy, until such time
> where the issue is actually resolved...
> 
> For instance, it seems that the following would work:
> 
>      // Use local variable assignments to keep other java compilers
>      // happy and avoid unchecked casts warnings
>      BiFunction<Http2Connection, Throwable, CompletableFuture<? extends
> ExchangeImpl<U>>>
>          factory = (h2c, t) -> createExchangeImpl(h2c, t, exchange,
> connection);
>      Function<CompletableFuture<? extends ExchangeImpl<U>>,
> CompletableFuture<? extends ExchangeImpl<U>>>
>          identity = (cf) -> cf;
>      return c2f.handle(factory).thenCompose(identity);
> 
> 
> best regards,
> 
> -- daniel
> 
> On 08/05/2019 09:02, Langer, Christoph wrote:
> > Hi,
> >
> > please review a small change that I'd like to see in OpenJDK to get rid
> > of compilation errors in the Eclipse IDE.
> >
> > It seems the root cause for the compilation errors is that javac would
> > sometimes widen capture variables and is hence able to compile the
> > places that I touch here. The EC4J compiler claims that it's following
> > the spec more strictly and bails out at these places. I had posted about
> > this on compiler-dev but got no reaction [0].
> >
> > So, as this seems to be some field of open work for the compiler/spec
> > folks, I'd like to get EC4J quiesced by introducing some slight
> > modifications to the original places which makes the code appeal a bit
> > less elegant and fluent but will get rid of the compile errors.
> >
> > Please review:
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8223553
> >
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/
> >
> > The modification to
> >
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav
> a
> > belongs to JSR-166, so I don't know if it needs some special handling.
> >
> > Thanks & Best regards
> >
> > Christoph
> >
> > [0]
> > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-
> March/013054.html
> >


From pavel.rappo at oracle.com  Fri May 10 11:06:05 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 10 May 2019 12:06:05 +0100
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <8430c4a7-2c67-0c79-a9bb-b1dd326338ff@gmail.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <FE93EE7B-B6C7-4E3C-9203-1E141A1F795E@oracle.com>
 <14bb1a84-a375-ef00-90ae-a7f044a367a8@oracle.com>
 <8430c4a7-2c67-0c79-a9bb-b1dd326338ff@gmail.com>
Message-ID: <36636CEA-38D3-4961-87BD-8E29DA100D1E@oracle.com>

> On 10 May 2019, at 09:52, Peter Levart <peter.levart at gmail.com> wrote:
> 
> <snip>
> 
> Is there a case where returning > MAX_ARRAY_SIZE will not lead to OOME?
> 
> If this utility method is meant for re-sizing arrays only (currently it is only used for that), then perhaps the method could throw OOME explicitly in this case. You already throw OOME for the overflow case, so currently the method is not uniform in returning exceptional values (i.e. values that lead to exceptions).
> 
> Unless you expect some VMs to tolerate arrays as large as Integer.MAX_VALUE ?

I think the proposed behaviour is equivalent to what there is now. After all,
it's a refactoring effort and as such *should* result in equivalent behaviour.

If understand you correctly, your question can be answered by answering 

    Why there is MAX_ARRAY_SIZE in the first place?

> These lines:
> 
>  607         int newCapacity = oldCapacity + preferredGrowBy;
>  608         if (preferredGrowBy < growAtLeastBy) {
>  609             newCapacity = oldCapacity + growAtLeastBy;
>  610         }
> 
> ...could perhaps be more easily grasped as:
> 
> int newCapacity = oldCapacity + Math.max(preferredGrowBy, growAtLeastBy);

I'm not an expert here, but if I understood Ivan correctly, the purpose was to
avoid branching. Maybe intrinsified Math.max is superior in both readability and
performance. I simply don't know. If you feel strongly about using it, you could
maybe compare those approaches by benchmarking.


From deepak.kejriwal at oracle.com  Fri May 10 11:25:37 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Fri, 10 May 2019 11:25:37 +0000 (UTC)
Subject: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker incorrect
 for Peru
Message-ID: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default>

Hello,

 

Please review the fix to the following issue:

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

 

The proposed fix is located at:

http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/

 

Summary

In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.).

 

Regard,

Deepak

 

From naoto.sato at oracle.com  Fri May 10 12:42:08 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 10 May 2019 05:42:08 -0700
Subject: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker
 incorrect for Peru
In-Reply-To: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default>
References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default>
Message-ID: <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com>

Hi Deepak, here are my comments.

- FormatData_es_PE.java: Modify the copyright year to 2019.

- Changes in "LocaleData" may be placed at the bottom of the file, 
explicitly indicating it is changed with 8206879. Please follow the 
similar changes' format.

- Bug8206879.java does not have proper copyright header.

Naoto

On 5/10/19 4:25 AM, Deepak Kejriwal wrote:
> Hello,
> 
>   
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8206879
> 
>   
> 
> The proposed fix is located at:
> 
> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/
> 
>   
> 
> Summary
> 
> In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.).
> 
>   
> 
> Regard,
> 
> Deepak
> 
>   
> 

From pavel.rappo at oracle.com  Fri May 10 13:22:51 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 10 May 2019 14:22:51 +0100
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
Message-ID: <A11A0A48-2349-48D2-954F-124CEC548015@oracle.com>

Ivan,

There seem to be more places that use a somewhat similar pattern. I was
wondering if you have seen them and decided not to include them in your patch
for some reason (e.g. they really are quite different)?

Here are some of them:

    java.io.BufferedInputStream
    java.io.InputStream
    java.lang.AbstractStringBuilder
    java.nio.file.Files
    java.util.ArrayDeque
    java.util.Hashtable
    java.util.concurrent.ConcurrentHashMap
    java.util.concurrent.PriorityBlockingQueue
    java.util.regex.Pattern.quote

There is also some number of occurrences in the jdk.* modules.

> On 9 May 2019, at 02:50, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> Hello!
> 
> Jdk has several places with similar logic:  an array needs to be reallocated (by at least some defined amount), taking into account the maximum allowed size of arrays.
> 
> There's clearly an opportunity for refactoring, so it is proposed to introduce a dedicated utility method for calculating the best new size of an array.
> 
> Would you please help review this enhancement?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
> 
> Mach5 job ran fine.
> 
> Thanks in advance!
> 
> -- 
> With kind regards,
> Ivan Gerasimov
> 


From Roger.Riggs at oracle.com  Fri May 10 14:41:28 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 10 May 2019 10:41:28 -0400
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <36636CEA-38D3-4961-87BD-8E29DA100D1E@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <FE93EE7B-B6C7-4E3C-9203-1E141A1F795E@oracle.com>
 <14bb1a84-a375-ef00-90ae-a7f044a367a8@oracle.com>
 <8430c4a7-2c67-0c79-a9bb-b1dd326338ff@gmail.com>
 <36636CEA-38D3-4961-87BD-8E29DA100D1E@oracle.com>
Message-ID: <1f34a649-e7c3-d8be-f95a-753c62d89e02@oracle.com>

Hi Ivan,

Thanks for refactoring[1] this sensitive function.

ArraySupport.java:

Line 33: Please add a period at the end of the sentence.
 ? I would have added a new sentence instead of mixing functions.

Line 583: Making MAX_ARRAY_SIZE public would make it accessible within 
java.base module.

Line 592: 'necessary' seems a bit vague. can you be specific.

Line 595-596: Since these are javadoc'd parameters, can you add the 
assumption that they are? non-negative implied by the asserts.

605: Does the assert growAtleastBy > 0 imply that the caller needs to 
check for zero or will get undefined behavior?
 ? I don't see a reason to require either atLeast or preferred to be 
non-zero or to leave the behavior undefined if they are.
 ? The asserts themselves are marginally useful except as documentation 
since they are inoperative in production builds but take up bytecode.

607-610:? As Peter suggested, would clearer using Math.max and would be 
intrinsified.

617:? A concern about the utility method throwing the OOM exception vs 
just returning a sentinel value
 ? is that this utility method will be expensive to use in other 
situations where the caller does not
 ? want to throw an exception and it buries the exception in a named 
method that does not clearly have to throw.
 ? On the pro-side, the location of the exception clearly identifies 
overflow as the cause.

ByteArrayOutputStream:
92: Please add a period at the end of the sentence.

98:? I think you've dropped the normal doubling of the buffer size that 
comes from old line 115.
 ? The buffer should be doubling in size, but at least minsize.

PriorityQueue.java is part of JSR 166 and the changes should be done 
upstream or deferred due to adding a dependency on a JDK 13 API.

Thanks, Roger

[1] http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/index.html


On 05/10/2019 07:06 AM, Pavel Rappo wrote:
>> On 10 May 2019, at 09:52, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> <snip>
>>
>> Is there a case where returning > MAX_ARRAY_SIZE will not lead to OOME?
>>
>> If this utility method is meant for re-sizing arrays only (currently it is only used for that), then perhaps the method could throw OOME explicitly in this case. You already throw OOME for the overflow case, so currently the method is not uniform in returning exceptional values (i.e. values that lead to exceptions).
>>
>> Unless you expect some VMs to tolerate arrays as large as Integer.MAX_VALUE ?
> I think the proposed behaviour is equivalent to what there is now. After all,
> it's a refactoring effort and as such *should* result in equivalent behaviour.
>
> If understand you correctly, your question can be answered by answering
>
>      Why there is MAX_ARRAY_SIZE in the first place?
>
>> These lines:
>>
>>   607         int newCapacity = oldCapacity + preferredGrowBy;
>>   608         if (preferredGrowBy < growAtLeastBy) {
>>   609             newCapacity = oldCapacity + growAtLeastBy;
>>   610         }
>>
>> ...could perhaps be more easily grasped as:
>>
>> int newCapacity = oldCapacity + Math.max(preferredGrowBy, growAtLeastBy);
> I'm not an expert here, but if I understood Ivan correctly, the purpose was to
> avoid branching. Maybe intrinsified Math.max is superior in both readability and
> performance. I simply don't know. If you feel strongly about using it, you could
> maybe compare those approaches by benchmarking.
>


From pavel.rappo at oracle.com  Fri May 10 15:11:24 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 10 May 2019 16:11:24 +0100
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <1f34a649-e7c3-d8be-f95a-753c62d89e02@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <FE93EE7B-B6C7-4E3C-9203-1E141A1F795E@oracle.com>
 <14bb1a84-a375-ef00-90ae-a7f044a367a8@oracle.com>
 <8430c4a7-2c67-0c79-a9bb-b1dd326338ff@gmail.com>
 <36636CEA-38D3-4961-87BD-8E29DA100D1E@oracle.com>
 <1f34a649-e7c3-d8be-f95a-753c62d89e02@oracle.com>
Message-ID: <EE57243F-0F2B-432C-858C-B6034EBED966@oracle.com>

> On 10 May 2019, at 15:41, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> 98:  I think you've dropped the normal doubling of the buffer size that comes from old line 115.
>   The buffer should be doubling in size, but at least minsize.

I thought about it too initially. But then I reproduced that function. It seemed
to be doing the right thing. What it boils down to is this:

    oldCapacity + oldCapacity

In other words, doubling in size, as required. Or am I missing something?

> PriorityQueue.java is part of JSR 166 and the changes should be done upstream or deferred due to adding a dependency on a JDK 13 API.

I understand that. First, ArraysSupport changes, then JSR 166 changes, finally
JDK gets that last change from the JSR 166 repo.

Thanks Roger.


From Roger.Riggs at oracle.com  Fri May 10 19:39:34 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 10 May 2019 15:39:34 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <75e4b0f4-0403-a565-c20d-7143957578af@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
 <e9c71491-fbe0-3874-4f6f-06cc839e5990@oracle.com>
 <75e4b0f4-0403-a565-c20d-7143957578af@oracle.com>
Message-ID: <b8417342-3499-5a85-fed5-0e4b2921e803@oracle.com>

Hi Andy,

Thanks for logging the issues.
>>
>> CLIHelp:
>> ?- 58, 65, 72, 80: Indentation of pLaunchOptions does not line up.
> I don't see what you mean here.? Looks lined up to me
The lines with pLaunchOptions have tabs instead of spaces.
jcheck has some complaints about tabs and trailing spaces.

>>
>> IOUtils:
>> ?- 262: why the mix of ProcessBuilder and Runtime.exec? - stick to 
>> ProcessBuilder
> added to this case to JDK-8223334
>>
>> Log:
>> ?? "JPACKAGE_DEBUG" environment variable - ? uppercase, documented?
> implemented as strictly upper case, what do we have to do to document ?
Usually java applications use system properties, not environment variables.
I can see the need for access to PATH to find the tools, but a debugging 
flag seems like an outlier.
I suppose it is an undocumented implementation detail and does not need 
to be documented.

Thanks, Roger


From andy.herrick at oracle.com  Fri May 10 19:44:09 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 10 May 2019 15:44:09 -0400
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <b8417342-3499-5a85-fed5-0e4b2921e803@oracle.com>
References: <0bd5501f-9db0-f22a-c4f1-4e284a43021f@oracle.com>
 <35c5208f-449b-8df2-d652-adb7f77e3ca2@oracle.com>
 <e9c71491-fbe0-3874-4f6f-06cc839e5990@oracle.com>
 <75e4b0f4-0403-a565-c20d-7143957578af@oracle.com>
 <b8417342-3499-5a85-fed5-0e4b2921e803@oracle.com>
Message-ID: <6597b2c6-18a4-4ae2-72bf-8205533a15e1@oracle.com>



On 5/10/2019 3:39 PM, Roger Riggs wrote:
> Hi Andy,
>
> Thanks for logging the issues.
>>>
>>> CLIHelp:
>>> ?- 58, 65, 72, 80: Indentation of pLaunchOptions does not line up.
>> I don't see what you mean here.? Looks lined up to me
> The lines with pLaunchOptions have tabs instead of spaces.
> jcheck has some complaints about tabs and trailing spaces. 
OK - this was already fixed with JDK-8223189.
Thanks.
/Andy

From ivan.gerasimov at oracle.com  Fri May 10 21:36:26 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 10 May 2019 14:36:26 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <8430c4a7-2c67-0c79-a9bb-b1dd326338ff@gmail.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <FE93EE7B-B6C7-4E3C-9203-1E141A1F795E@oracle.com>
 <14bb1a84-a375-ef00-90ae-a7f044a367a8@oracle.com>
 <8430c4a7-2c67-0c79-a9bb-b1dd326338ff@gmail.com>
Message-ID: <79efab7f-285d-3dce-7bcc-5318b75441a6@oracle.com>

Hi Peter!

Thank you for reviewing!


On 5/10/19 1:52 AM, Peter Levart wrote:
> Hi Ivan,
>
> On 5/9/19 8:07 PM, Ivan Gerasimov wrote:
>>> 3. I know that this is not new and has been copied from the old 
>>> code. However,
>>> I'm not sure I understand the meaning of "unless necessary" here:
>>>
>>>      /**
>>>       * The maximum size of array to allocate (unless necessary).
>> It means that if the minimum requested new capacity (oldCapacity + 
>> growAtLeastBy) is greater than MAX_ARRAY_SIZE (though still not 
>> greater than Integer.MAX_VALUE) then the result *will* be greater 
>> than MAX_ARRAY_SIZE.
>>
>> Current implementation returns Integer.MAX_VALUE in this case. I was 
>> thinking about changing it to returning the actual sum (oldCapacity + 
>> growAtLeastBy), but decided not to do that to preserve the behavior.
>>
>> Practically, it shouldn't matter much, as both variants would likely 
>> lead to OOM anyway.
>>
>> With kind regards,
>> Ivan 
>
> Is there a case where returning > MAX_ARRAY_SIZE will not lead to OOME?
>
Yes.  I just tried (successfully) and could allocate up to 
byte[Integer.MAX_INTEGER - 2].
Greater size result in OutOfMemoryError: Requested array size exceeds VM 
limit.

> If this utility method is meant for re-sizing arrays only (currently 
> it is only used for that), then perhaps the method could throw OOME 
> explicitly in this case. You already throw OOME for the overflow case, 
> so currently the method is not uniform in returning exceptional values 
> (i.e. values that lead to exceptions).
>
> Unless you expect some VMs to tolerate arrays as large as 
> Integer.MAX_VALUE ?
>
I prefer to go conservative with this refactoring, and preserve the 
behavior as close as possible to the current one.

Later, I think, it could be reconsidered.
For example, as I wrote earlier, it may be desirable to make 
hugeCapacity(minCapacity) return minCapacity instead of Integer.MAX_VALUE.

For now, I'd rather keep the implementation to minimize risk of regressions.

> These lines:
>
>  607         int newCapacity = oldCapacity + preferredGrowBy;
>  608         if (preferredGrowBy < growAtLeastBy) {
>  609             newCapacity = oldCapacity + growAtLeastBy;
>  610         }
>
> ...could perhaps be more easily grasped as:
>
> int newCapacity = oldCapacity + Math.max(preferredGrowBy, growAtLeastBy);
>

Okay, let's do it with Math.max().  I'll update the webrev shortly.

Thank you!

Ivan



> Regards, Peter
>
>

-- 
With kind regards,
Ivan Gerasimov


From ivan.gerasimov at oracle.com  Fri May 10 22:29:17 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 10 May 2019 15:29:17 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <1f34a649-e7c3-d8be-f95a-753c62d89e02@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <FE93EE7B-B6C7-4E3C-9203-1E141A1F795E@oracle.com>
 <14bb1a84-a375-ef00-90ae-a7f044a367a8@oracle.com>
 <8430c4a7-2c67-0c79-a9bb-b1dd326338ff@gmail.com>
 <36636CEA-38D3-4961-87BD-8E29DA100D1E@oracle.com>
 <1f34a649-e7c3-d8be-f95a-753c62d89e02@oracle.com>
Message-ID: <1352d04a-3aa7-f21a-634e-1004ee6f06b6@oracle.com>

Thank you Roger so much for valuable feedback!


On 5/10/19 7:41 AM, Roger Riggs wrote:
> Hi Ivan,
>
> Thanks for refactoring[1] this sensitive function.
>
> ArraySupport.java:
>
> Line 33: Please add a period at the end of the sentence.
>   I would have added a new sentence instead of mixing functions.
>
Done.

> Line 583: Making MAX_ARRAY_SIZE public would make it accessible within 
> java.base module.
>
Right, done.
I was wondering if this value could be requested from VM, so we wouldn't 
have to guess with '- 8'.

> Line 592: 'necessary' seems a bit vague. can you be specific.

Okay.
Added clarification that the requirement is to return at least 
(oldCapacity + growAtleastBy), which was meant by 'necessary'.

>
> Line 595-596: Since these are javadoc'd parameters, can you add the 
> assumption that they are  non-negative implied by the asserts.
>
Done.

> 605: Does the assert growAtleastBy > 0 imply that the caller needs to 
> check for zero or will get undefined behavior?
>   I don't see a reason to require either atLeast or preferred to be 
> non-zero or to leave the behavior undefined if they are.
This function is only called in a context where it is known for sure 
there will be re-allocation.
Thus the assumption growAtleastBy > 0.
For the other argument, preferredGrowBy, there are no restrictions.

>   The asserts themselves are marginally useful except as documentation 
> since they are inoperative in production builds but take up bytecode.
Good point.  I commented them out (just as all other asserts in this file).
>
> 607-610:  As Peter suggested, would clearer using Math.max and would 
> be intrinsified.
>
Done.

> 617:  A concern about the utility method throwing the OOM exception vs 
> just returning a sentinel value
>   is that this utility method will be expensive to use in other 
> situations where the caller does not
>   want to throw an exception and it buries the exception in a named 
> method that does not clearly have to throw.
>   On the pro-side, the location of the exception clearly identifies 
> overflow as the cause.
>
I agree, that it wouldn't be the greatest design for public API.

In this case, however, the function is specially designed to be used in 
specific context.
The branch that throws OOM is expected to be rarely executed, so having 
it in a separate method may help Hotspot avoid unnecessary optimization 
of that code.

> ByteArrayOutputStream:
> 92: Please add a period at the end of the sentence.
>
Done.

> 98:  I think you've dropped the normal doubling of the buffer size 
> that comes from old line 115.
>   The buffer should be doubling in size, but at least minsize.
>
The code looks correct, actually.
I see, Pavel already explained that passing oldCapacity as 
preferredGrowBy results in doubling the capacity.

> PriorityQueue.java is part of JSR 166 and the changes should be done 
> upstream or deferred due to adding a dependency on a JDK 13 API.
>
Oops, is it?
I noticed that PriorityQueue.java has typical Oracle copyright header 
unlike the files like Deque.java or everything from concurrency package.

The mercurial history suggests that PriorityQueue.java has been modified 
via OpenJDK process, e.g.
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a6cbb9808e4b

I can drop the changes in this file, if we don't own this code.

With kind regards,
Ivan


> Thanks, Roger
>
> [1] http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/index.html
>
>
> On 05/10/2019 07:06 AM, Pavel Rappo wrote:
>>> On 10 May 2019, at 09:52, Peter Levart <peter.levart at gmail.com> wrote:
>>>
>>> <snip>
>>>
>>> Is there a case where returning > MAX_ARRAY_SIZE will not lead to OOME?
>>>
>>> If this utility method is meant for re-sizing arrays only (currently 
>>> it is only used for that), then perhaps the method could throw OOME 
>>> explicitly in this case. You already throw OOME for the overflow 
>>> case, so currently the method is not uniform in returning 
>>> exceptional values (i.e. values that lead to exceptions).
>>>
>>> Unless you expect some VMs to tolerate arrays as large as 
>>> Integer.MAX_VALUE ?
>> I think the proposed behaviour is equivalent to what there is now. 
>> After all,
>> it's a refactoring effort and as such *should* result in equivalent 
>> behaviour.
>>
>> If understand you correctly, your question can be answered by answering
>>
>>      Why there is MAX_ARRAY_SIZE in the first place?
>>
>>> These lines:
>>>
>>>   607         int newCapacity = oldCapacity + preferredGrowBy;
>>>   608         if (preferredGrowBy < growAtLeastBy) {
>>>   609             newCapacity = oldCapacity + growAtLeastBy;
>>>   610         }
>>>
>>> ...could perhaps be more easily grasped as:
>>>
>>> int newCapacity = oldCapacity + Math.max(preferredGrowBy, 
>>> growAtLeastBy);
>> I'm not an expert here, but if I understood Ivan correctly, the 
>> purpose was to
>> avoid branching. Maybe intrinsified Math.max is superior in both 
>> readability and
>> performance. I simply don't know. If you feel strongly about using 
>> it, you could
>> maybe compare those approaches by benchmarking.
>>
>
>

-- 
With kind regards,
Ivan Gerasimov


From ivan.gerasimov at oracle.com  Fri May 10 23:05:52 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 10 May 2019 16:05:52 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <A11A0A48-2349-48D2-954F-124CEC548015@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <A11A0A48-2349-48D2-954F-124CEC548015@oracle.com>
Message-ID: <39e69968-42b8-dd82-0d2f-18c8cb70098a@oracle.com>

Thank you Pavel for the investigation!

I've seen some of these places, and decided not to touch them with this 
refactoring for various reasons:

java.lang.AbstractStringBuilder - the case has additional complication 
due to interference of coder.  It may make sense to refactor it later 
within a separate enhancement.

java.io.InputStream - do you mean readNBytes()?  It uses different 
strategy: instead of reallocating an array of greater size it maintains 
a list of chunks that are combined on a final step.

java.util.ArrayDeque, java.util.concurrent.* - as Roger has mentioned, 
these belong to JSR-166 project.

java.util.Hashtable - It could actually be refactored with the code like 
this:
+        int newCapacity = ArraysSupport.newCapacity(oldCapacity, 0, 
oldCapacity + 1);
+        if (newCapacity == oldCapacity) {
+            // Keep running with MAX_ARRAY_SIZE buckets
+            return;
+        }

Though, I don't think it's worth doing this because it would separate 
logic around MAX_ARRAY_SIZE across different files.

java.util.regex.Pattern.quote - It also could be refactored as
+    int lenHint = ArraysSupport.newCapacity(s.length(), 0, s.length());

I'm not certain it would add much clarity to the code, so let's leave it 
aside for now.

java.io.BufferedInputStream and java.nio.file.Files - Oh, I missed these 
two.  Thank you for pointing me to them!

I'll share the updated webrev shortly.

With kind regards,
Ivan


On 5/10/19 6:22 AM, Pavel Rappo wrote:
> Ivan,
>
> There seem to be more places that use a somewhat similar pattern. I was
> wondering if you have seen them and decided not to include them in your patch
> for some reason (e.g. they really are quite different)?
>
> Here are some of them:
>
>      java.io.BufferedInputStream
>      java.io.InputStream
>      java.lang.AbstractStringBuilder
>      java.nio.file.Files
>      java.util.ArrayDeque
>      java.util.Hashtable
>      java.util.concurrent.ConcurrentHashMap
>      java.util.concurrent.PriorityBlockingQueue
>      java.util.regex.Pattern.quote
>
> There is also some number of occurrences in the jdk.* modules.
>
>> On 9 May 2019, at 02:50, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> Hello!
>>
>> Jdk has several places with similar logic:  an array needs to be reallocated (by at least some defined amount), taking into account the maximum allowed size of arrays.
>>
>> There's clearly an opportunity for refactoring, so it is proposed to introduce a dedicated utility method for calculating the best new size of an array.
>>
>> Would you please help review this enhancement?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>>
>> Mach5 job ran fine.
>>
>> Thanks in advance!
>>
>> -- 
>> With kind regards,
>> Ivan Gerasimov
>>
>

-- 
With kind regards,
Ivan Gerasimov


From ivan.gerasimov at oracle.com  Sat May 11 04:01:46 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 10 May 2019 21:01:46 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
Message-ID: <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>

Hello!

Please help review the updated fix.

This new webrev includes changes suggested by Pavel, Peter and Roger.

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

Please note that the behavior of j.n.f.Files.readAllBytes() has changed 
slightly, so now it *may* be possible to read a file larger than 
(Integer.MAX_VALUE - 8), if VM is able to allocate that large array.

With kind regards,
Ivan

On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
> Hello!
>
> Jdk has several places with similar logic:  an array needs to be 
> reallocated (by at least some defined amount), taking into account the 
> maximum allowed size of arrays.
>
> There's clearly an opportunity for refactoring, so it is proposed to 
> introduce a dedicated utility method for calculating the best new size 
> of an array.
>
> Would you please help review this enhancement?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>
> Mach5 job ran fine.
>
> Thanks in advance!
>

-- 
With kind regards,
Ivan Gerasimov


From forax at univ-mlv.fr  Sat May 11 14:48:14 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 11 May 2019 16:48:14 +0200 (CEST)
Subject: Process.exec with the linux posix_spawn mode has a bug
Message-ID: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>

I've seen a weird error on my CI [1] since the 15th of February when using the jdk 13,
i was not able to run jshell* using the programmatic API (java tool) anymore.

Yesterday, i took the time to track that issue and i believe i've found the root cause, trying to execute the java launcher using ProcessBuilder.start() with the jdk 13 sometimes fails with an i/o exception (errno 13) which is weird because you are trying to execute the same process that the one you are executing. Note that this is a spurious bug, I was not able to find the exact condition that triggers that bug.
So sometime it works, sometime it doesn't.

If i pass -Djdk.lang.Process.launchMechanism=fork (or vfork) when starting the VM, the bug disappear meaning that the bug occurs when the VM is trying to use posix_spawn, perhaps spawn is trying to do an optimization when you try to execute the same process as the one you are running under some conditions ?

Given the use of posix_spawn by default was enabled by the changeset f037d1a2e899 at the beginning of February, i believe i've spotted the issue.

regards,
R?mi


[1] https://travis-ci.org/forax/pratt_parser/jobs/493756422
[2] http://hg.openjdk.java.net/jdk/jdk/file/f037d1a2e899/src/java.base/unix/classes/java/lang/ProcessImpl.java

* jshell works by spawning and controlling a new VM.

From david.lloyd at redhat.com  Sat May 11 15:14:56 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Sat, 11 May 2019 10:14:56 -0500
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
Message-ID: <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>

On Sat, May 11, 2019 at 9:49 AM Remi Forax <forax at univ-mlv.fr> wrote:
>
> I've seen a weird error on my CI [1] since the 15th of February when using the jdk 13,
> i was not able to run jshell* using the programmatic API (java tool) anymore.
>
> Yesterday, i took the time to track that issue and i believe i've found the root cause, trying to execute the java launcher using ProcessBuilder.start() with the jdk 13 sometimes fails with an i/o exception (errno 13) which is weird because you are trying to execute the same process that the one you are executing. Note that this is a spurious bug, I was not able to find the exact condition that triggers that bug.
> So sometime it works, sometime it doesn't.

Assuming you're running on Linux (given that the changeset only
applies to Linux), errno 13 is EACCES which would indicate a
filesystem permission issue.  Are you sure you have permission to
execute `jspawnhelper` in your JVM installation?  Could there be an
SELinux restriction in place?

Here's what the man page says:

```

     [EACCES]           Search permission is denied for a component of
the path prefix.


     [EACCES]           The new process file is not an ordinary file.


     [EACCES]           The new process file mode denies execute permission.


     [EACCES]           The new process file is on a filesystem
mounted with execution

                        disabled (MNT_NOEXEC in <sys/mount.h>).
```

> If i pass -Djdk.lang.Process.launchMechanism=fork (or vfork) when starting the VM, the bug disappear meaning that the bug occurs when the VM is trying to use posix_spawn, perhaps spawn is trying to do an optimization when you try to execute the same process as the one you are running under some conditions ?

The posix_spawn approach executes an intermediate support process
(`jspawnhelper`) which in turn executes the target process.  I believe
there's an extensive discussion on the reasons for this in the
`core-libs-dev` archive.


-- 
- DML

From thomas.stuefe at gmail.com  Sat May 11 18:49:02 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 11 May 2019 20:49:02 +0200
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
Message-ID: <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>

Hi Remi,

David is right - a few more details:

In both fork- and vfork-mode we fork/vfork the child process and in the
child process then exec() the target binary (in this case "java" itself).

In posix_spawn mode, for complicated reasons, we start, via posix_spawn(),
the jspawnhelper - which, depending on the glibc involved, will either
vfork() or clone() the child process and then exec() the jspawnhelper
binary. Then, inside the jspawnhelper, we will exec() a second time, this
time the target binary.

(So, small correction, we do not have an intermediate _process_ here - at
any time only two processes are involved, the parent and the child - but
inside the child we call exec() twice.)

If you get EACCESS only in posix_spawn() mode, the only difference to
fork/vfork is that we exec() jspawnhelper. That is a binary located in the
jdk and should have the correct permissions set.

If you have a reproducible scenario, can you strace the call? (you would
probably need "strace -f", and if you see in the output the jspawnhelper
path with either _vfork or _clone system calls it worked).

Cheers, Thomas

On Sat, May 11, 2019 at 5:15 PM David Lloyd <david.lloyd at redhat.com> wrote:

> On Sat, May 11, 2019 at 9:49 AM Remi Forax <forax at univ-mlv.fr> wrote:
> >
> > I've seen a weird error on my CI [1] since the 15th of February when
> using the jdk 13,
> > i was not able to run jshell* using the programmatic API (java tool)
> anymore.
> >
> > Yesterday, i took the time to track that issue and i believe i've found
> the root cause, trying to execute the java launcher using
> ProcessBuilder.start() with the jdk 13 sometimes fails with an i/o
> exception (errno 13) which is weird because you are trying to execute the
> same process that the one you are executing. Note that this is a spurious
> bug, I was not able to find the exact condition that triggers that bug.
> > So sometime it works, sometime it doesn't.
>
> Assuming you're running on Linux (given that the changeset only
> applies to Linux), errno 13 is EACCES which would indicate a
> filesystem permission issue.  Are you sure you have permission to
> execute `jspawnhelper` in your JVM installation?  Could there be an
> SELinux restriction in place?
>
> Here's what the man page says:
>
> ```
>
>      [EACCES]           Search permission is denied for a component of
> the path prefix.
>
>
>      [EACCES]           The new process file is not an ordinary file.
>
>
>      [EACCES]           The new process file mode denies execute
> permission.
>
>
>      [EACCES]           The new process file is on a filesystem
> mounted with execution
>
>                         disabled (MNT_NOEXEC in <sys/mount.h>).
> ```
>
> > If i pass -Djdk.lang.Process.launchMechanism=fork (or vfork) when
> starting the VM, the bug disappear meaning that the bug occurs when the VM
> is trying to use posix_spawn, perhaps spawn is trying to do an optimization
> when you try to execute the same process as the one you are running under
> some conditions ?
>
> The posix_spawn approach executes an intermediate support process
> (`jspawnhelper`) which in turn executes the target process.  I believe
> there's an extensive discussion on the reasons for this in the
> `core-libs-dev` archive.
>
>
> --
> - DML
>

From ivan.gerasimov at oracle.com  Sat May 11 22:07:49 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sat, 11 May 2019 15:07:49 -0700
Subject: RFR 8223730 : URLClassLoader.findClass() can throw
 IndexOutOfBoundsException
Message-ID: <af4c0c4a-507b-780f-37a7-b44b96a40f99@oracle.com>

Hello!

An integer overflow during array size calculation can happen in a case 
of loading extremely huge class file (which is unlikely in the real world).

It is possible to create a regression test (see the bug), though I doubt 
it would carry much weight while requiring much memory.

I did check manually that the POC runs fine with the patched JDK.

Would you please help review the fix?

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

-- 
With kind regards,
Ivan Gerasimov


From forax at univ-mlv.fr  Sun May 12 08:20:28 2019
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 12 May 2019 10:20:28 +0200 (CEST)
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
Message-ID: <2123972130.1727577.1557649228090.JavaMail.zimbra@u-pem.fr>

Hi David,
spot on !

jspawnhelper had no execution permission (i overlook that in my installation process).

I wonder if the exception message can be improved to indicate that the issue is on jspawnhelper and not on the program i want to execute.

Thanks a lot,
R?mi

----- Mail original -----
> De: "David Lloyd" <david.lloyd at redhat.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Roger Riggs" <Roger.Riggs at oracle.com>, "Alan Bateman"
> <Alan.Bateman at oracle.com>
> Envoy?: Samedi 11 Mai 2019 17:14:56
> Objet: Re: Process.exec with the linux posix_spawn mode has a bug

> On Sat, May 11, 2019 at 9:49 AM Remi Forax <forax at univ-mlv.fr> wrote:
>>
>> I've seen a weird error on my CI [1] since the 15th of February when using the
>> jdk 13,
>> i was not able to run jshell* using the programmatic API (java tool) anymore.
>>
>> Yesterday, i took the time to track that issue and i believe i've found the root
>> cause, trying to execute the java launcher using ProcessBuilder.start() with
>> the jdk 13 sometimes fails with an i/o exception (errno 13) which is weird
>> because you are trying to execute the same process that the one you are
>> executing. Note that this is a spurious bug, I was not able to find the exact
>> condition that triggers that bug.
>> So sometime it works, sometime it doesn't.
> 
> Assuming you're running on Linux (given that the changeset only
> applies to Linux), errno 13 is EACCES which would indicate a
> filesystem permission issue.  Are you sure you have permission to
> execute `jspawnhelper` in your JVM installation?  Could there be an
> SELinux restriction in place?
> 
> Here's what the man page says:
> 
> ```
> 
>     [EACCES]           Search permission is denied for a component of
> the path prefix.
> 
> 
>     [EACCES]           The new process file is not an ordinary file.
> 
> 
>     [EACCES]           The new process file mode denies execute permission.
> 
> 
>     [EACCES]           The new process file is on a filesystem
> mounted with execution
> 
>                        disabled (MNT_NOEXEC in <sys/mount.h>).
> ```
> 
>> If i pass -Djdk.lang.Process.launchMechanism=fork (or vfork) when starting the
>> VM, the bug disappear meaning that the bug occurs when the VM is trying to use
>> posix_spawn, perhaps spawn is trying to do an optimization when you try to
>> execute the same process as the one you are running under some conditions ?
> 
> The posix_spawn approach executes an intermediate support process
> (`jspawnhelper`) which in turn executes the target process.  I believe
> there's an extensive discussion on the reasons for this in the
> `core-libs-dev` archive.
> 
> 
> --
> - DML

From forax at univ-mlv.fr  Sun May 12 08:23:54 2019
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 12 May 2019 10:23:54 +0200 (CEST)
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
 <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
Message-ID: <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>

Thanks Thomas, 
by the way, what is the purpose of jexec ? 

R?mi 

> De: "Thomas St?fe" <thomas.stuefe at gmail.com>
> ?: "David Lloyd" <david.lloyd at redhat.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Samedi 11 Mai 2019 20:49:02
> Objet: Re: Process.exec with the linux posix_spawn mode has a bug

> Hi Remi,

> David is right - a few more details:
> In both fork- and vfork-mode we fork/vfork the child process and in the child
> process then exec() the target binary (in this case "java" itself).

> In posix_spawn mode, for complicated reasons, we start, via posix_spawn(), the
> jspawnhelper - which, depending on the glibc involved, will either vfork() or
> clone() the child process and then exec() the jspawnhelper binary. Then, inside
> the jspawnhelper, we will exec() a second time, this time the target binary.

> (So, small correction, we do not have an intermediate _process_ here - at any
> time only two processes are involved, the parent and the child - but inside the
> child we call exec() twice.)

> If you get EACCESS only in posix_spawn() mode, the only difference to fork/vfork
> is that we exec() jspawnhelper. That is a binary located in the jdk and should
> have the correct permissions set.

> If you have a reproducible scenario, can you strace the call? (you would
> probably need "strace -f", and if you see in the output the jspawnhelper path
> with either _vfork or _clone system calls it worked).

> Cheers, Thomas

> On Sat, May 11, 2019 at 5:15 PM David Lloyd < [ mailto:david.lloyd at redhat.com |
> david.lloyd at redhat.com ] > wrote:

>> On Sat, May 11, 2019 at 9:49 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>>> I've seen a weird error on my CI [1] since the 15th of February when using the
>> > jdk 13,
>> > i was not able to run jshell* using the programmatic API (java tool) anymore.

>>> Yesterday, i took the time to track that issue and i believe i've found the root
>>> cause, trying to execute the java launcher using ProcessBuilder.start() with
>>> the jdk 13 sometimes fails with an i/o exception (errno 13) which is weird
>>> because you are trying to execute the same process that the one you are
>>> executing. Note that this is a spurious bug, I was not able to find the exact
>> > condition that triggers that bug.
>> > So sometime it works, sometime it doesn't.

>> Assuming you're running on Linux (given that the changeset only
>> applies to Linux), errno 13 is EACCES which would indicate a
>> filesystem permission issue. Are you sure you have permission to
>> execute `jspawnhelper` in your JVM installation? Could there be an
>> SELinux restriction in place?

>> Here's what the man page says:

>> ```

>> [EACCES] Search permission is denied for a component of
>> the path prefix.

>> [EACCES] The new process file is not an ordinary file.

>> [EACCES] The new process file mode denies execute permission.

>> [EACCES] The new process file is on a filesystem
>> mounted with execution

>> disabled (MNT_NOEXEC in <sys/mount.h>).
>> ```

>>> If i pass -Djdk.lang.Process.launchMechanism=fork (or vfork) when starting the
>>> VM, the bug disappear meaning that the bug occurs when the VM is trying to use
>>> posix_spawn, perhaps spawn is trying to do an optimization when you try to
>> > execute the same process as the one you are running under some conditions ?

>> The posix_spawn approach executes an intermediate support process
>> (`jspawnhelper`) which in turn executes the target process. I believe
>> there's an extensive discussion on the reasons for this in the
>> `core-libs-dev` archive.

>> --
>> - DML

From Alan.Bateman at oracle.com  Sun May 12 08:32:59 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 12 May 2019 09:32:59 +0100
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
 <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
 <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
Message-ID: <9832361d-c16f-8d56-0db9-59c706bc141a@oracle.com>

On 12/05/2019 09:23, forax at univ-mlv.fr wrote:
> Thanks Thomas,
> by the way, what is the purpose of jexec ?
>
jexec is legacy, should probably be removed [1].

It's good that the issue has been tracked down but I'm curious why it 
was initially intermittent. I would have expected it to fail every time. 
Also just to say that jlink goes out of its way to ensure that 
jspawnhelper has execute permission so I assume the issue is something 
copying a run-time image and not preserving permissions?

-Alan

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

From forax at univ-mlv.fr  Sun May 12 08:47:53 2019
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 12 May 2019 10:47:53 +0200 (CEST)
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <9832361d-c16f-8d56-0db9-59c706bc141a@oracle.com>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
 <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
 <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
 <9832361d-c16f-8d56-0db9-59c706bc141a@oracle.com>
Message-ID: <1269780327.1729317.1557650873039.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Remi Forax" <forax at univ-mlv.fr>
> Envoy?: Dimanche 12 Mai 2019 10:32:59
> Objet: Re: Process.exec with the linux posix_spawn mode has a bug

> On 12/05/2019 09:23, forax at univ-mlv.fr wrote:
>> Thanks Thomas,
>> by the way, what is the purpose of jexec ?
>>
> jexec is legacy, should probably be removed [1].
> 
> It's good that the issue has been tracked down but I'm curious why it
> was initially intermittent. I would have expected it to fail every time.
> Also just to say that jlink goes out of its way to ensure that
> jspawnhelper has execute permission so I assume the issue is something
> copying a run-time image and not preserving permissions?

Yes, it was intermittent because of the way the CI + my own installation script works, either the JDK was built (using jlink BTW) and it was Ok or the JDK files are cached [1] and reused but in that case the permission was not restored. 

> 
> -Alan
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8176066

R?mi

[1] https://www.appveyor.com/docs/build-cache/

From thomas.stuefe at gmail.com  Sun May 12 09:26:57 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 12 May 2019 11:26:57 +0200
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
 <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
 <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAA-vtUytfErR1LgjdazjKoCtFuBK0rT+eUNPiTwR3+MSFN7+Bw@mail.gmail.com>

I am happy this is resolved and the intermittent behavior explained. Yes,
we could improve exception messages, especially since analyzing fork
scenarios is cumbersome.

But as Alan wrote, this should not happen if the JFK is installed correctly.

Cheers, Thomas

On Sun, May 12, 2019, 10:23 AM <forax at univ-mlv.fr> wrote:

> Thanks Thomas,
> by the way, what is the purpose of jexec ?
>
> R?mi
>
> ------------------------------
>
> *De: *"Thomas St?fe" <thomas.stuefe at gmail.com>
> *?: *"David Lloyd" <david.lloyd at redhat.com>
> *Cc: *"Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <
> core-libs-dev at openjdk.java.net>
> *Envoy?: *Samedi 11 Mai 2019 20:49:02
> *Objet: *Re: Process.exec with the linux posix_spawn mode has a bug
>
> Hi Remi,
>
> David is right - a few more details:
> In both fork- and vfork-mode we fork/vfork the child process and in the
> child process then exec() the target binary (in this case "java" itself).
>
> In posix_spawn mode, for complicated reasons, we start, via posix_spawn(),
> the jspawnhelper - which, depending on the glibc involved, will either
> vfork() or clone() the child process and then exec() the jspawnhelper
> binary. Then, inside the jspawnhelper, we will exec() a second time, this
> time the target binary.
>
> (So, small correction, we do not have an intermediate _process_ here - at
> any time only two processes are involved, the parent and the child - but
> inside the child we call exec() twice.)
>
> If you get EACCESS only in posix_spawn() mode, the only difference to
> fork/vfork is that we exec() jspawnhelper. That is a binary located in the
> jdk and should have the correct permissions set.
>
> If you have a reproducible scenario, can you strace the call? (you would
> probably need "strace -f", and if you see in the output the jspawnhelper
> path with either _vfork or _clone system calls it worked).
>
> Cheers, Thomas
>
> On Sat, May 11, 2019 at 5:15 PM David Lloyd <david.lloyd at redhat.com>
> wrote:
>
>> On Sat, May 11, 2019 at 9:49 AM Remi Forax <forax at univ-mlv.fr> wrote:
>> >
>> > I've seen a weird error on my CI [1] since the 15th of February when
>> using the jdk 13,
>> > i was not able to run jshell* using the programmatic API (java tool)
>> anymore.
>> >
>> > Yesterday, i took the time to track that issue and i believe i've found
>> the root cause, trying to execute the java launcher using
>> ProcessBuilder.start() with the jdk 13 sometimes fails with an i/o
>> exception (errno 13) which is weird because you are trying to execute the
>> same process that the one you are executing. Note that this is a spurious
>> bug, I was not able to find the exact condition that triggers that bug.
>> > So sometime it works, sometime it doesn't.
>>
>> Assuming you're running on Linux (given that the changeset only
>> applies to Linux), errno 13 is EACCES which would indicate a
>> filesystem permission issue.  Are you sure you have permission to
>> execute `jspawnhelper` in your JVM installation?  Could there be an
>> SELinux restriction in place?
>>
>> Here's what the man page says:
>>
>> ```
>>
>>      [EACCES]           Search permission is denied for a component of
>> the path prefix.
>>
>>
>>      [EACCES]           The new process file is not an ordinary file.
>>
>>
>>      [EACCES]           The new process file mode denies execute
>> permission.
>>
>>
>>      [EACCES]           The new process file is on a filesystem
>> mounted with execution
>>
>>                         disabled (MNT_NOEXEC in <sys/mount.h>).
>> ```
>>
>> > If i pass -Djdk.lang.Process.launchMechanism=fork (or vfork) when
>> starting the VM, the bug disappear meaning that the bug occurs when the VM
>> is trying to use posix_spawn, perhaps spawn is trying to do an optimization
>> when you try to execute the same process as the one you are running under
>> some conditions ?
>>
>> The posix_spawn approach executes an intermediate support process
>> (`jspawnhelper`) which in turn executes the target process.  I believe
>> there's an extensive discussion on the reasons for this in the
>> `core-libs-dev` archive.
>>
>>
>> --
>> - DML
>>
>
>

From ramanand.patil at oracle.com  Mon May 13 07:10:25 2019
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 13 May 2019 00:10:25 -0700 (PDT)
Subject: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker
 incorrect for Peru
In-Reply-To: <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com>
References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default>
 <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com>
Message-ID: <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default>

Hi Deepak,
Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID.

Regards,
Ramanand.

-----Original Message-----
From: Naoto Sato 
Sent: Friday, May 10, 2019 6:12 PM
To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru

Hi Deepak, here are my comments.

- FormatData_es_PE.java: Modify the copyright year to 2019.

- Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format.

- Bug8206879.java does not have proper copyright header.

Naoto

On 5/10/19 4:25 AM, Deepak Kejriwal wrote:
> Hello,
> 
>   
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8206879
> 
>   
> 
> The proposed fix is located at:
> 
> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/
> 
>   
> 
> Summary
> 
> In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.).
> 
>   
> 
> Regard,
> 
> Deepak
> 
>   
> 

From christoph.langer at sap.com  Mon May 13 07:29:28 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 13 May 2019 07:29:28 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Daniel,

unfortunately, your proposed solution does not work with javac. I get this in the build:

...\mercurial\jdk\src\java.net.http\share\classes\jdk\internal\net\http\ExchangeImpl.java:103: error: method thenCompose in class CompletableFuture<T> cannot be applied to given types;
            return c2f.handle(factory).thenCompose(identity);
                                      ^
  required: Function<? super CompletableFuture<? extends ExchangeImpl<U#1>>,? extends CompletionStage<U#2>>
  found:    Function<CompletableFuture<? extends ExchangeImpl<U#1>>,CompletableFuture<? extends ExchangeImpl<U#1>>>
  reason: cannot infer type-variable(s) U#2
    (argument mismatch; Function<CompletableFuture<? extends ExchangeImpl<U#1>>,CompletableFuture<? extends ExchangeImpl<U#1>>> cannot be converted to Function<? super CompletableFuture<? extends ExchangeImpl<U#1>>,? extends CompletionStage<U#2>>)
  where U#1,U#2,T are type-variables:
    U#1 extends Object declared in method <U#1>get(Exchange<U#1>,HttpConnection)
    U#2 extends Object declared in method <U#2>thenCompose(Function<? super T,? extends CompletionStage<U#2>>)
    T extends Object declared in class CompletableFuture
1 error

So I think we need to go back to my initial proposal which works for both, IDE and javac: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/ 

Thanks
Christoph


> -----Original Message-----
> From: Langer, Christoph
> Sent: Freitag, 10. Mai 2019 11:17
> To: Daniel Fuchs <daniel.fuchs at oracle.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> Cc: compiler-dev at openjdk.java.net
> Subject: RE: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
> 
> Hi Daniel,
> 
> I fully agree, @SuppressWarnings should be avoided wherever possible.
> 
> So, thanks for coming up with this alternative suggestion. It works and so I
> updated my webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8223553.1/
> 
> Any reviews for the other 3 files?
> 
> Thanks
> Christoph
> 
> > -----Original Message-----
> > From: Daniel Fuchs <daniel.fuchs at oracle.com>
> > Sent: Donnerstag, 9. Mai 2019 17:24
> > To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-
> libs-
> > dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> > Cc: compiler-dev at openjdk.java.net
> > Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> > Eclipse Java Compiler
> >
> > Hi Christoph,
> >
> > I'm only commenting on the HttpClient changes, I'll let
> > others comment on the other changes...
> >
> >
> http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/s
> > hare/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html
> >
> > I have a profound dislike for using @SuppressedWarnings, unless
> > it's the only alternative. My preference would be to introduce
> > local variables, if that can make the compiler happy, until such time
> > where the issue is actually resolved...
> >
> > For instance, it seems that the following would work:
> >
> >      // Use local variable assignments to keep other java compilers
> >      // happy and avoid unchecked casts warnings
> >      BiFunction<Http2Connection, Throwable, CompletableFuture<? extends
> > ExchangeImpl<U>>>
> >          factory = (h2c, t) -> createExchangeImpl(h2c, t, exchange,
> > connection);
> >      Function<CompletableFuture<? extends ExchangeImpl<U>>,
> > CompletableFuture<? extends ExchangeImpl<U>>>
> >          identity = (cf) -> cf;
> >      return c2f.handle(factory).thenCompose(identity);
> >
> >
> > best regards,
> >
> > -- daniel
> >
> > On 08/05/2019 09:02, Langer, Christoph wrote:
> > > Hi,
> > >
> > > please review a small change that I'd like to see in OpenJDK to get rid
> > > of compilation errors in the Eclipse IDE.
> > >
> > > It seems the root cause for the compilation errors is that javac would
> > > sometimes widen capture variables and is hence able to compile the
> > > places that I touch here. The EC4J compiler claims that it's following
> > > the spec more strictly and bails out at these places. I had posted about
> > > this on compiler-dev but got no reaction [0].
> > >
> > > So, as this seems to be some field of open work for the compiler/spec
> > > folks, I'd like to get EC4J quiesced by introducing some slight
> > > modifications to the original places which makes the code appeal a bit
> > > less elegant and fluent but will get rid of the compile errors.
> > >
> > > Please review:
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223553
> > >
> > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/
> > >
> > > The modification to
> > >
> >
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav
> > a
> > > belongs to JSR-166, so I don't know if it needs some special handling.
> > >
> > > Thanks & Best regards
> > >
> > > Christoph
> > >
> > > [0]
> > > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-
> > March/013054.html
> > >


From daniel.fuchs at oracle.com  Mon May 13 09:34:02 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 13 May 2019 10:34:02 +0100
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>

Hi Christoph,

On 13/05/2019 08:29, Langer, Christoph wrote:
> Hi Daniel,
> 
> unfortunately, your proposed solution does not work with javac. I get this in the build:

Oh darn. I should have double checked.
Can we at least reduce the scope of the @SuppressedWarnings by
introducing a private method that just has the return call?

best regards,

-- daniel


> 
> ...\mercurial\jdk\src\java.net.http\share\classes\jdk\internal\net\http\ExchangeImpl.java:103: error: method thenCompose in class CompletableFuture<T> cannot be applied to given types;
>              return c2f.handle(factory).thenCompose(identity);
>                                        ^
>    required: Function<? super CompletableFuture<? extends ExchangeImpl<U#1>>,? extends CompletionStage<U#2>>
>    found:    Function<CompletableFuture<? extends ExchangeImpl<U#1>>,CompletableFuture<? extends ExchangeImpl<U#1>>>
>    reason: cannot infer type-variable(s) U#2
>      (argument mismatch; Function<CompletableFuture<? extends ExchangeImpl<U#1>>,CompletableFuture<? extends ExchangeImpl<U#1>>> cannot be converted to Function<? super CompletableFuture<? extends ExchangeImpl<U#1>>,? extends CompletionStage<U#2>>)
>    where U#1,U#2,T are type-variables:
>      U#1 extends Object declared in method <U#1>get(Exchange<U#1>,HttpConnection)
>      U#2 extends Object declared in method <U#2>thenCompose(Function<? super T,? extends CompletionStage<U#2>>)
>      T extends Object declared in class CompletableFuture
> 1 error
> 
> So I think we need to go back to my initial proposal which works for both, IDE and javac:http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/  
> 
> Thanks
> Christoph


From martinrb at google.com  Mon May 13 12:08:12 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 13 May 2019 05:08:12 -0700
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <CAA-vtUytfErR1LgjdazjKoCtFuBK0rT+eUNPiTwR3+MSFN7+Bw@mail.gmail.com>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
 <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
 <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
 <CAA-vtUytfErR1LgjdazjKoCtFuBK0rT+eUNPiTwR3+MSFN7+Bw@mail.gmail.com>
Message-ID: <CA+kOe0_Eb+RzF4ASf1ZaOruoyxYURP+xOt23zTKGhDHfsABDWg@mail.gmail.com>

I am happy this is resolved and the intermittent behavior explained. Yes,
> we could improve exception messages, especially since analyzing fork
> scenarios is cumbersome.
>

I tried hard back in 2005 to provide pretty good java-level diagnostics
when subprocess starting failed somehow (see WhyCantJohnnyExec) .  At least
the errno did get reported.

I've had this little script around for ages:

#!/bin/bash
# -v: Print unabbreviated versions of environment, etc

exec /usr/bin/strace -f -v -s 256 -e signal=none -e trace=process "$@"

From christoph.langer at sap.com  Mon May 13 12:14:33 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 13 May 2019 12:14:33 +0000
Subject: RFR(S): 8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException:
 CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)
Message-ID: <AM6PR02MB5192F6781E65000CF47F62BF8A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

please review this fix of a regression in zipfs after JDK-8222532 [0].

Bug: https://bugs.openjdk.java.net/browse/JDK-8223597
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223597.0/

The issue occurs when an empty file/channel is persisted into a zip file. The entry had already been compressed with CRC of 0 at the time the output stream to the zipfs was closed. But when the Entry is eventually synced to the zip file, this is not detected and the bytes get compressed again.

The test was adapted to reliably provoke this intermittent error. In the test I also suppressed printout of an expected Exception to avoid some distraction when reading its JTR files.

Thanks
Christoph

[0] https://bugs.openjdk.java.net/browse/JDK-8222532


From thomas.stuefe at gmail.com  Mon May 13 13:42:24 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 13 May 2019 15:42:24 +0200
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <CA+kOe0_Eb+RzF4ASf1ZaOruoyxYURP+xOt23zTKGhDHfsABDWg@mail.gmail.com>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
 <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
 <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
 <CAA-vtUytfErR1LgjdazjKoCtFuBK0rT+eUNPiTwR3+MSFN7+Bw@mail.gmail.com>
 <CA+kOe0_Eb+RzF4ASf1ZaOruoyxYURP+xOt23zTKGhDHfsABDWg@mail.gmail.com>
Message-ID: <CAA-vtUxBhKV9m1MZ2hywXZtX5-oAKbTXMJunaywFT1W8Q0spEg@mail.gmail.com>

Hi Martin,

On Mon, May 13, 2019 at 2:08 PM Martin Buchholz <martinrb at google.com> wrote:

>
>
> I am happy this is resolved and the intermittent behavior explained. Yes,
>> we could improve exception messages, especially since analyzing fork
>> scenarios is cumbersome.
>>
>
> I tried hard back in 2005 to provide pretty good java-level diagnostics
> when subprocess starting failed somehow (see WhyCantJohnnyExec) .  At least
> the errno did get reported.
>
>
I know your code. For many years I wondered who Johnny is :)

We have a very similar solution in our port: we have our own error codes
(plus errno mixed in where it makes sense) for the many things that can go
wrong in the forkhelper. Maybe we can improve upon your solution a bit.
And/or add tracing for environment etc.

But here is one thing that I still do not understand with Remis problem:

The theory is that the first exec(), starting jspawnhelper, went wrong with
NOACCESS, yes?

Man page for posix_spawn() states:

<quote>
       Upon successful completion, posix_spawn() and posix_spawnp() place
       the PID of the child process in pid, and return 0.  If there is an
       error before or during the fork(2), then no child is created, the
       contents of *pid are unspecified, and these functions return an error
       number as described below.

       Even when these functions return a success status, the child process
       may still fail for a plethora of reasons related to its pre-exec()
       initialization.  In addition, the exec(3) may fail.  In all of these
       cases, the child process will exit with the exit value of 127.
</quote>

To me this looks as if what should have happened is: posix_spawn() should
have returned with success, since the fork() went thru. Then, the child
process (still inside posix_spawn()) attempts exec and gets a NOACCESS.
Then, child process should have ended with exit code 127. Your fail pipe
would never read an error code since we never entered the main function of
jspawnhelper. For the java caller it should have looked like a very short
lived process with exit code 127.

Obviously this is not what happened, since Remi reported an IOException
with an errno. So, where do I understand this wong?


I've had this little script around for ages:
>
> #!/bin/bash
> # -v: Print unabbreviated versions of environment, etc
>
> exec /usr/bin/strace -f -v -s 256 -e signal=none -e trace=process "$@"
>
>
We had all this as part of spawn traces. But this is a nice and neat idea.
Does it print current directory?

Cheers, Thomas

From martinrb at google.com  Mon May 13 14:08:25 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 13 May 2019 07:08:25 -0700
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <CAA-vtUxBhKV9m1MZ2hywXZtX5-oAKbTXMJunaywFT1W8Q0spEg@mail.gmail.com>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
 <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
 <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
 <CAA-vtUytfErR1LgjdazjKoCtFuBK0rT+eUNPiTwR3+MSFN7+Bw@mail.gmail.com>
 <CA+kOe0_Eb+RzF4ASf1ZaOruoyxYURP+xOt23zTKGhDHfsABDWg@mail.gmail.com>
 <CAA-vtUxBhKV9m1MZ2hywXZtX5-oAKbTXMJunaywFT1W8Q0spEg@mail.gmail.com>
Message-ID: <CA+kOe09SUbDk6cmR9+6qSAA=BstnoGz7oxNk3TQw4AwA4LSuTQ@mail.gmail.com>

>
>
>> I tried hard back in 2005 to provide pretty good java-level diagnostics
>> when subprocess starting failed somehow (see WhyCantJohnnyExec) .  At least
>> the errno did get reported.
>>
>>
> I know your code. For many years I wondered who Johnny is :)
>

https://en.wikipedia.org/wiki/Rudolf_Flesch

I should have spelled that WhyJohnnyCantExec

From thomas.stuefe at gmail.com  Mon May 13 14:09:49 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 13 May 2019 16:09:49 +0200
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <CA+kOe09SUbDk6cmR9+6qSAA=BstnoGz7oxNk3TQw4AwA4LSuTQ@mail.gmail.com>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
 <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
 <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
 <CAA-vtUytfErR1LgjdazjKoCtFuBK0rT+eUNPiTwR3+MSFN7+Bw@mail.gmail.com>
 <CA+kOe0_Eb+RzF4ASf1ZaOruoyxYURP+xOt23zTKGhDHfsABDWg@mail.gmail.com>
 <CAA-vtUxBhKV9m1MZ2hywXZtX5-oAKbTXMJunaywFT1W8Q0spEg@mail.gmail.com>
 <CA+kOe09SUbDk6cmR9+6qSAA=BstnoGz7oxNk3TQw4AwA4LSuTQ@mail.gmail.com>
Message-ID: <CAA-vtUx3wJjae3uHQsb+guMBoTGprisCpbzzUNyHEr0VZH3hBg@mail.gmail.com>

On Mon, May 13, 2019 at 4:08 PM Martin Buchholz <martinrb at google.com> wrote:

>
>>> I tried hard back in 2005 to provide pretty good java-level diagnostics
>>> when subprocess starting failed somehow (see WhyCantJohnnyExec) .  At least
>>> the errno did get reported.
>>>
>>>
>> I know your code. For many years I wondered who Johnny is :)
>>
>
> https://en.wikipedia.org/wiki/Rudolf_Flesch
>
> I should have spelled that WhyJohnnyCantExec
>
>
Mystery finally solved. Thanks!

From thomas.stuefe at gmail.com  Mon May 13 14:11:52 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 13 May 2019 16:11:52 +0200
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <CAA-vtUxBhKV9m1MZ2hywXZtX5-oAKbTXMJunaywFT1W8Q0spEg@mail.gmail.com>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
 <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
 <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
 <CAA-vtUytfErR1LgjdazjKoCtFuBK0rT+eUNPiTwR3+MSFN7+Bw@mail.gmail.com>
 <CA+kOe0_Eb+RzF4ASf1ZaOruoyxYURP+xOt23zTKGhDHfsABDWg@mail.gmail.com>
 <CAA-vtUxBhKV9m1MZ2hywXZtX5-oAKbTXMJunaywFT1W8Q0spEg@mail.gmail.com>
Message-ID: <CAA-vtUxfcRYoNmyqwOmK6R7T66Dj7xPzRufRag_173M5JdMbJw@mail.gmail.com>

On Mon, May 13, 2019 at 3:42 PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

>
> Hi Martin,
>
> On Mon, May 13, 2019 at 2:08 PM Martin Buchholz <martinrb at google.com>
> wrote:
>
>>
>>
>> I am happy this is resolved and the intermittent behavior explained. Yes,
>>> we could improve exception messages, especially since analyzing fork
>>> scenarios is cumbersome.
>>>
>>
>> I tried hard back in 2005 to provide pretty good java-level diagnostics
>> when subprocess starting failed somehow (see WhyCantJohnnyExec) .  At least
>> the errno did get reported.
>>
>>
> I know your code. For many years I wondered who Johnny is :)
>
> We have a very similar solution in our port: we have our own error codes
> (plus errno mixed in where it makes sense) for the many things that can go
> wrong in the forkhelper. Maybe we can improve upon your solution a bit.
> And/or add tracing for environment etc.
>
> But here is one thing that I still do not understand with Remis problem:
>
> The theory is that the first exec(), starting jspawnhelper, went wrong
> with NOACCESS, yes?
>
> Man page for posix_spawn() states:
>
> <quote>
>        Upon successful completion, posix_spawn() and posix_spawnp() place
>        the PID of the child process in pid, and return 0.  If there is an
>        error before or during the fork(2), then no child is created, the
>        contents of *pid are unspecified, and these functions return an
> error
>        number as described below.
>
>        Even when these functions return a success status, the child process
>        may still fail for a plethora of reasons related to its pre-exec()
>        initialization.  In addition, the exec(3) may fail.  In all of these
>        cases, the child process will exit with the exit value of 127.
> </quote>
>
> To me this looks as if what should have happened is: posix_spawn() should
> have returned with success, since the fork() went thru. Then, the child
> process (still inside posix_spawn()) attempts exec and gets a NOACCESS.
> Then, child process should have ended with exit code 127. Your fail pipe
> would never read an error code since we never entered the main function of
> jspawnhelper. For the java caller it should have looked like a very short
> lived process with exit code 127.
>
> Obviously this is not what happened, since Remi reported an IOException
> with an errno. So, where do I understand this wong?
>
>
Hmm this looks wrong. Just tested (Ubuntu 16.4): removing execute
permission from jspawnhelper does not result in an IOException. Instead,
Runtime.exec() seemingly succeeds. strace shows the exec() for jspawnhelper
to fail as expected:

5676 [pid 13796]
execve("/shared/projects/openjdk/jdk-jdk/output-fastdebug/images/jdk/lib/jspawnhelper",
["11:14"], [/* 79 vars */]) = -1 EACCES (Permission denied)
5677 [pid 13796] exit_group(127)             = ?
5678 [pid 13780] <... vfork resumed> )       = 13796
5679 [pid 13796] +++ exited with 127 +++
5680 [pid 13780] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED,
si_pid=13796, si_uid=1027, si_status=127, si_utime=0, si_stime=0} ---

But we completely fail to notice.

This is bad. We should fix it.

One more thing, not sure if this is libc specific? The OpenGroup manpage
for posix_spawn() states:

<quote>
If *posix_spawn*() or *posix_spawnp*() fail for any of the reasons that
would cause *fork*()
<http://pubs.opengroup.org/onlinepubs/007904875/functions/fork.html> or one
of the *exec
<http://pubs.opengroup.org/onlinepubs/007904875/functions/exec.html>* family
of functions to fail, an error value shall be returned as described by
*fork*()
<http://pubs.opengroup.org/onlinepubs/007904875/functions/fork.html> and *exec
<http://pubs.opengroup.org/onlinepubs/007904875/functions/exec.html>*,
respectively (or, if the error occurs after the calling process
successfully returns, the child process shall exit with exit status 127).
</quote>

which I interpret as the standard leaves open the decision if exec() errors
are communicated outside to the caller of posix_spawn().

..Thomas


> I've had this little script around for ages:
>>
>> #!/bin/bash
>> # -v: Print unabbreviated versions of environment, etc
>>
>> exec /usr/bin/strace -f -v -s 256 -e signal=none -e trace=process "$@"
>>
>>
> We had all this as part of spawn traces. But this is a nice and neat idea.
> Does it print current directory?
>
> Cheers, Thomas
>
>

From thomas.stuefe at gmail.com  Mon May 13 14:22:23 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 13 May 2019 16:22:23 +0200
Subject: Process.exec with the linux posix_spawn mode has a bug
In-Reply-To: <CAA-vtUxfcRYoNmyqwOmK6R7T66Dj7xPzRufRag_173M5JdMbJw@mail.gmail.com>
References: <904002001.1648926.1557586094935.JavaMail.zimbra@u-pem.fr>
 <CANghgrS-mTssGi9vKc+zj5_T1+AZ3S-WVWUiK7OM0qC-rJ7g-w@mail.gmail.com>
 <CAA-vtUy5dYDq51L+BE0oHo4C8zCWfDagFKkqoFf0a65PJxG6Pw@mail.gmail.com>
 <1765727699.1727772.1557649434953.JavaMail.zimbra@u-pem.fr>
 <CAA-vtUytfErR1LgjdazjKoCtFuBK0rT+eUNPiTwR3+MSFN7+Bw@mail.gmail.com>
 <CA+kOe0_Eb+RzF4ASf1ZaOruoyxYURP+xOt23zTKGhDHfsABDWg@mail.gmail.com>
 <CAA-vtUxBhKV9m1MZ2hywXZtX5-oAKbTXMJunaywFT1W8Q0spEg@mail.gmail.com>
 <CAA-vtUxfcRYoNmyqwOmK6R7T66Dj7xPzRufRag_173M5JdMbJw@mail.gmail.com>
Message-ID: <CAA-vtUyGLpPaOLYWR9wCUMaSxyt=CzGgD+xDcQQkUN7iVFBrjA@mail.gmail.com>

On Mon, May 13, 2019 at 4:11 PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

>
>
> On Mon, May 13, 2019 at 3:42 PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>>
>> Hi Martin,
>>
>> On Mon, May 13, 2019 at 2:08 PM Martin Buchholz <martinrb at google.com>
>> wrote:
>>
>>>
>>>
>>> I am happy this is resolved and the intermittent behavior explained. Yes,
>>>> we could improve exception messages, especially since analyzing fork
>>>> scenarios is cumbersome.
>>>>
>>>
>>> I tried hard back in 2005 to provide pretty good java-level diagnostics
>>> when subprocess starting failed somehow (see WhyCantJohnnyExec) .  At least
>>> the errno did get reported.
>>>
>>>
>> I know your code. For many years I wondered who Johnny is :)
>>
>> We have a very similar solution in our port: we have our own error codes
>> (plus errno mixed in where it makes sense) for the many things that can go
>> wrong in the forkhelper. Maybe we can improve upon your solution a bit.
>> And/or add tracing for environment etc.
>>
>> But here is one thing that I still do not understand with Remis problem:
>>
>> The theory is that the first exec(), starting jspawnhelper, went wrong
>> with NOACCESS, yes?
>>
>> Man page for posix_spawn() states:
>>
>> <quote>
>>        Upon successful completion, posix_spawn() and posix_spawnp() place
>>        the PID of the child process in pid, and return 0.  If there is an
>>        error before or during the fork(2), then no child is created, the
>>        contents of *pid are unspecified, and these functions return an
>> error
>>        number as described below.
>>
>>        Even when these functions return a success status, the child
>> process
>>        may still fail for a plethora of reasons related to its pre-exec()
>>        initialization.  In addition, the exec(3) may fail.  In all of
>> these
>>        cases, the child process will exit with the exit value of 127.
>> </quote>
>>
>> To me this looks as if what should have happened is: posix_spawn() should
>> have returned with success, since the fork() went thru. Then, the child
>> process (still inside posix_spawn()) attempts exec and gets a NOACCESS.
>> Then, child process should have ended with exit code 127. Your fail pipe
>> would never read an error code since we never entered the main function of
>> jspawnhelper. For the java caller it should have looked like a very short
>> lived process with exit code 127.
>>
>> Obviously this is not what happened, since Remi reported an IOException
>> with an errno. So, where do I understand this wong?
>>
>>
> Hmm this looks wrong. Just tested (Ubuntu 16.4): removing execute
> permission from jspawnhelper does not result in an IOException. Instead,
> Runtime.exec() seemingly succeeds. strace shows the exec() for jspawnhelper
> to fail as expected:
>
> 5676 [pid 13796]
> execve("/shared/projects/openjdk/jdk-jdk/output-fastdebug/images/jdk/lib/jspawnhelper",
> ["11:14"], [/* 79 vars */]) = -1 EACCES (Permission denied)
> 5677 [pid 13796] exit_group(127)             = ?
> 5678 [pid 13780] <... vfork resumed> )       = 13796
> 5679 [pid 13796] +++ exited with 127 +++
> 5680 [pid 13780] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED,
> si_pid=13796, si_uid=1027, si_status=127, si_utime=0, si_stime=0} ---
>
> But we completely fail to notice.
>
> This is bad. We should fix it.
>
> One more thing, not sure if this is libc specific? The OpenGroup manpage
> for posix_spawn() states:
>
> <quote>
> If *posix_spawn*() or *posix_spawnp*() fail for any of the reasons that
> would cause *fork*()
> <http://pubs.opengroup.org/onlinepubs/007904875/functions/fork.html> or
> one of the *exec
> <http://pubs.opengroup.org/onlinepubs/007904875/functions/exec.html>* family
> of functions to fail, an error value shall be returned as described by
> *fork*()
> <http://pubs.opengroup.org/onlinepubs/007904875/functions/fork.html> and *exec
> <http://pubs.opengroup.org/onlinepubs/007904875/functions/exec.html>*,
> respectively (or, if the error occurs after the calling process
> successfully returns, the child process shall exit with exit status 127).
> </quote>
>
> which I interpret as the standard leaves open the decision if exec()
> errors are communicated outside to the caller of posix_spawn().
>
> ..Thomas
>
>
.. opened https://bugs.openjdk.java.net/browse/JDK-8223777 to track this.


>
>> I've had this little script around for ages:
>>>
>>> #!/bin/bash
>>> # -v: Print unabbreviated versions of environment, etc
>>>
>>> exec /usr/bin/strace -f -v -s 256 -e signal=none -e trace=process "$@"
>>>
>>>
>> We had all this as part of spawn traces. But this is a nice and neat
>> idea. Does it print current directory?
>>
>> Cheers, Thomas
>>
>>
>

From pavel.rappo at oracle.com  Mon May 13 14:44:14 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 13 May 2019 15:44:14 +0100
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
Message-ID: <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>

Thanks for updating your patch. The updated code seems fine.

-Pavel

> On 11 May 2019, at 05:01, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> Hello!
> 
> Please help review the updated fix.
> 
> This new webrev includes changes suggested by Pavel, Peter and Roger.
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
> 
> Please note that the behavior of j.n.f.Files.readAllBytes() has changed slightly, so now it *may* be possible to read a file larger than (Integer.MAX_VALUE - 8), if VM is able to allocate that large array.
> 
> With kind regards,
> Ivan
> 
> On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
>> Hello!
>> 
>> Jdk has several places with similar logic:  an array needs to be reallocated (by at least some defined amount), taking into account the maximum allowed size of arrays.
>> 
>> There's clearly an opportunity for refactoring, so it is proposed to introduce a dedicated utility method for calculating the best new size of an array.
>> 
>> Would you please help review this enhancement?
>> 
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>> 
>> Mach5 job ran fine.
>> 
>> Thanks in advance!
>> 
> 
> -- 
> With kind regards,
> Ivan Gerasimov
> 


From claes.redestad at oracle.com  Mon May 13 14:59:24 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 13 May 2019 16:59:24 +0200
Subject: RFR(S): 8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException:
 CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)
In-Reply-To: <AM6PR02MB5192F6781E65000CF47F62BF8A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192F6781E65000CF47F62BF8A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <db9a8f14-dd2b-50cd-e66d-5e65755ad47e@oracle.com>

Changes and new tests looks good,

will csize always be > 0 for an empty file/channel?

/Claes

On 2019-05-13 14:14, Langer, Christoph wrote:
> Hi,
> 
> please review this fix of a regression in zipfs after JDK-8222532 [0].
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223597
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223597.0/
> 
> The issue occurs when an empty file/channel is persisted into a zip file. The entry had already been compressed with CRC of 0 at the time the output stream to the zipfs was closed. But when the Entry is eventually synced to the zip file, this is not detected and the bytes get compressed again.
> 
> The test was adapted to reliably provoke this intermittent error. In the test I also suppressed printout of an expected Exception to avoid some distraction when reading its JTR files.
> 
> Thanks
> Christoph
> 
> [0] https://bugs.openjdk.java.net/browse/JDK-8222532
> 

From thomas.stuefe at gmail.com  Mon May 13 16:00:35 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 13 May 2019 18:00:35 +0200
Subject: RFR(s): 8223777: In posix_spawn mode, failing to exec() jspawnhelper
 does not result in an error
Message-ID: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>

Hi all,

may I have please your opinions about the following change:

Bug: https://bugs.openjdk.java.net/browse/JDK-8223777
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error/webrev.00/webrev/

In short, since some weeks posix_spawn() is used on Linux to spawn childs.
But the glibc implementation of posix_spawn does not report errors back to
the caller if exec()ing the target binary fails.

We only ever exec the jspawnhelper, which is part of the JDK and which then
exec()s the real target binary. The second exec() is under our control and
Martin did provide proper error reporting.

However, the first exec(), performed inside posix_spawn(), may fail too.
Most posix_spawn implementations will tell us if that happens, not glibc
(it is cumbersome to implement, one needs a pipe and somesuch, and POSIX
leaves a bit of headroom for the implementor to cheap out, so they did.)

So, if someone messes with the JDK installation and e.g. removes the
execute bits from jspawnhelper, that first exec() fails, but we get no
error. From the outside it looks like Runtime.exec() succeeded.

This is impossible to fix completely - see Martin's comment about the
impossibility to foresee whether an exec() will succeed without actually
exec()ing. But at least we can test the execute permissions on the
jspawnhelper. Which this fix does. This fixes Ubuntu 16.4 (Now, I get an
IOException if jspawnhelper is not executable).

Since I like to be super careful with runtime.exec coding, I will run this
through our nightlies and also would like feedback from the core libs
people. Also, I am not sure about the runtime costs of this hack. Seems a
bit excessive for something which is just a setup error (a correctly
installed JDK should never have this problem).

As a side note, it may help if jspawnhelper would live in the bin folder of
the JDK (currently lives in lib), because everyone should be aware that
programs in bin need execute permissions...

Cheers, Thomas

From adinn at redhat.com  Mon May 13 16:14:36 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 13 May 2019 17:14:36 +0100
Subject: RFR : 8221696: MappedByteBuffer.force method to specify range
In-Reply-To: <4cda30a8-7d86-de1a-2ff9-ae1904563ead@redhat.com>
References: <2c9099f0-d95d-425a-c033-b22ad5c25231@redhat.com>
 <4ad97801-218f-2fa5-e8b5-3f14347c4320@oracle.com>
 <9218d37f-9820-9216-b125-8f3bc2d19e3d@redhat.com>
 <453045f6-0259-e098-8211-0187428adb9f@oracle.com>
 <b6e8c4cd-fa7a-74ae-4881-744883073bbe@redhat.com>
 <40cb2223-6d5a-4262-6293-2f187f578735@redhat.com>
 <4cda30a8-7d86-de1a-2ff9-ae1904563ead@redhat.com>
Message-ID: <199698dd-a486-61f4-62c6-d99930e164d8@redhat.com>

Thank you for looking at the patch.

On 28/04/2019 18:09, Andrew Haley wrote:
> On 4/25/19 5:34 PM, Andrew Dinn wrote:
>>    long map_base = (address & ~(ps - 1));
> 
> This looks like a hard way to write
> 
>    long map_base = address & -ps;

My version certainly uses more characters, that is for sure. However, I 
chose (and still prefer) this form for /clarity/. It seems to me to 
communicate as simply as possible what mask is being constructed, 
granted the starting premise that ps is a power of 2 (i.e. has only a 
single bit set).

It only requires elementary knowledge of binary representations to see:

   firstly, that ps-1 clears the original bit and sets all lower bits;

   next that ~(ps-1) clears those lower bits and sets all bits from the 
original (inclusive) upwards;

   then that the result can be used as a mask to clear those same bottom 
bits from address;

   finally that this mask operation is equivalent to rounding down to 
the relevant power of two.

I find your alternative (a tad) less clear because it employs an 
arithmetic operation to achieve the requisite bitwise transformation. 
That the two expressions compute to equivalent results requires some 
experience and understanding of the twos-complement representations of 
numbers rather than basic knowledge of bit fields.

As a gcc hacker 'your mileage may vary' ;-)

Crucially, every compiler we rely on is going to produce the same code 
in both cases.

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 mikael.vidstedt at oracle.com  Mon May 13 16:41:29 2019
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 13 May 2019 09:41:29 -0700
Subject: RFR : 8221696: MappedByteBuffer.force method to specify range
In-Reply-To: <199698dd-a486-61f4-62c6-d99930e164d8@redhat.com>
References: <2c9099f0-d95d-425a-c033-b22ad5c25231@redhat.com>
 <4ad97801-218f-2fa5-e8b5-3f14347c4320@oracle.com>
 <9218d37f-9820-9216-b125-8f3bc2d19e3d@redhat.com>
 <453045f6-0259-e098-8211-0187428adb9f@oracle.com>
 <b6e8c4cd-fa7a-74ae-4881-744883073bbe@redhat.com>
 <40cb2223-6d5a-4262-6293-2f187f578735@redhat.com>
 <4cda30a8-7d86-de1a-2ff9-ae1904563ead@redhat.com>
 <199698dd-a486-61f4-62c6-d99930e164d8@redhat.com>
Message-ID: <DABFA78D-B493-45DB-9EF9-FFFA06523BC6@oracle.com>


Would it be worth putting the logic in an aptly named (private) method? Something like:

...
private long alignDown(long address, long alignment) {
   return address & <whatever>;
}
...
long mapBase = alignDown(address, ps);
?


Cheers,
Mikael

> On May 13, 2019, at 9:14 AM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> Thank you for looking at the patch.
> 
> On 28/04/2019 18:09, Andrew Haley wrote:
>> On 4/25/19 5:34 PM, Andrew Dinn wrote:
>>>   long map_base = (address & ~(ps - 1));
>> This looks like a hard way to write
>>   long map_base = address & -ps;
> 
> My version certainly uses more characters, that is for sure. However, I chose (and still prefer) this form for /clarity/. It seems to me to communicate as simply as possible what mask is being constructed, granted the starting premise that ps is a power of 2 (i.e. has only a single bit set).
> 
> It only requires elementary knowledge of binary representations to see:
> 
>  firstly, that ps-1 clears the original bit and sets all lower bits;
> 
>  next that ~(ps-1) clears those lower bits and sets all bits from the original (inclusive) upwards;
> 
>  then that the result can be used as a mask to clear those same bottom bits from address;
> 
>  finally that this mask operation is equivalent to rounding down to the relevant power of two.
> 
> I find your alternative (a tad) less clear because it employs an arithmetic operation to achieve the requisite bitwise transformation. That the two expressions compute to equivalent results requires some experience and understanding of the twos-complement representations of numbers rather than basic knowledge of bit fields.
> 
> As a gcc hacker 'your mileage may vary' ;-)
> 
> Crucially, every compiler we rely on is going to produce the same code in both cases.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


From lance.andersen at oracle.com  Mon May 13 16:59:44 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 13 May 2019 12:59:44 -0400
Subject: RFR(S): 8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException:
 CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)
In-Reply-To: <AM6PR02MB5192F6781E65000CF47F62BF8A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192F6781E65000CF47F62BF8A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <9F5FD56C-314E-40D5-B31F-361F56C59E72@oracle.com>

Hi Christoph,

The change seems reasonable.

> On May 13, 2019, at 8:14 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi,
>  
> please review this fix of a regression in zipfs after JDK-8222532 [0].
>  
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223597 <https://bugs.openjdk.java.net/browse/JDK-8223597>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223597.0/ <http://cr.openjdk.java.net/~clanger/webrevs/8223597.0/>
>  
> The issue occurs when an empty file/channel is persisted into a zip file. The entry had already been compressed with CRC of 0 at the time the output stream to the zipfs was closed. But when the Entry is eventually synced to the zip file, this is not detected and the bytes get compressed again.
>  
> The test was adapted to reliably provoke this intermittent error. In the test I also suppressed printout of an expected Exception to avoid some distraction when reading its JTR files.
>  
> Thanks
> Christoph
>  
> [0] https://bugs.openjdk.java.net/browse/JDK-8222532 <https://bugs.openjdk.java.net/browse/JDK-8222532>
 <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 Roger.Riggs at oracle.com  Mon May 13 18:43:48 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 13 May 2019 14:43:48 -0400
Subject: RFR(s): 8223777: In posix_spawn mode, failing to exec()
 jspawnhelper does not result in an error
In-Reply-To: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
Message-ID: <4c317664-05c6-a150-45f0-bc1a2f36aed4@oracle.com>

Hi Thomas,

Some thoughts...

Did you determine exactly how the failure of exec did not result in an 
IOException?
The change at 696 just prevents an exception from getting overwritten but
not one that is not thrown or was cleared.

An improved test for a successful spawnChild could be added to 
initialize resultPid to -1
and check that it has been overwritten with the pid.? If posix_spawn 
returned success,
there would still be an indication that the process was or was not created.

Can the function be named to indicate what is it checking?? For example, 
isHelperExecutable?
It returns a boolean and it would be more conventional to stick to the C 
interpretation
of 0 == true, anything else is not.
Requiring all three exec bits may be overkill and does not match the 
actual access test.
It might be confusing if the permissions were set so Linux could exec 
it, but the Java runtime
threw an exception because it had a stricter requirement (not documented).

Since this is in the normal path and will very rarely fail, it is 
reasonable to ask
about any potential performance impact.? Can the test for exec and more 
specific message
be used only if the exec fails.

The exception includes the literal "jspawnhelper" which would be 
misleading if it were
changed and it might be clearer to mention 'exec' permission in the message.

Thanks, Roger



On 05/13/2019 12:00 PM, Thomas St?fe wrote:
> Hi all,
>
> may I have please your opinions about the following change:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223777
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error/webrev.00/webrev/
>
> In short, since some weeks posix_spawn() is used on Linux to spawn childs.
> But the glibc implementation of posix_spawn does not report errors back to
> the caller if exec()ing the target binary fails.
>
> We only ever exec the jspawnhelper, which is part of the JDK and which then
> exec()s the real target binary. The second exec() is under our control and
> Martin did provide proper error reporting.
>
> However, the first exec(), performed inside posix_spawn(), may fail too.
> Most posix_spawn implementations will tell us if that happens, not glibc
> (it is cumbersome to implement, one needs a pipe and somesuch, and POSIX
> leaves a bit of headroom for the implementor to cheap out, so they did.)
>
> So, if someone messes with the JDK installation and e.g. removes the
> execute bits from jspawnhelper, that first exec() fails, but we get no
> error. From the outside it looks like Runtime.exec() succeeded.
>
> This is impossible to fix completely - see Martin's comment about the
> impossibility to foresee whether an exec() will succeed without actually
> exec()ing. But at least we can test the execute permissions on the
> jspawnhelper. Which this fix does. This fixes Ubuntu 16.4 (Now, I get an
> IOException if jspawnhelper is not executable).
>
> Since I like to be super careful with runtime.exec coding, I will run this
> through our nightlies and also would like feedback from the core libs
> people. Also, I am not sure about the runtime costs of this hack. Seems a
> bit excessive for something which is just a setup error (a correctly
> installed JDK should never have this problem).
>
> As a side note, it may help if jspawnhelper would live in the bin folder of
> the JDK (currently lives in lib), because everyone should be aware that
> programs in bin need execute permissions...
>
> Cheers, Thomas


From david.lloyd at redhat.com  Mon May 13 18:53:54 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 13 May 2019 13:53:54 -0500
Subject: RFR(s): 8223777: In posix_spawn mode, failing to exec()
 jspawnhelper does not result in an error
In-Reply-To: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
Message-ID: <CANghgrQxnN=EcZ8OVZeRF3m-E-8fS6NfkuZ+dqhGz1Rv5SCyuA@mail.gmail.com>

On Mon, May 13, 2019 at 11:01 AM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> Hi all,
>
> may I have please your opinions about the following change:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223777
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error/webrev.00/webrev/
> [...]
> But at least we can test the execute permissions on the
> jspawnhelper. Which this fix does. This fixes Ubuntu 16.4 (Now, I get an
> IOException if jspawnhelper is not executable).

I like it.  But I wonder if it's a good idea to test in this way:

+        /* Require all bits set since this is how jspawnhelper
+         * is set up in a canonical installation */
+        if (s.st_mode & S_IXUSR &&
+            s.st_mode & S_IXGRP &&
+            s.st_mode & S_IXOTH) {
+            return 1;
+        } else {

What if the JDK is not world-accessible for some reason?  This would
not seem unreasonable.  I think it would be best to err on the side of
caution: if no `x` bit is set, then it would not be executable and an
exception should be reported, but otherwise it *may* be executable so
either no error should be reported at this point, or a "smarter" check
should be done (e.g. comparing the UIDs and so forth).

-- 
- DML

From pavel.rappo at oracle.com  Mon May 13 21:25:39 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 13 May 2019 22:25:39 +0100
Subject: RFR 8223730 : URLClassLoader.findClass() can throw
 IndexOutOfBoundsException
In-Reply-To: <af4c0c4a-507b-780f-37a7-b44b96a40f99@oracle.com>
References: <af4c0c4a-507b-780f-37a7-b44b96a40f99@oracle.com>
Message-ID: <7DE6A7C1-02E9-4B50-B298-FF8B641A1469@oracle.com>

Ivan,

This change looks good to me.

It's a pity we can't use 3-args InputStream.readNBytes here. Unrelated to your
change: it looks a bit wasteful to create a zero-length byte array only to throw
it away later. We could probably pre-size it or at least make it a `private
static final`?

-Pavel

> On 11 May 2019, at 23:07, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> Hello!
> 
> An integer overflow during array size calculation can happen in a case of loading extremely huge class file (which is unlikely in the real world).
> 
> It is possible to create a regression test (see the bug), though I doubt it would carry much weight while requiring much memory.
> 
> I did check manually that the POC runs fine with the patched JDK.
> 
> Would you please help review the fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223730
> WEBREV: http://cr.openjdk.java.net/~igerasim/8223730/00/webrev/
> 
> -- 
> With kind regards,
> Ivan Gerasimov
> 


From brent.christian at oracle.com  Mon May 13 23:47:31 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 13 May 2019 16:47:31 -0700
Subject: RFR 8223730 : URLClassLoader.findClass() can throw
 IndexOutOfBoundsException
In-Reply-To: <af4c0c4a-507b-780f-37a7-b44b96a40f99@oracle.com>
References: <af4c0c4a-507b-780f-37a7-b44b96a40f99@oracle.com>
Message-ID: <837204aa-f311-db0d-f33c-421ca377d230@oracle.com>

I think the change looks OK.

I agree that this case is unlikely to come up in the real world, so no 
regtest seems acceptable; tag the bug with noreg-hard.

(Another option might be a test in a seldom-run Tier that @requires a 
large amount of heap.)

-Brent

On 5/11/19 3:07 PM, Ivan Gerasimov wrote:
> Hello!
> 
> An integer overflow during array size calculation can happen in a case 
> of loading extremely huge class file (which is unlikely in the real world).
> 
> It is possible to create a regression test (see the bug), though I doubt 
> it would carry much weight while requiring much memory.
> 
> I did check manually that the POC runs fine with the patched JDK.
> 
> Would you please help review the fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223730
> WEBREV: http://cr.openjdk.java.net/~igerasim/8223730/00/webrev/
> 

From stuart.marks at oracle.com  Tue May 14 00:28:09 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 13 May 2019 17:28:09 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
Message-ID: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>

Hi all,

Here's an updated webrev for this change. The general direction of the change is 
the same as before. Differences are primarily additional wording in a few 
relevant places, plus editorial and markup tweaks. Highlights of changes from 
the previous webrev include:

  - addition of FIXME comment and reference to javadoc bug report, where doc 
comment from interface cannot be inherited
  - tuned up wording around operations that depend on membership semantics of 
more than one collection
  - updated wording about membership semantics in Collections.disjoint()
  - added performance-related @implNote to List.removeAll/retainAll
  - various markup fixes

Webrev:

     http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.1/

Bug:

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

Previous review thread:

     http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060007.html

Thanks,

s'marks

From lance.andersen at oracle.com  Tue May 14 00:44:39 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 13 May 2019 20:44:39 -0400
Subject: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for
 JDK-8213031
In-Reply-To: <AM6PR02MB5192C231B13810C8EF1F3E708A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <HE1PR0201MB226656E770657D840E1FEF228A2F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <AM6PR02MB51929210FF0E3A73571569138A3E0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB519262684DA223A733C7D41B8A3A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192C231B13810C8EF1F3E708A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <8CD9547E-D56E-440F-8DCD-020E26B959D5@oracle.com>

Hi Christoph,

Thank you for taking this on.

Overall this looks pretty good.  A few comments


ZipFileSystem
initCEN()
I think I understand why you made some of the changes here, but for  initializing for example cen, and end, starting on line 137, was there a reason you are doing this outside of the method now?
FindEND()
I know that endsub and comlen fields are not currently used by Zip FS but given they are valid fields in the header we should probably add a comment that they are not currently used which is why they are commented out?
line 1245, comment to Sync
can you fix the typo udpate to update?
line 1928 IndexNode(IndexNode other) , is there a reason you left this code?
line 2061 version(boolean)
Could you add a comment to describe the method as the changes could be confusing to someone looking at this code for the 1st time
lines 2362 and 2462 are commented out but were not previously. Can you clarify why?




HTH
Lance
> On May 9, 2019, at 10:47 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi,
>  
> after exchanging a few mails with Lance, I have a new version ready: http://cr.openjdk.java.net/~clanger/webrevs/8222276.2/ <http://cr.openjdk.java.net/~clanger/webrevs/8222276.2/>
>  
> I stepped back from changing the class hierarchy for ZipFileSystem.IndexNode and ZipFileSystem.Entry. It?s not a prerequisite for my current proposal for JDK-8213031 anymore. I?ve added further cleanups and implemented feedback I got from Lance.
>  
> Please get me some reviews ??
>  
> Thanks
> Christoph
>  
>  
> From: Langer, Christoph 
> Sent: Dienstag, 30. April 2019 11:54
> To: core-libs-dev <core-libs-dev at openjdk.java.net>; nio-dev <nio-dev at openjdk.java.net>; Alan Bateman <Alan.Bateman at oracle.com>; Lance Andersen <lance.andersen at oracle.com>
> Subject: RE: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031
>  
> Hi,
>  
> it turned out that there was a regression in my last version. I needed to fix some initializations in the constructor of Entry. I also added some other fixes found by the IDE?s code analysis to ZipFileSystem.java.
>  
> By accident, I updated the last webrev in-place. So, please find my most current version here:http://cr.openjdk.java.net/~clanger/webrevs/8222276.1/ <http://cr.openjdk.java.net/~clanger/webrevs/8222276.1/>
>  
> Now it passes all testing.
>  
> Thank you
> Christoph
>  
> From: Langer, Christoph 
> Sent: Freitag, 26. April 2019 17:37
> To: core-libs-dev <core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>>; nio-dev <nio-dev at openjdk.java.net <mailto:nio-dev at openjdk.java.net>>; Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>; Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>>
> Subject: RE: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031
>  
> Hi,
>  
> ping ??
>  
> I?ve rebased this change after the latest zipfs updates. I also made some further modifications. Apart from minor things, I modified the constructors of the ZipFileSystem.Entry class and I also made some post JDK-8222440 cleanup.
>  
> Please find the new webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8222276.1/ <http://cr.openjdk.java.net/~clanger/webrevs/8222276.1/>
>  
> The jtreg tests for zipfs are all passing.
>  
> Thanks
> Christoph
>  
> From: Langer, Christoph 
> Sent: Donnerstag, 11. April 2019 16:06
> To: core-libs-dev <core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>>; nio-dev <nio-dev at openjdk.java.net <mailto:nio-dev at openjdk.java.net>>; Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>; Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>>
> Subject: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031
>  
> Hi,
>  
> working on JDK-8213031 to add posix file permission support for the zipfs, I thought it makes sense to factor out some of the changes into a separate change. Those changes reorganize and clean up some parts of the code which I think makes sense in any case.
>  
> Please review:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222276 <https://bugs.openjdk.java.net/browse/JDK-8222276>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8222276.0/ <http://cr.openjdk.java.net/~clanger/webrevs/8222276.0/>
>  
> In detail:
> The main change is to the hierarchy of inner classes ZipFileSystem.IndexNode and ZipFileSystem.Entry (the latter extends the former). Both classes are static classes currently. It makes sense, though, to have those associated with the ZipFileSystem they belong to. 
> To do that, I need to add a static superclass named ZFSNode which only holds a node name and its hashcode. This class needs to exist because of the lookup implementation to find specific nodes of tze ZipFileSystem in its node map. Then the classes IndexNode extends ZFSNode and Entry extends IndexNode can be made non-static. 
> 
> Further changes are: 
> Improve error handling for ZipFileAttributeView::get methods 
> improve handling for zip64 attribute/version 
> minor clenaups such as adding @Override annotations, whitespace fixes, private method visibility etc.
>  
> Furthermore, there is some suspicious coding in JarFileSystem:: createVersionedLinks where a temporary key node is inserted into the alias map. However, this is a singleton instance which always gets new values. I?ll open a separate bug for that and I?ll try to create a test case which demonstrates an issue with the current code.
>  
> I ran the zipfs jtreg tests successfully and will put it into our internal system as well as run it through jdk-submit.
>  
> Thanks
> Christoph

 <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 ivan.gerasimov at oracle.com  Tue May 14 01:23:40 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 13 May 2019 18:23:40 -0700
Subject: RFR 8223730 : URLClassLoader.findClass() can throw
 IndexOutOfBoundsException
In-Reply-To: <837204aa-f311-db0d-f33c-421ca377d230@oracle.com>
References: <af4c0c4a-507b-780f-37a7-b44b96a40f99@oracle.com>
 <837204aa-f311-db0d-f33c-421ca377d230@oracle.com>
Message-ID: <05119676-e8d4-74a7-9ba9-71610313863c@oracle.com>

Thank you Pavel and Brent for reviewing!

With kind regards,

Ivan


On 5/13/19 4:47 PM, Brent Christian wrote:
> I think the change looks OK.
>
> I agree that this case is unlikely to come up in the real world, so no 
> regtest seems acceptable; tag the bug with noreg-hard.
>
> (Another option might be a test in a seldom-run Tier that @requires a 
> large amount of heap.)
>
> -Brent
>
> On 5/11/19 3:07 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> An integer overflow during array size calculation can happen in a 
>> case of loading extremely huge class file (which is unlikely in the 
>> real world).
>>
>> It is possible to create a regression test (see the bug), though I 
>> doubt it would carry much weight while requiring much memory.
>>
>> I did check manually that the POC runs fine with the patched JDK.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223730
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223730/00/webrev/
>>
>

-- 
With kind regards,
Ivan Gerasimov


From thomas.stuefe at gmail.com  Tue May 14 06:36:18 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 14 May 2019 08:36:18 +0200
Subject: RFR(s): 8223777: In posix_spawn mode, failing to exec()
 jspawnhelper does not result in an error
In-Reply-To: <4c317664-05c6-a150-45f0-bc1a2f36aed4@oracle.com>
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
 <4c317664-05c6-a150-45f0-bc1a2f36aed4@oracle.com>
Message-ID: <CAA-vtUyg_HeP6XiFJZhBdcAvwx0_ybtQCvniAgLmF4-8++v6QA@mail.gmail.com>

Hi Roger, David,

second version:

Full:
http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error/webrev.01/webrev/
Delta:
http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error/webrev_delta.01/webrev/

Answering Rogers remarks here since that should cover Davids points too:

On Mon, May 13, 2019 at 8:44 PM Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Thomas,
>
> Some thoughts...
>
> Did you determine exactly how the failure of exec did not result in an
> IOException?
>

posix_spawn() succeeds. Child process is started successfully - so the
fork/vfork/clone/whatever posix_spawn() does internally goes thru
successfully. But child process dies immediately with exit code 127. This
is impossible to tell apart from cases where the target binary was launched
successfull but exited with 127. So there is no way to tell that exec()
failed. For the user it looks like Runtime.exec() was successful but his
program was very short lived.

See comments in code for more details.


> The change at 696 just prevents an exception from getting overwritten but
> not one that is not thrown or was cleared.
>

I changed that coding to return an adduitional static string in case of an
error, which gets appended to the IOException text. So, I restored the
original logic which only throws IOException at the topmost layer.


>
> An improved test for a successful spawnChild could be added to
> initialize resultPid to -1

and check that it has been overwritten with the pid.  If posix_spawn
> returned success,
> there would still be an indication that the process was or was not created.
>
>
 Done, but probably pointless. As I wrote, the child process does get
created, that is not the problem. The follow up exec fails.


> Can the function be named to indicate what is it checking?  For example,
> isHelperExecutable?
> It returns a boolean and it would be more conventional to stick to the C
> interpretation
> of 0 == true, anything else is not.
>

Yes, that is cleaner. All done.


> Requiring all three exec bits may be overkill and does not match the
> actual access test.
> It might be confusing if the permissions were set so Linux could exec
> it, but the Java runtime
> threw an exception because it had a stricter requirement (not documented).
>

David had the same concerns. Of course. Since we cannot safely predict
exec() success I rather have false negatives than false positives.

Both are bad but refusing to exec in situations where it could actually
work is worse.

Neither do I want to go down the rabbit hole and make the pre-exec test
more intricate, there was a reason Martin abandoned that approach in 2005.


> Since this is in the normal path and will very rarely fail, it is
> reasonable to ask
> about any potential performance impact.  Can the test for exec and more
> specific message
> be used only if the exec fails.
>

I dont know if exec fails, which is the whole problem :)

But I changed the coding to only do this test once. Since I find it very
unlikely that someone changes the permissions on the fly, this should be
okay.

I don't know, should it? Now I start to doubt. What do you guys think?


>
> The exception includes the literal "jspawnhelper" which would be
> misleading if it were
> changed and it might be clearer to mention 'exec' permission in the
> message.
>
>
Done. In the message I talk now about "spawn helper" and foresee many a
blog post explaining how to fix this :P


> Thanks, Roger
>

Thanks, Thomas


>
>
>
> On 05/13/2019 12:00 PM, Thomas St?fe wrote:
> > Hi all,
> >
> > may I have please your opinions about the following change:
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8223777
> > webrev:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error/webrev.00/webrev/
> >
> > In short, since some weeks posix_spawn() is used on Linux to spawn
> childs.
> > But the glibc implementation of posix_spawn does not report errors back
> to
> > the caller if exec()ing the target binary fails.
> >
> > We only ever exec the jspawnhelper, which is part of the JDK and which
> then
> > exec()s the real target binary. The second exec() is under our control
> and
> > Martin did provide proper error reporting.
> >
> > However, the first exec(), performed inside posix_spawn(), may fail too.
> > Most posix_spawn implementations will tell us if that happens, not glibc
> > (it is cumbersome to implement, one needs a pipe and somesuch, and POSIX
> > leaves a bit of headroom for the implementor to cheap out, so they did.)
> >
> > So, if someone messes with the JDK installation and e.g. removes the
> > execute bits from jspawnhelper, that first exec() fails, but we get no
> > error. From the outside it looks like Runtime.exec() succeeded.
> >
> > This is impossible to fix completely - see Martin's comment about the
> > impossibility to foresee whether an exec() will succeed without actually
> > exec()ing. But at least we can test the execute permissions on the
> > jspawnhelper. Which this fix does. This fixes Ubuntu 16.4 (Now, I get an
> > IOException if jspawnhelper is not executable).
> >
> > Since I like to be super careful with runtime.exec coding, I will run
> this
> > through our nightlies and also would like feedback from the core libs
> > people. Also, I am not sure about the runtime costs of this hack. Seems a
> > bit excessive for something which is just a setup error (a correctly
> > installed JDK should never have this problem).
> >
> > As a side note, it may help if jspawnhelper would live in the bin folder
> of
> > the JDK (currently lives in lib), because everyone should be aware that
> > programs in bin need execute permissions...
> >
> > Cheers, Thomas
>
>

From adinn at redhat.com  Tue May 14 07:55:39 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 14 May 2019 08:55:39 +0100
Subject: RFR : 8221696: MappedByteBuffer.force method to specify range
In-Reply-To: <e7c92bf1-39b9-956d-93a7-a2b049c3278c@oracle.com>
References: <2c9099f0-d95d-425a-c033-b22ad5c25231@redhat.com>
 <4ad97801-218f-2fa5-e8b5-3f14347c4320@oracle.com>
 <9218d37f-9820-9216-b125-8f3bc2d19e3d@redhat.com>
 <453045f6-0259-e098-8211-0187428adb9f@oracle.com>
 <b6e8c4cd-fa7a-74ae-4881-744883073bbe@redhat.com>
 <40cb2223-6d5a-4262-6293-2f187f578735@redhat.com>
 <e7c92bf1-39b9-956d-93a7-a2b049c3278c@oracle.com>
Message-ID: <27296812-6a69-88ed-ad75-546d5a6535d4@redhat.com>

On 26/04/2019 15:46, Alan Bateman wrote:
> On 25/04/2019 17:34, Andrew Dinn wrote:
>> Also, here is a new webrev including the updated implementations for
>> mappingAddress/Offset/Length as described below
>>
>> JIRA:?? https://bugs.openjdk.java.net/browse/JDK-8221696
>> webrev: http://cr.openjdk.java.net/~adinn/8221696/webrev.02
>>
> This looks right and I agree with your notes on negative addresses. As 
> its tricky to get right then it would be good to get another set of eyes 
> on this.
> 
> A minor nit is that we don't usually use underscores in variable names 
> here, it would be baseAddress rather than base_address, etc.
Alan tested this for me on Windows and MacOS with a successfl outcome 
and oked the push in a private note. I pushed the patch yesterday -- 
modulo fixing the var names to use camelCase instead of under_score.

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  Tue May 14 08:00:42 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 14 May 2019 09:00:42 +0100
Subject: RFR : 8221696: MappedByteBuffer.force method to specify range
In-Reply-To: <DABFA78D-B493-45DB-9EF9-FFFA06523BC6@oracle.com>
References: <2c9099f0-d95d-425a-c033-b22ad5c25231@redhat.com>
 <4ad97801-218f-2fa5-e8b5-3f14347c4320@oracle.com>
 <9218d37f-9820-9216-b125-8f3bc2d19e3d@redhat.com>
 <453045f6-0259-e098-8211-0187428adb9f@oracle.com>
 <b6e8c4cd-fa7a-74ae-4881-744883073bbe@redhat.com>
 <40cb2223-6d5a-4262-6293-2f187f578735@redhat.com>
 <4cda30a8-7d86-de1a-2ff9-ae1904563ead@redhat.com>
 <199698dd-a486-61f4-62c6-d99930e164d8@redhat.com>
 <DABFA78D-B493-45DB-9EF9-FFFA06523BC6@oracle.com>
Message-ID: <4d7b9dc5-ceaa-0df7-bec7-ca39abe9e55a@redhat.com>

Hi Mikael,

Thanks for looking at this.

On 13/05/2019 17:41, Mikael Vidstedt wrote:
> 
> Would it be worth putting the logic in an aptly named (private) method? Something like:
> 
> ...
> private long alignDown(long address, long alignment) {
>     return address & <whatever>;
> }
> ...
> long mapBase = alignDown(address, ps);
> ?
Yes, that would probably be an improvement. However, I am afraid the 
ship has already sailed. I pushed the patch last night on the strength 
of an ok from Alan posted after he tested the patch on Windows and 
MacOS. Perhaps I should fix this in the push of the associated JEP 
implementation?

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 fweimer at redhat.com  Tue May 14 08:22:22 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 14 May 2019 10:22:22 +0200
Subject: RFR(s): 8223777: In posix_spawn mode,
 failing to exec() jspawnhelper does not result in an error
In-Reply-To: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
 ("Thomas \=\?utf-8\?Q\?St\=C3\=BCfe\=22's\?\= message of "Mon,
 13 May 2019 18:00:35 +0200")
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
Message-ID: <878sv9bg3l.fsf@oldenburg2.str.redhat.com>

* Thomas St?fe:

> This is impossible to fix completely - see Martin's comment about the
> impossibility to foresee whether an exec() will succeed without actually
> exec()ing. But at least we can test the execute permissions on the
> jspawnhelper. Which this fix does. This fixes Ubuntu 16.4 (Now, I get an
> IOException if jspawnhelper is not executable).

I think jspawnhelper could write something to the pipe to show that it
has started.  If you never get that notification, you know that
jspawnhelper hasn't run, even if posix_spawn has succeeded.

(This fix will also help qemu-user and WSL, which implement vfork as
fork and interfere with the internal error reporting from posix_spawn.)

Thanks,
Florian

From christoph.langer at sap.com  Tue May 14 08:21:58 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 14 May 2019 08:21:58 +0000
Subject: RFR(S): 8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException:
 CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)
In-Reply-To: <db9a8f14-dd2b-50cd-e66d-5e65755ad47e@oracle.com>
References: <AM6PR02MB5192F6781E65000CF47F62BF8A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <db9a8f14-dd2b-50cd-e66d-5e65755ad47e@oracle.com>
Message-ID: <AM6PR02MB519273C3EFBABD78319DBB7A8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Claes,

thanks for reviewing.

Yes, seems csize will always be > 0 if the entry got deflated. I don?t know the details of the zip algorithm, but DeflaterOutputStream::finish() always causes 2 bytes to be written when the buffer for the file/channel has 0 bytes. So I think the fix really is correct.

Best regards
Christoph

> -----Original Message-----
> From: Claes Redestad <claes.redestad at oracle.com>
> Sent: Montag, 13. Mai 2019 16:59
> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; nio-dev <nio-dev at openjdk.java.net>
> Subject: Re: RFR(S): 8223597: jdk/nio/zipfs/ZipFSTester.java
> RuntimeException: CHECK_FAILED! (getAttribute.crc <entries20> failed
> 6af4413c vs 0 ...)
> 
> Changes and new tests looks good,
> 
> will csize always be > 0 for an empty file/channel?
> 
> /Claes
> 
> On 2019-05-13 14:14, Langer, Christoph wrote:
> > Hi,
> >
> > please review this fix of a regression in zipfs after JDK-8222532 [0].
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8223597
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223597.0/
> >
> > The issue occurs when an empty file/channel is persisted into a zip file. The
> entry had already been compressed with CRC of 0 at the time the output
> stream to the zipfs was closed. But when the Entry is eventually synced to
> the zip file, this is not detected and the bytes get compressed again.
> >
> > The test was adapted to reliably provoke this intermittent error. In the test
> I also suppressed printout of an expected Exception to avoid some
> distraction when reading its JTR files.
> >
> > Thanks
> > Christoph
> >
> > [0] https://bugs.openjdk.java.net/browse/JDK-8222532
> >

From christoph.langer at sap.com  Tue May 14 08:22:14 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 14 May 2019 08:22:14 +0000
Subject: RFR(S): 8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException:
 CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)
In-Reply-To: <9F5FD56C-314E-40D5-B31F-361F56C59E72@oracle.com>
References: <AM6PR02MB5192F6781E65000CF47F62BF8A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <9F5FD56C-314E-40D5-B31F-361F56C59E72@oracle.com>
Message-ID: <AM6PR02MB5192CA102FD6E12B5E7F498B8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>

Thanks, Lance.

From: Lance Andersen <lance.andersen at oracle.com>
Sent: Montag, 13. Mai 2019 19:00
To: Langer, Christoph <christoph.langer at sap.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; nio-dev <nio-dev at openjdk.java.net>
Subject: Re: RFR(S): 8223597: jdk/nio/zipfs/ZipFSTester.java RuntimeException: CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)

Hi Christoph,

The change seems reasonable.

On May 13, 2019, at 8:14 AM, Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:

Hi,

please review this fix of a regression in zipfs after JDK-8222532 [0].

Bug: https://bugs.openjdk.java.net/browse/JDK-8223597
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223597.0/

The issue occurs when an empty file/channel is persisted into a zip file. The entry had already been compressed with CRC of 0 at the time the output stream to the zipfs was closed. But when the Entry is eventually synced to the zip file, this is not detected and the bytes get compressed again.

The test was adapted to reliably provoke this intermittent error. In the test I also suppressed printout of an expected Exception to avoid some distraction when reading its JTR files.

Thanks
Christoph

[0] https://bugs.openjdk.java.net/browse/JDK-8222532

[cid:image001.gif at 01D50A3E.E551EFA0]<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 thomas.stuefe at gmail.com  Tue May 14 09:36:47 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 14 May 2019 11:36:47 +0200
Subject: RFR(s): 8223777: In posix_spawn mode, failing to exec()
 jspawnhelper does not result in an error
In-Reply-To: <878sv9bg3l.fsf@oldenburg2.str.redhat.com>
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
 <878sv9bg3l.fsf@oldenburg2.str.redhat.com>
Message-ID: <CAA-vtUwhjq49AVtpuQxzCr70r3=VPcpXSPHEQYAues52xiTG3w@mail.gmail.com>

Neat idea!

But this incurs costs for this pipe communication on every spawn. What do
the others think?

Cheers, Thomas

On Tue, May 14, 2019 at 10:22 AM Florian Weimer <fweimer at redhat.com> wrote:

> * Thomas St?fe:
>
> > This is impossible to fix completely - see Martin's comment about the
> > impossibility to foresee whether an exec() will succeed without actually
> > exec()ing. But at least we can test the execute permissions on the
> > jspawnhelper. Which this fix does. This fixes Ubuntu 16.4 (Now, I get an
> > IOException if jspawnhelper is not executable).
>
> I think jspawnhelper could write something to the pipe to show that it
> has started.  If you never get that notification, you know that
> jspawnhelper hasn't run, even if posix_spawn has succeeded.
>
> (This fix will also help qemu-user and WSL, which implement vfork as
> fork and interfere with the internal error reporting from posix_spawn.)
>
> Thanks,
> Florian
>

From aph at redhat.com  Tue May 14 09:57:33 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 14 May 2019 10:57:33 +0100
Subject: RFR : 8221696: MappedByteBuffer.force method to specify range
In-Reply-To: <199698dd-a486-61f4-62c6-d99930e164d8@redhat.com>
References: <2c9099f0-d95d-425a-c033-b22ad5c25231@redhat.com>
 <4ad97801-218f-2fa5-e8b5-3f14347c4320@oracle.com>
 <9218d37f-9820-9216-b125-8f3bc2d19e3d@redhat.com>
 <453045f6-0259-e098-8211-0187428adb9f@oracle.com>
 <b6e8c4cd-fa7a-74ae-4881-744883073bbe@redhat.com>
 <40cb2223-6d5a-4262-6293-2f187f578735@redhat.com>
 <4cda30a8-7d86-de1a-2ff9-ae1904563ead@redhat.com>
 <199698dd-a486-61f4-62c6-d99930e164d8@redhat.com>
Message-ID: <f2853edd-de8f-f16e-2cb0-3617a59ff43a@redhat.com>

On 5/13/19 5:14 PM, Andrew Dinn wrote:
> Thank you for looking at the patch.
> 
> On 28/04/2019 18:09, Andrew Haley wrote:
>> On 4/25/19 5:34 PM, Andrew Dinn wrote:
>>>    long map_base = (address & ~(ps - 1));
>>
>> This looks like a hard way to write
>>
>>    long map_base = address & -ps;
> 
> My version certainly uses more characters, that is for sure. However, I 
> chose (and still prefer) this form for /clarity/. It seems to me to 
> communicate as simply as possible what mask is being constructed, 
> granted the starting premise that ps is a power of 2 (i.e. has only a 
> single bit set).
> 
> It only requires elementary knowledge of binary representations to see:
> 
>    firstly, that ps-1 clears the original bit and sets all lower bits;

I think your core argument fails at this point. You have *already*
moved to considering a bitwise transformation as arithmetic.

>    next that ~(ps-1) clears those lower bits and sets all bits from the 
> original (inclusive) upwards;
> 
>    then that the result can be used as a mask to clear those same bottom 
> bits from address;
> 
>    finally that this mask operation is equivalent to rounding down to 
> the relevant power of two.
> 
> I find your alternative (a tad) less clear because it employs an 
> arithmetic operation to achieve the requisite bitwise transformation. 

So does yours. See above.

> That the two expressions compute to equivalent results requires some 
> experience and understanding of the twos-complement representations of 
> numbers rather than basic knowledge of bit fields.
> 
> As a gcc hacker 'your mileage may vary' ;-)
> 
> Crucially, every compiler we rely on is going to produce the same code 
> in both cases.

It helps a lot to think of the operation as sign extending the most
significant bit. This clears up the confusion and removes the need for
the obfuscation, I think.

Still, it's not worth arguing about. You've at least thought about it.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Tue May 14 10:46:11 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 14 May 2019 11:46:11 +0100
Subject: RFR : 8221696: MappedByteBuffer.force method to specify range
In-Reply-To: <f2853edd-de8f-f16e-2cb0-3617a59ff43a@redhat.com>
References: <2c9099f0-d95d-425a-c033-b22ad5c25231@redhat.com>
 <4ad97801-218f-2fa5-e8b5-3f14347c4320@oracle.com>
 <9218d37f-9820-9216-b125-8f3bc2d19e3d@redhat.com>
 <453045f6-0259-e098-8211-0187428adb9f@oracle.com>
 <b6e8c4cd-fa7a-74ae-4881-744883073bbe@redhat.com>
 <40cb2223-6d5a-4262-6293-2f187f578735@redhat.com>
 <4cda30a8-7d86-de1a-2ff9-ae1904563ead@redhat.com>
 <199698dd-a486-61f4-62c6-d99930e164d8@redhat.com>
 <f2853edd-de8f-f16e-2cb0-3617a59ff43a@redhat.com>
Message-ID: <60bc112a-e2c3-1225-75e7-3b653c04ad88@redhat.com>

On 14/05/2019 10:57, Andrew Haley wrote:
> On 5/13/19 5:14 PM, Andrew Dinn wrote:
>> Thank you for looking at the patch.
>> . . .
>>    firstly, that ps-1 clears the original bit and sets all lower bits;
> 
> I think your core argument fails at this point. You have *already*
> moved to considering a bitwise transformation as arithmetic.

Hmm, yes. Well, at least that part doesn't drag in twos complement
arithmetic, simply an understanding of how (the oh so very satisfying)
rollover of all set bits happens when you add 1 to an all 1s pattern and
hence how that rollover must happen in reverse when you subtract 1 from
a single-bit pattern.

> It helps a lot to think of the operation as sign extending the most
> significant bit. This clears up the confusion and removes the need for
> the obfuscation, I think.

Yes, that's another interesting way to think about it.

What is more interesting to me is how different programmers use a
different base toolkit of concepts (and associated coding idioms) to
convince themselves that specific combinations of logical and/or
arithmetic operations achieve desired bit-twiddling outcomes. Of course,
in many cases they don't -- because many programmers either simply don't
encounter or carefully avoid bit-bashing problems. I suspect that, say,
your work on compilers and, say, my work on graphics renderers taught us
both many bit-twiddling tricks that are far from intuitive except when
they are, if only just to us.

> Still, it's not worth arguing about. You've at least thought about it.

And perhaps not just post-hoc ;-) I have always coded and thought about
rounding down this way having first seen the same idiom many years ago
(in Interlisp-D code, believe it or not).

regards,


Andrew Dinn
-----------


From deepak.kejriwal at oracle.com  Tue May 14 11:19:37 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Tue, 14 May 2019 04:19:37 -0700 (PDT)
Subject: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker
 incorrect for Peru
In-Reply-To: <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default>
References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default>
 <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com>
 <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default>
Message-ID: <4c9d3c0b-2970-4cf8-a218-edef84751720@default>

Thanks Ramanand and Naoto for review. Please find updated version of webrev:-

http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.01/

Regards,
Deepak

-----Original Message-----
From: Ramanand Patil 
Sent: Monday, May 13, 2019 12:40 PM
To: Naoto Sato <naoto.sato at oracle.com>; Deepak Kejriwal <deepak.kejriwal at oracle.com>; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: RE: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru

Hi Deepak,
Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID.

Regards,
Ramanand.

-----Original Message-----
From: Naoto Sato 
Sent: Friday, May 10, 2019 6:12 PM
To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru

Hi Deepak, here are my comments.

- FormatData_es_PE.java: Modify the copyright year to 2019.

- Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format.

- Bug8206879.java does not have proper copyright header.

Naoto

On 5/10/19 4:25 AM, Deepak Kejriwal wrote:
> Hello,
> 
>   
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8206879
> 
>   
> 
> The proposed fix is located at:
> 
> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/
> 
>   
> 
> Summary
> 
> In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.).
> 
>   
> 
> Regard,
> 
> Deepak
> 
>   
> 

From david.lloyd at redhat.com  Tue May 14 12:03:19 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 14 May 2019 07:03:19 -0500
Subject: RFR(s): 8223777: In posix_spawn mode, failing to exec()
 jspawnhelper does not result in an error
In-Reply-To: <CAA-vtUwhjq49AVtpuQxzCr70r3=VPcpXSPHEQYAues52xiTG3w@mail.gmail.com>
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
 <878sv9bg3l.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUwhjq49AVtpuQxzCr70r3=VPcpXSPHEQYAues52xiTG3w@mail.gmail.com>
Message-ID: <CANghgrSHrsfF4YLLnVf7ytZ-oU5JPe-5pwCY-DT55NT5G6zPkA@mail.gmail.com>

Pipe communication isn't very costly AFAIK.  The added complexity
would be waiting for either a thing to appear on the pipe indicating
success or else a waitpid/waitid+WNOHANG for exit code 127.  But
writing a thing to the pipe won't help determine if the subsequent
exec succeeded, which is really the interesting bit.

You *could* wait for the other end of the pipe to close (and write
jspawnhelper to close the write end on exec) as an indication that the
subsequent exec succeeded, while also reading from the pipe to
determine if the exec has failed (writing the errno or something).
Not sure if that's racy though, as I've only given it a minute of
thought.

On Tue, May 14, 2019 at 4:37 AM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> Neat idea!
>
> But this incurs costs for this pipe communication on every spawn. What do
> the others think?
>
> Cheers, Thomas
>
> On Tue, May 14, 2019 at 10:22 AM Florian Weimer <fweimer at redhat.com> wrote:
>
> > * Thomas St?fe:
> >
> > > This is impossible to fix completely - see Martin's comment about the
> > > impossibility to foresee whether an exec() will succeed without actually
> > > exec()ing. But at least we can test the execute permissions on the
> > > jspawnhelper. Which this fix does. This fixes Ubuntu 16.4 (Now, I get an
> > > IOException if jspawnhelper is not executable).
> >
> > I think jspawnhelper could write something to the pipe to show that it
> > has started.  If you never get that notification, you know that
> > jspawnhelper hasn't run, even if posix_spawn has succeeded.
> >
> > (This fix will also help qemu-user and WSL, which implement vfork as
> > fork and interfere with the internal error reporting from posix_spawn.)
> >
> > Thanks,
> > Florian
> >



-- 
- DML

From fweimer at redhat.com  Tue May 14 12:15:59 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 14 May 2019 14:15:59 +0200
Subject: RFR(s): 8223777: In posix_spawn mode,
 failing to exec() jspawnhelper does not result in an error
In-Reply-To: <CANghgrSHrsfF4YLLnVf7ytZ-oU5JPe-5pwCY-DT55NT5G6zPkA@mail.gmail.com>
 (David Lloyd's message of "Tue, 14 May 2019 07:03:19 -0500")
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
 <878sv9bg3l.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUwhjq49AVtpuQxzCr70r3=VPcpXSPHEQYAues52xiTG3w@mail.gmail.com>
 <CANghgrSHrsfF4YLLnVf7ytZ-oU5JPe-5pwCY-DT55NT5G6zPkA@mail.gmail.com>
Message-ID: <87zhnp2pvk.fsf@oldenburg2.str.redhat.com>

* David Lloyd:

> Pipe communication isn't very costly AFAIK.  The added complexity
> would be waiting for either a thing to appear on the pipe indicating
> success or else a waitpid/waitid+WNOHANG for exit code 127.  But
> writing a thing to the pipe won't help determine if the subsequent
> exec succeeded, which is really the interesting bit.

Please have a look at the code.  It's already using CLOEXEC to cover
the execve call (src/java.base/unix/native/libjava/ProcessImpl_md.c):

    switch (readFully(fail[0], &errnum, sizeof(errnum))) {
    case 0: break; /* Exec succeeded */
    case sizeof(errnum):
        waitpid(resultPid, NULL, 0);
        throwIOException(env, errnum, "Exec failed");
        goto Catch;
    default:
        throwIOException(env, errno, "Read failed");
        goto Catch;
    }

Instead of 0/4 bytes, the outcome could be 0/4/8 bytes, corresponding to
jspawnhelper exec failure, complete success, and exec failure in
jspawnhelper.

The run-time cost would be the additional pipe write in jspawnhelper.
There shouldn't even be another ping-pong between the processes.

Thanks,
Florian

From christoph.langer at sap.com  Tue May 14 12:38:17 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 14 May 2019 12:38:17 +0000
Subject: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for
 JDK-8213031
In-Reply-To: <8CD9547E-D56E-440F-8DCD-020E26B959D5@oracle.com>
References: <HE1PR0201MB226656E770657D840E1FEF228A2F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <AM6PR02MB51929210FF0E3A73571569138A3E0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB519262684DA223A733C7D41B8A3A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192C231B13810C8EF1F3E708A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <8CD9547E-D56E-440F-8DCD-020E26B959D5@oracle.com>
Message-ID: <AM6PR02MB5192FD0666B75972ADE952458A080@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Lance,

> Thank you for taking this on.

Thank you for reviewing! Unfortunately you didn't look at my latest edition... (http://cr.openjdk.java.net/~clanger/webrevs/8222276.2/)

In v2 I took back the modification of the hierarchy of classes IndexNode and Entry so it should be a bit easier to review. But I touched a few other places, compared to v1.

Your comments still hold in parts, so let me answer them one by one:

> ? ZipFileSystem
> o initCEN()
> ? I think I understand why you made some of the changes here, but
> for ?initializing for example cen, and end, starting on line 137, was there a
> reason you are doing this outside of the method now?

this is obsolete now, not part of the change any longer

> o FindEND()
> ? I know that endsub and comlen fields are not currently used by Zip FS but
> given they are valid fields in the header we should probably add a comment
> that they are not currently used which is why they are commented out?

there is a comment in line 1850 where the members of class END are declared. Shouldn't that suffice?

> o line 1245, comment to Sync
> ? can you fix the typo udpate to update?

already addressed in webrev v2

> o line 1928?IndexNode(IndexNode other)?, is there a reason you left this code?

obsolete now

> o line 2061 version(boolean)
> ? Could you add a comment to describe the method as the changes could be
> confusing to someone looking at this code for the 1st time

addressed in v2, please check

> ? lines 2362 and 2462 are commented out but were not previously. Can you clarify why?

the variables "pos" and "locPos" aren't used thereafter, so no need to increment them at these places. Maybe I should delete the lines altogether?

Thanks
Christoph


From christoph.langer at sap.com  Tue May 14 12:57:07 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 14 May 2019 12:57:07 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
Message-ID: <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Daniel,

> > unfortunately, your proposed solution does not work with javac. I get this
> in the build:
> 
> Oh darn. I should have double checked.
> Can we at least reduce the scope of the @SuppressedWarnings by
> introducing a private method that just has the return call?

Sure, what about this one: http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ?

Thanks
Christoph


From david.lloyd at redhat.com  Tue May 14 13:01:10 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 14 May 2019 08:01:10 -0500
Subject: RFR(s): 8223777: In posix_spawn mode, failing to exec()
 jspawnhelper does not result in an error
In-Reply-To: <87zhnp2pvk.fsf@oldenburg2.str.redhat.com>
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
 <878sv9bg3l.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUwhjq49AVtpuQxzCr70r3=VPcpXSPHEQYAues52xiTG3w@mail.gmail.com>
 <CANghgrSHrsfF4YLLnVf7ytZ-oU5JPe-5pwCY-DT55NT5G6zPkA@mail.gmail.com>
 <87zhnp2pvk.fsf@oldenburg2.str.redhat.com>
Message-ID: <CANghgrT_tp0npVSgn+7ofenqBsysg=jdAjBWUUyoNWD2OfKHuw@mail.gmail.com>

Ah I see.  I like the idea, it would mean pretty comprehensive error
reporting and should work across platforms too I think.

On Tue, May 14, 2019 at 7:16 AM Florian Weimer <fweimer at redhat.com> wrote:
>
> * David Lloyd:
>
> > Pipe communication isn't very costly AFAIK.  The added complexity
> > would be waiting for either a thing to appear on the pipe indicating
> > success or else a waitpid/waitid+WNOHANG for exit code 127.  But
> > writing a thing to the pipe won't help determine if the subsequent
> > exec succeeded, which is really the interesting bit.
>
> Please have a look at the code.  It's already using CLOEXEC to cover
> the execve call (src/java.base/unix/native/libjava/ProcessImpl_md.c):
>
>     switch (readFully(fail[0], &errnum, sizeof(errnum))) {
>     case 0: break; /* Exec succeeded */
>     case sizeof(errnum):
>         waitpid(resultPid, NULL, 0);
>         throwIOException(env, errnum, "Exec failed");
>         goto Catch;
>     default:
>         throwIOException(env, errno, "Read failed");
>         goto Catch;
>     }
>
> Instead of 0/4 bytes, the outcome could be 0/4/8 bytes, corresponding to
> jspawnhelper exec failure, complete success, and exec failure in
> jspawnhelper.
>
> The run-time cost would be the additional pipe write in jspawnhelper.
> There shouldn't even be another ping-pong between the processes.
>
> Thanks,
> Florian



-- 
- DML

From goetz.lindenmaier at sap.com  Tue May 14 13:31:39 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 14 May 2019 13:31:39 +0000
Subject: 8223869: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java on
 more platforms
Message-ID: <VI1PR02MB4463B48F90BEAAA86100DBF8EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>

Hi,

I would like to problem list this test on ppc and s390.
We see it failing, and it seems to be a Problem not related to
the VM, see also the description in JDK-8221305<https://bugs.openjdk.java.net/browse/JDK-8221305> java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

webrev:
http://cr.openjdk.java.net/~goetz/wr19/8223869-MaxAdvance/01/

Best regards,
  Goetz.

From Alan.Bateman at oracle.com  Tue May 14 13:47:20 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 May 2019 14:47:20 +0100
Subject: 8223869: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java
 on more platforms
In-Reply-To: <VI1PR02MB4463B48F90BEAAA86100DBF8EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>
References: <VI1PR02MB4463B48F90BEAAA86100DBF8EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>
Message-ID: <755afe18-631d-cbd2-f8f6-bdbe2aad7595@oracle.com>

On 14/05/2019 14:31, Lindenmaier, Goetz wrote:
> Hi,
>
> I would like to problem list this test on ppc and s390.
> We see it failing, and it seems to be a Problem not related to
> the VM, see also the description in JDK-8221305<https://bugs.openjdk.java.net/browse/JDK-8221305> java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris
>
> webrev:
> http://cr.openjdk.java.net/~goetz/wr19/8223869-MaxAdvance/01/
>
FontMetrics is awt-dev but not worth redirecting this one.

If the issue on these platforms is different JDK-8221305 then best to 
create a new issue and use that to exclude the test (you can't used 
JDK-8223869 as that is the issue you are using to add to the exclude 
list). I'm not 100% certain without trying it, but I think you can put 
it on its own line too.

-Alan

From goetz.lindenmaier at sap.com  Tue May 14 13:59:41 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 14 May 2019 13:59:41 +0000
Subject: 8223869: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java
 on more platforms
In-Reply-To: <755afe18-631d-cbd2-f8f6-bdbe2aad7595@oracle.com>
References: <VI1PR02MB4463B48F90BEAAA86100DBF8EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <755afe18-631d-cbd2-f8f6-bdbe2aad7595@oracle.com>
Message-ID: <VI1PR02MB44636C528DEE94755EF3F7D4EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>

Hi Alan, 

thanks for looking at this.

> If the issue on these platforms is different JDK-8221305 then best to
> create a new issue and use that to exclude the test (you can't used
> JDK-8223869 as that is the issue you are using to add to the exclude
> list). 
Ah, no I think it's the same issue.  Updated webrev:
http://cr.openjdk.java.net/~goetz/wr19/8223869-MaxAdvance/02/
I'll mention linux-ppc64le in 8221305 in a comment.

> I'm not 100% certain without trying it, but I think you can put
> it on its own line too.
No, that's not possible. 
I maintain our own ProblemList, that is just appended to 
the one checked in.  And if I exclude a test we see failing
that is also in the other one, it suddenly starts failing on 
other platforms :/
This is a nuisance!  ... but not relevant for this here :)

Best regards,
  Goetz.



> 
> -Alan

From thomas.stuefe at gmail.com  Tue May 14 14:37:36 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 14 May 2019 16:37:36 +0200
Subject: RFR(s): 8223777: In posix_spawn mode, failing to exec()
 jspawnhelper does not result in an error
In-Reply-To: <87zhnp2pvk.fsf@oldenburg2.str.redhat.com>
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
 <878sv9bg3l.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUwhjq49AVtpuQxzCr70r3=VPcpXSPHEQYAues52xiTG3w@mail.gmail.com>
 <CANghgrSHrsfF4YLLnVf7ytZ-oU5JPe-5pwCY-DT55NT5G6zPkA@mail.gmail.com>
 <87zhnp2pvk.fsf@oldenburg2.str.redhat.com>
Message-ID: <CAA-vtUxWkrNOPU1A--5WhXHHbijXMWMCCmiSD73HD_XvAXyChg@mail.gmail.com>

On Tue, May 14, 2019 at 2:16 PM Florian Weimer <fweimer at redhat.com> wrote:

> * David Lloyd:
>
> > Pipe communication isn't very costly AFAIK.  The added complexity
> > would be waiting for either a thing to appear on the pipe indicating
> > success or else a waitpid/waitid+WNOHANG for exit code 127.  But
> > writing a thing to the pipe won't help determine if the subsequent
> > exec succeeded, which is really the interesting bit.
>
> Please have a look at the code.  It's already using CLOEXEC to cover
> the execve call (src/java.base/unix/native/libjava/ProcessImpl_md.c):
>
>     switch (readFully(fail[0], &errnum, sizeof(errnum))) {
>     case 0: break; /* Exec succeeded */
>     case sizeof(errnum):
>         waitpid(resultPid, NULL, 0);
>         throwIOException(env, errnum, "Exec failed");
>         goto Catch;
>     default:
>         throwIOException(env, errno, "Read failed");
>         goto Catch;
>     }
>
> Instead of 0/4 bytes, the outcome could be 0/4/8 bytes, corresponding to
> jspawnhelper exec failure, complete success, and exec failure in
> jspawnhelper.
>
> The run-time cost would be the additional pipe write in jspawnhelper.
> There shouldn't even be another ping-pong between the processes.
>
>
Yes.

Right now I am worried more about things I cannot determine yet. Where
before we would wait for the pipe to get broken, now we have a read call on
the parent side, a write call on the child side, which both must succeed.
Could they fail sporadically, e.g. due to EINTR? I know this sounds very
vague but around this API I am super careful.

I will also check our proprietary port. I have a deja vue, maybe I did a
similar thing already in our code base (we have an own Runtime.exec
implementation). If that is the case, this would be a proven concept and
I'd feel safer.

..Thomas


> Thanks,
> Florian
>

From Alan.Bateman at oracle.com  Tue May 14 14:43:57 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 May 2019 15:43:57 +0100
Subject: 8223869: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java
 on more platforms
In-Reply-To: <VI1PR02MB44636C528DEE94755EF3F7D4EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>
References: <VI1PR02MB4463B48F90BEAAA86100DBF8EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <755afe18-631d-cbd2-f8f6-bdbe2aad7595@oracle.com>
 <VI1PR02MB44636C528DEE94755EF3F7D4EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>
Message-ID: <fac91b17-d236-6592-4abf-eb2b43d11e49@oracle.com>



On 14/05/2019 14:59, Lindenmaier, Goetz wrote:
> Hi Alan,
>
> thanks for looking at this.
>
>> If the issue on these platforms is different JDK-8221305 then best to
>> create a new issue and use that to exclude the test (you can't used
>> JDK-8223869 as that is the issue you are using to add to the exclude
>> list).
> Ah, no I think it's the same issue.  Updated webrev:
> http://cr.openjdk.java.net/~goetz/wr19/8223869-MaxAdvance/02/
> I'll mention linux-ppc64le in 8221305 in a comment.
That's fine.
>
>> I'm not 100% certain without trying it, but I think you can put
>> it on its own line too.
> No, that's not possible.
> I maintain our own ProblemList, that is just appended to
> the one checked in.  And if I exclude a test we see failing
> that is also in the other one, it suddenly starts failing on
> other platforms :/
> This is a nuisance!  ... but not relevant for this here :)
>
> Best regards,
>    Goetz.
>
>
>
>> -Alan


From Roger.Riggs at oracle.com  Tue May 14 14:50:54 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 14 May 2019 10:50:54 -0400
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
 <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>
Message-ID: <fedb1d4d-3284-8acd-c598-edc003b3e7a5@oracle.com>

Hi Ivan,

The updated patch looks fine.

Strictly speaking, the change to Files.readAllBytes is not indicated by 
the bug report
so please update or comment on the bug report to mention that change.

Thanks, Roger


On 05/13/2019 10:44 AM, Pavel Rappo wrote:
> Thanks for updating your patch. The updated code seems fine.
>
> -Pavel
>
>> On 11 May 2019, at 05:01, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> Hello!
>>
>> Please help review the updated fix.
>>
>> This new webrev includes changes suggested by Pavel, Peter and Roger.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
>>
>> Please note that the behavior of j.n.f.Files.readAllBytes() has changed slightly, so now it *may* be possible to read a file larger than (Integer.MAX_VALUE - 8), if VM is able to allocate that large array.
>>
>> With kind regards,
>> Ivan
>>
>> On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> Jdk has several places with similar logic:  an array needs to be reallocated (by at least some defined amount), taking into account the maximum allowed size of arrays.
>>>
>>> There's clearly an opportunity for refactoring, so it is proposed to introduce a dedicated utility method for calculating the best new size of an array.
>>>
>>> Would you please help review this enhancement?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>>>
>>> Mach5 job ran fine.
>>>
>>> Thanks in advance!
>>>
>> -- 
>> With kind regards,
>> Ivan Gerasimov
>>


From javalists at cbfiddle.com  Tue May 14 15:09:16 2019
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 14 May 2019 08:09:16 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
Message-ID: <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>

Hi Stuart,

I strongly disagree with this change. (Fortunately, I am not a Reviewer, just Opinionated.)

Summary:
  1. The change to removeAll() is a significant incompatible change because of its performance implications.
  2. The benefit of the change to removeAll() is restricted to a few edge cases which arguably are not bugs (with respect to the current documentation). 
  3. The benefit does not outweigh the cost.

In addition, the new concept of "membership semantics" is inadequately defined.

In detail:

I would describe the state of Collections before this change as:

An object supporting the Collection interface either:

1. has a state that identifies a set of member objects

where members can be identified by the results of iteration

where object identification refers to the usual class-based equals/hashCode concept

where set is the mathematical notion

or

2. is an ersatz Collection that adopts the Collection interface because the object supports many useful Collection operations, but not all operations obey #1

The existence of ersatz Collections in the JDK is not ideal, but with the understanding that the effects of Collection operations on ersatz Collections is undefined (implementation dependent), it can be made to work. With this understanding, the "semantic shift" of removeAll() is simply a reflection of the undefined (implementation dependent) behavior of ersatz Collections and is not a bug.

The revised design tries to improve this situation by defining a new category of Collection, namely, a Collection whose membership semantics are defined in a non-standard way (not compatible with equals and hashCode). My understanding is that the ersatz Collections defined by the JDK are all Sets that have either stronger or weaker notions of member identity. Hence, the proposal has the potential of replacing ersatz Collections with non-standard, but well behaved Collections. Indeed, a claim is made that Collections with non-standard membership semantics are well defined and an implication is made that the only possible issue is that the results may be "counterintuitive" when Collections with different membership semantics are mixed.

This sounds like an improvement, except for two things:

1. I don't think removeAll() is well defined.

The definition says: "Removes all of this collection's elements that are also contained in the specified collection."

What are the elements of a Collection with a non-standard membership semantics? Are they all of the objects for which contains() returns true? Are they only the objects returned by the iterator? Is the Collection required to define a canonical set of objects that the iterator must return? Can an iterator return two non-equal objects that are equivalent according to its membership semantics? What happens if the specified collection contains one of these objects but not the other?

The definition says: "After this call returns, this collection will contain no elements in common with the specified collection."

That sounds like Collections.disjoint(), which is undefined in the mixed membership semantics case.

If the statement is meaningful, why isn't Collections.disjoint() defined in this case?

Alternatively, why is it OK for Collections.disjoint() to be undefined, but not removeAll()?

2. There will be serious performance hits.

To me, the troubling consequence is that using removeAll() to remove a small number of elements from a large set implemented using hashing goes from fast to very slow. This consequence does not appear to be covered by the current implementation note. It has nothing to do with the performance of contains() on the parameter, but on the need to test every member of the target.

I will need to review every use of removeAll() in my code and convert to iteration where appropriate. This is a significant incompatibility!

Other comments (if the above issues are discounted):

The concept of non-standard membership semantics is introduced (in Collection) without any previous definition of standard membership semantics or any specification of the requirements for a valid membership semantics. A linkage to the contains() method is implied, but not explained.

Classes such as SortedSet and TreeSet that currently can be used to create ersatz Collections should have their documentation changed to say that they may have non-standard membership semantics.

There should be some guidance to developers on how to write code that operates in a well defined manner on both standard and non-standard Collections, including multiple Collections with mixed membership semantics.

The definition of List.contains() rules out a List class with non-standard membership semantics. Is this necessary?

Given that this is a seriously incompatible change (in performance), why not add a method to reveal whether a Collection is using non-standard membership semantics? If this method returns false, then the Collection is either standard or ersatz, and in the latter case, generic behavior remains undefined, so the old removeAll() optimization can be used.

Alternatively, if the behavior of removeAll with a non-standard parameter is important, it can be supported by a filter(predicate) operation.

Regards,

  Alan


> On May 13, 2019, at 5:28 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi all,
> 
> Here's an updated webrev for this change. The general direction of the change is the same as before. Differences are primarily additional wording in a few relevant places, plus editorial and markup tweaks. Highlights of changes from the previous webrev include:
> 
> - addition of FIXME comment and reference to javadoc bug report, where doc comment from interface cannot be inherited
> - tuned up wording around operations that depend on membership semantics of more than one collection
> - updated wording about membership semantics in Collections.disjoint()
> - added performance-related @implNote to List.removeAll/retainAll
> - various markup fixes
> 
> Webrev:
> 
>    http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.1/
> 
> Bug:
> 
>    https://bugs.openjdk.java.net/browse/JDK-6394757
> 
> Previous review thread:
> 
>    http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060007.html
> 
> Thanks,
> 
> s'marks
> 


From philip.race at oracle.com  Tue May 14 15:39:31 2019
From: philip.race at oracle.com (Phil Race)
Date: Tue, 14 May 2019 08:39:31 -0700
Subject: 8223869: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java
 on more platforms
In-Reply-To: <VI1PR02MB4463B48F90BEAAA86100DBF8EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>
References: <VI1PR02MB4463B48F90BEAAA86100DBF8EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>
Message-ID: <c6263500-bc80-a234-b37b-8afb5e26ba60@oracle.com>

This isn't a core libs test, its a 2D test, so the request should go there.

-phil.

On 5/14/19 6:31 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I would like to problem list this test on ppc and s390.
> We see it failing, and it seems to be a Problem not related to
> the VM, see also the description in JDK-8221305<https://bugs.openjdk.java.net/browse/JDK-8221305> java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris
>
> webrev:
> http://cr.openjdk.java.net/~goetz/wr19/8223869-MaxAdvance/01/
>
> Best regards,
>    Goetz.


From philip.race at oracle.com  Tue May 14 15:40:38 2019
From: philip.race at oracle.com (Phil Race)
Date: Tue, 14 May 2019 08:40:38 -0700
Subject: 8223869: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java
 on more platforms
In-Reply-To: <755afe18-631d-cbd2-f8f6-bdbe2aad7595@oracle.com>
References: <VI1PR02MB4463B48F90BEAAA86100DBF8EC080@VI1PR02MB4463.eurprd02.prod.outlook.com>
 <755afe18-631d-cbd2-f8f6-bdbe2aad7595@oracle.com>
Message-ID: <9d104322-d3e8-fb2e-eb4e-64ca5e0f9740@oracle.com>



On 5/14/19 6:47 AM, Alan Bateman wrote:
> On 14/05/2019 14:31, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I would like to problem list this test on ppc and s390.
>> We see it failing, and it seems to be a Problem not related to
>> the VM, see also the description in 
>> JDK-8221305<https://bugs.openjdk.java.net/browse/JDK-8221305> 
>> java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris
>>
>> webrev:
>> http://cr.openjdk.java.net/~goetz/wr19/8223869-MaxAdvance/01/
>>
> FontMetrics is awt-dev but not worth redirecting this one.

2D, not AWT, and I think it worth discussing there.

-phil.

>
> If the issue on these platforms is different JDK-8221305 then best to 
> create a new issue and use that to exclude the test (you can't used 
> JDK-8223869 as that is the issue you are using to add to the exclude 
> list). I'm not 100% certain without trying it, but I think you can put 
> it on its own line too.
>
> -Alan


From daniel.fuchs at oracle.com  Tue May 14 16:03:45 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 May 2019 17:03:45 +0100
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>

Hi Christoph,

That looks much better, thanks!
(but still not commenting on the other changes ;-))

best regards,

-- daniel

On 14/05/2019 13:57, Langer, Christoph wrote:
> Hi Daniel,
> 
>>> unfortunately, your proposed solution does not work with javac. I get this
>> in the build:
>>
>> Oh darn. I should have double checked.
>> Can we at least reduce the scope of the @SuppressedWarnings by
>> introducing a private method that just has the return call?
> 
> Sure, what about this one: http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ?
> 
> Thanks
> Christoph
> 


From naoto.sato at oracle.com  Tue May 14 16:47:07 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 14 May 2019 09:47:07 -0700
Subject: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker
 incorrect for Peru
In-Reply-To: <4c9d3c0b-2970-4cf8-a218-edef84751720@default>
References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default>
 <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com>
 <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default>
 <4c9d3c0b-2970-4cf8-a218-edef84751720@default>
Message-ID: <f32312ed-32da-95c5-580f-8fe3f5c102a0@oracle.com>

There is a typo in the test file name (and other related locations, such 
as class name, constructor name, etc):

"Fomat" -> "Format"

Otherwise looks good.

Naoto

On 5/14/19 4:19 AM, Deepak Kejriwal wrote:
> Thanks Ramanand and Naoto for review. Please find updated version of webrev:-
> 
> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.01/
> 
> Regards,
> Deepak
> 
> -----Original Message-----
> From: Ramanand Patil
> Sent: Monday, May 13, 2019 12:40 PM
> To: Naoto Sato <naoto.sato at oracle.com>; Deepak Kejriwal <deepak.kejriwal at oracle.com>; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: RE: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru
> 
> Hi Deepak,
> Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID.
> 
> Regards,
> Ramanand.
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Friday, May 10, 2019 6:12 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru
> 
> Hi Deepak, here are my comments.
> 
> - FormatData_es_PE.java: Modify the copyright year to 2019.
> 
> - Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format.
> 
> - Bug8206879.java does not have proper copyright header.
> 
> Naoto
> 
> On 5/10/19 4:25 AM, Deepak Kejriwal wrote:
>> Hello,
>>
>>    
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8206879
>>
>>    
>>
>> The proposed fix is located at:
>>
>> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/
>>
>>    
>>
>> Summary
>>
>> In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.).
>>
>>    
>>
>> Regard,
>>
>> Deepak
>>
>>    
>>

From sargun.vohra at gmail.com  Tue May 14 07:00:08 2019
From: sargun.vohra at gmail.com (Sargun Vohra)
Date: Tue, 14 May 2019 00:00:08 -0700
Subject: Bug in jpackage early access regarding icons with the deb installer
 type
Message-ID: <CAC0wMOsqm=Lt+R34NFO-qJWxhMGAvPyDgobFa+1o_hS=SCFHUw@mail.gmail.com>

I've found a bug in the jpackage tool early access which I obtained from
https://jdk.java.net/jpackage/. The issue is that the icon path is
incorrect in the generated desktop entry file. If there's a better place to
report this, please let me know. Steps to reproduce the bug in Ubuntu are
as follows:

I have a project in which I create an app image with the command:

jpackage create-app-image --output build/jpackage --name modsman-gui
--module-path build/jlinkbase/jlinkjars --module
modsman.gui/modsman.gui.MainKt --runtime-image build/image --icon
icons/linux.png

This creates an app image and puts the icon inside the *resources*
directory.

I then create a deb installer for that package with the command:

jpackage create-installer --installer-type deb --output build/jpackage
--name modsman-gui --app-image build/jpackage/modsman-gui
--app-version 0.0.0 --linux-bundle-name modsman-gui

When I install the resulting deb package, there's a desktop entry installed
called *modsman-gui.desktop*. That file has the following content:

[Desktop Entry]  Name=modsman-gui  Comment=modsman-gui
Exec=/opt/modsman-gui/modsman-gui
Icon=/opt/modsman-gui/modsman-gui.png  Terminal=false
Type=Application  Categories=Unknown

That Icon property points to a path containing the default gray application
icon, *not* the icon I specified when creating the app image. In order to
set the icon properly, the Icon property must be set to:

Icon=/opt/modsman-gui/resources/modsman-gui.png

This is because the create-app-image command put the icon inside the
*resources* subdirectory. So, this is either a bug in create-installer
pointing the desktop entry to the wrong icon, or a bug in create-app-image
placing the icon in the wrong place.

You can reproduce it yourself by cloning my git repo from
https://gitlab.com/sargunv-mc-mods/modsman-new and running ./gradlew
:modsman-gui:jpackage. Inspect the deb package created in
*modsman-gui/build/jpackage*, and you'll find the issue described above.

Reproduced on jpackage version 13-internal downloaded on May 13.

From fweimer at redhat.com  Tue May 14 19:00:51 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 14 May 2019 21:00:51 +0200
Subject: RFR(s): 8223777: In posix_spawn mode,
 failing to exec() jspawnhelper does not result in an error
In-Reply-To: <CAA-vtUxWkrNOPU1A--5WhXHHbijXMWMCCmiSD73HD_XvAXyChg@mail.gmail.com>
 ("Thomas \=\?utf-8\?Q\?St\=C3\=BCfe\=22's\?\= message of "Tue,
 14 May 2019 16:37:36 +0200")
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
 <878sv9bg3l.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUwhjq49AVtpuQxzCr70r3=VPcpXSPHEQYAues52xiTG3w@mail.gmail.com>
 <CANghgrSHrsfF4YLLnVf7ytZ-oU5JPe-5pwCY-DT55NT5G6zPkA@mail.gmail.com>
 <87zhnp2pvk.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUxWkrNOPU1A--5WhXHHbijXMWMCCmiSD73HD_XvAXyChg@mail.gmail.com>
Message-ID: <87v9yczwrg.fsf@oldenburg2.str.redhat.com>

* Thomas St?fe:

> Right now I am worried more about things I cannot determine yet. Where
> before we would wait for the pipe to get broken, now we have a read
> call on the parent side, a write call on the child side, which both
> must succeed. Could they fail sporadically, e.g. due to EINTR? I know
> this sounds very vague but around this API I am super careful.

EINTR should only arrive if there's a signal handler, otherwise the
signal is either ignored or terminates the process.  I don't think
jspawnhelper installs any.  If the write fails, jspawnhelper can just
exit, and it will look like as if it had never launched (resulting in an
error).  The write-after-exec-error case is more problematic than that.

I'm working on this from the other end?adding functionality to glibc, so
that we can eliminate jspawnhelper.  But that's a more long-term effort,
of course.

Thanks,
Florian

From vicente.romero at oracle.com  Tue May 14 20:53:19 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 14 May 2019 16:53:19 -0400
Subject: =?UTF-8?Q?RFR=3a_JDK-8223723=3a_j=2el=2ec=2eMethodTypeDesc=2edropPa?=
 =?UTF-8?Q?rameterTypes=e2=80=8b_throws_the_undocumented_exception=3a_Illega?=
 =?UTF-8?Q?lArgumentException?=
Message-ID: <b3a7137f-3c4f-d303-7508-9f8366820cb6@oracle.com>

Please review fix for [1] at [2]. The implementation of method 
java.lang.constant.MethodTypeDesc::dropParameterTypes was throwing a non 
specified exception. The proposed fix is synchronizing the 
implementation with the specification. Please also review the CSR at 
[3]. Check the problem section in the CSR for more details,

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8223723
[2] http://cr.openjdk.java.net/~vromero/8223767/webrev.00/
[3] https://bugs.openjdk.java.net/browse/JDK-8223918

From christoph.langer at sap.com  Tue May 14 21:03:47 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 14 May 2019 21:03:47 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
Message-ID: <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>

Thanks Daniel.

Can anybody help reviewing the changes to:
src/java.base/share/classes/java/lang/invoke/MethodHandles.java
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
and
src/java.management/share/classes/java/lang/management/ManagementFactory.java ?

Thanks
Christoph

> -----Original Message-----
> From: Daniel Fuchs <daniel.fuchs at oracle.com>
> Sent: Dienstag, 14. Mai 2019 18:04
> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> Cc: compiler-dev at openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
>
> Hi Christoph,
>
> That looks much better, thanks!
> (but still not commenting on the other changes ;-))
>
> best regards,
>
> -- daniel
>
> On 14/05/2019 13:57, Langer, Christoph wrote:
> > Hi Daniel,
> >
> >>> unfortunately, your proposed solution does not work with javac. I get
> this
> >> in the build:
> >>
> >> Oh darn. I should have double checked.
> >> Can we at least reduce the scope of the @SuppressedWarnings by
> >> introducing a private method that just has the return call?
> >
> > Sure, what about this one:
> http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ?
> >
> > Thanks
> > Christoph
> >


From david.holmes at oracle.com  Tue May 14 22:05:20 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 15 May 2019 08:05:20 +1000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>

Hi Christoph,

I'm very reluctant to see changes like this that the compiler folk have 
not determined are actually incorrect. That said ...

On 15/05/2019 7:03 am, Langer, Christoph wrote:
> Thanks Daniel.
> 
> Can anybody help reviewing the changes to:
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java

The introduction of the intermediate local variable seems harmless 
(though why it should be necessary is another matter).

> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java

As you note this should be ok'd by jsr166 folk so I've cc'd Martin 
Buccholz. I dislike seeing a raw type introduced here though.

> and
> src/java.management/share/classes/java/lang/management/ManagementFactory.java ?

Introducing an unchecked cast seems very crude. I'd want the core-libs 
stream experts to comment on this.

Cheers,
David
----

> Thanks
> Christoph
> 
>> -----Original Message-----
>> From: Daniel Fuchs <daniel.fuchs at oracle.com>
>> Sent: Dienstag, 14. Mai 2019 18:04
>> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-libs-
>> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
>> Cc: compiler-dev at openjdk.java.net
>> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
>> Eclipse Java Compiler
>>
>> Hi Christoph,
>>
>> That looks much better, thanks!
>> (but still not commenting on the other changes ;-))
>>
>> best regards,
>>
>> -- daniel
>>
>> On 14/05/2019 13:57, Langer, Christoph wrote:
>>> Hi Daniel,
>>>
>>>>> unfortunately, your proposed solution does not work with javac. I get
>> this
>>>> in the build:
>>>>
>>>> Oh darn. I should have double checked.
>>>> Can we at least reduce the scope of the @SuppressedWarnings by
>>>> introducing a private method that just has the return call?
>>>
>>> Sure, what about this one:
>> http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ?
>>>
>>> Thanks
>>> Christoph
>>>
> 

From vicente.romero at oracle.com  Tue May 14 22:37:22 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 14 May 2019 18:37:22 -0400
Subject: RFR: JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented
 exception IllegalArgumentException
Message-ID: <953e6ae5-365d-251a-901f-a58fc889d9f5@oracle.com>

Please review fix [1] for [2] and the corresponding CSR at [3]. The fix 
is just adding a missing @throws at method j.l.c.MethodHandleDesc::of. 
It is a one liner fix,

Thanks,
Vicente

[1] http://cr.openjdk.java.net/~vromero/8223725/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8223725
[3] https://bugs.openjdk.java.net/browse/JDK-8223920

From lance.andersen at oracle.com  Wed May 15 01:31:56 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 14 May 2019 21:31:56 -0400
Subject: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for
 JDK-8213031
In-Reply-To: <AM6PR02MB5192FD0666B75972ADE952458A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <HE1PR0201MB226656E770657D840E1FEF228A2F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <AM6PR02MB51929210FF0E3A73571569138A3E0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB519262684DA223A733C7D41B8A3A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192C231B13810C8EF1F3E708A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <8CD9547E-D56E-440F-8DCD-020E26B959D5@oracle.com>
 <AM6PR02MB5192FD0666B75972ADE952458A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <6FCBB899-0E26-461A-A4C9-440D90090FA7@oracle.com>

Hi Chistoph,

> On May 14, 2019, at 8:38 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Lance,
> 
>> Thank you for taking this on.
> 
> Thank you for reviewing! Unfortunately you didn't look at my latest edition... (http://cr.openjdk.java.net/~clanger/webrevs/8222276.2/)

Sorry, must have clicked on the wrong webrev.
> 
> In v2 I took back the modification of the hierarchy of classes IndexNode and Entry so it should be a bit easier to review. But I touched a few other places, compared to v1.
> 
OK
> Your comments still hold in parts, so let me answer them one by one:
> 
>> ? ZipFileSystem
>> o initCEN()
>> ? I think I understand why you made some of the changes here, but
>> for  initializing for example cen, and end, starting on line 137, was there a
>> reason you are doing this outside of the method now?
> 
> this is obsolete now, not part of the change any longer
ok
> 
>> o FindEND()
>> ? I know that endsub and comlen fields are not currently used by Zip FS but
>> given they are valid fields in the header we should probably add a comment
>> that they are not currently used which is why they are commented out?
> 
> there is a comment in line 1850 where the members of class END are declared. Shouldn't that suffice?

Personally, I would add a comment about the unused members in the method to make it easier?.
> 
>> o line 1245, comment to Sync
>> ? can you fix the typo udpate to update?
> 
> already addressed in webrev v2

Thank you
> 
>> o line 1928 IndexNode(IndexNode other) , is there a reason you left this code?
> 
> obsolete now

+1
> 
>> o line 2061 version(boolean)
>> ? Could you add a comment to describe the method as the changes could be
>> confusing to someone looking at this code for the 1st time
> 
> addressed in v2, please check

Definitely better but is still a bit confusing as it says stored =10 and zip64=stored (and the value is 45 ;-) ), can we tweak it a bit more
> 
>> ? lines 2362 and 2462 are commented out but were not previously. Can you clarify why?
> 
> the variables "pos" and "locPos" aren't used thereafter, so no need to increment them at these places. Maybe I should delete the lines altogether?

OK, looking at this again (with extra coffee ;-) ) it makes sense and I would delete the lines.  They are a leftover cut & paste code I suspect

Can we move makeParentDirs() closer to buildNodeTree(), perhaps the same for removeFromTree()?

Can the comment on line 1850 be worded better?  I know you are trying to say that  the lines commented out are not used but previously the fields were all together so being a bit more specific would help those coming later on to look at this code.  Same for line 2025.  Also can you add back the comment that writeCEN writes these fields out with a 0 value as we lost that comment?

line 1937: can you fix the typo ?tailing" which should be ?trailing? in the comment.

Best
Lance

> 
> Thanks
> Christoph
> 

 <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 martinrb at google.com  Wed May 15 04:16:33 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 14 May 2019 21:16:33 -0700
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
Message-ID: <CA+kOe0_9rORGxNEqss+i2ek8Vgcx9cEXxvh8g=4O4K71xt_yuw@mail.gmail.com>

I feel the same as David - reluctant to change anything.  Introducing a raw
type makes an ugly cast uglier.

*From: *David Holmes <david.holmes at oracle.com>

> >
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
>
> As you note this should be ok'd by jsr166 folk so I've cc'd Martin
> Buccholz. I dislike seeing a raw type introduced here though.
>
>

From thomas.stuefe at gmail.com  Wed May 15 07:21:51 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 15 May 2019 09:21:51 +0200
Subject: RFR(s): 8223777: In posix_spawn mode, failing to exec()
 jspawnhelper does not result in an error
In-Reply-To: <87v9yczwrg.fsf@oldenburg2.str.redhat.com>
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
 <878sv9bg3l.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUwhjq49AVtpuQxzCr70r3=VPcpXSPHEQYAues52xiTG3w@mail.gmail.com>
 <CANghgrSHrsfF4YLLnVf7ytZ-oU5JPe-5pwCY-DT55NT5G6zPkA@mail.gmail.com>
 <87zhnp2pvk.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUxWkrNOPU1A--5WhXHHbijXMWMCCmiSD73HD_XvAXyChg@mail.gmail.com>
 <87v9yczwrg.fsf@oldenburg2.str.redhat.com>
Message-ID: <CAA-vtUzV_WhcDUcKGCZdqWmfgAn0wRL8VAarxs1H4p=bhtp3ng@mail.gmail.com>

Hi all,

I am currently busy with other things, and I'd like to wait for Rogers and
Martins opinion on this. I think Florans idea is elegant, but as I said,
this is an area where I want to be super careful.

To recap Florians idea:

Using the already existing fail pipe Martin added for jspawnhelper, change
the protocol such that:
- jspawnhelper, just before exec() ing the target binary, will send an
"alive and well and about to exec" code up the pipe to the parent. Then
exec() the target binary.
- for the parent process that means:
    -> if we get nothing, it means the first exec() already failed, we were
not even able to exec jspawnhelper itself
    -> if we get a single error code it means jspawnhelper came up alright
but hit an error before exec()ing the target binary
    -> if we get a "alive and well" code and then pipe breaks this means
all is well - jspawnhelper came up and successfully exec()d the target
binary
    -> if we get a "alive and well" code followed by an error code it means
jspawnhelper came up but we failed to exec() the target binary

Beauty is that this would work for all exec() errors, not just permission
problems. Problem is that this incurs additional costs and potential error
surface to cover a rare situation probably caused by a botched up JDK
installation.

@Florian :

Since we deal with many libc variants, not only glibc, fixing posix_spawn
just in glibc may not be sufficient, at least not for a long time. But if
you would fix glibc and give it a error-reporting back channel for exec()
this would already help a lot. I dug up
https://sourceware.org/bugzilla/show_bug.cgi?id=18433 which sounded pretty
hopeless. I have long given up trying to report bugs to glibc maintainers :(

Thanks, Thomas


On Tue, May 14, 2019 at 9:00 PM Florian Weimer <fweimer at redhat.com> wrote:

> * Thomas St?fe:
>
> > Right now I am worried more about things I cannot determine yet. Where
> > before we would wait for the pipe to get broken, now we have a read
> > call on the parent side, a write call on the child side, which both
> > must succeed. Could they fail sporadically, e.g. due to EINTR? I know
> > this sounds very vague but around this API I am super careful.
>
> EINTR should only arrive if there's a signal handler, otherwise the
> signal is either ignored or terminates the process.  I don't think
> jspawnhelper installs any.  If the write fails, jspawnhelper can just
> exit, and it will look like as if it had never launched (resulting in an
> error).  The write-after-exec-error case is more problematic than that.
>
> I'm working on this from the other end?adding functionality to glibc, so
> that we can eliminate jspawnhelper.  But that's a more long-term effort,
> of course.
>
> Thanks,
> Florian
>

From fweimer at redhat.com  Wed May 15 08:18:23 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 15 May 2019 10:18:23 +0200
Subject: RFR(s): 8223777: In posix_spawn mode,
 failing to exec() jspawnhelper does not result in an error
In-Reply-To: <CAA-vtUzV_WhcDUcKGCZdqWmfgAn0wRL8VAarxs1H4p=bhtp3ng@mail.gmail.com>
 ("Thomas \=\?utf-8\?Q\?St\=C3\=BCfe\=22's\?\= message of "Wed,
 15 May 2019 09:21:51 +0200")
References: <CAA-vtUz9z+08pVs3xDPKjDU8Qy2P6nOg3Dn_ru-y5aH52MqhHQ@mail.gmail.com>
 <878sv9bg3l.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUwhjq49AVtpuQxzCr70r3=VPcpXSPHEQYAues52xiTG3w@mail.gmail.com>
 <CANghgrSHrsfF4YLLnVf7ytZ-oU5JPe-5pwCY-DT55NT5G6zPkA@mail.gmail.com>
 <87zhnp2pvk.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUxWkrNOPU1A--5WhXHHbijXMWMCCmiSD73HD_XvAXyChg@mail.gmail.com>
 <87v9yczwrg.fsf@oldenburg2.str.redhat.com>
 <CAA-vtUzV_WhcDUcKGCZdqWmfgAn0wRL8VAarxs1H4p=bhtp3ng@mail.gmail.com>
Message-ID: <87zhnoxh9s.fsf@oldenburg2.str.redhat.com>

* Thomas St?fe:

> Since we deal with many libc variants, not only glibc, fixing
> posix_spawn just in glibc may not be sufficient, at least not for a
> long time.

I think Solaris already has the required functionality, so it's not
entirely glibc-specific.

> But if you would fix glibc and give it a error-reporting back channel
> for exec() this would already help a lot. I dug up
> https://sourceware.org/bugzilla/show_bug.cgi?id=18433 which sounded
> pretty hopeless.

Well, this one at least is fixed.  But it will take some time to
propagate to distributions, of course.  If an issue really bugs you, it
might help to open backport requests with distribution maintainers.

> I have long given up trying to report bugs to glibc maintainers :(

Sorry to hear that.  I think there's value in actually fixing the buggy
component, and not working around breakage elsewhere.

Thanks,
Florian

From deepak.kejriwal at oracle.com  Wed May 15 13:13:39 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Wed, 15 May 2019 06:13:39 -0700 (PDT)
Subject: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker
 incorrect for Peru
In-Reply-To: <f32312ed-32da-95c5-580f-8fe3f5c102a0@oracle.com>
References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default>
 <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com>
 <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default>
 <4c9d3c0b-2970-4cf8-a218-edef84751720@default>
 <f32312ed-32da-95c5-580f-8fe3f5c102a0@oracle.com>
Message-ID: <714af9f3-8011-4b69-864a-3c6c717953c6@default>

Thanks Naoto for review, please find below updated version of webrev:-

http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.02/

Regards,
Deepak

-----Original Message-----
From: Naoto Sato 
Sent: Tuesday, May 14, 2019 10:17 PM
To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Ramanand Patil <ramanand.patil at oracle.com>; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru

There is a typo in the test file name (and other related locations, such as class name, constructor name, etc):

"Fomat" -> "Format"

Otherwise looks good.

Naoto

On 5/14/19 4:19 AM, Deepak Kejriwal wrote:
> Thanks Ramanand and Naoto for review. Please find updated version of 
> webrev:-
> 
> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.01/
> 
> Regards,
> Deepak
> 
> -----Original Message-----
> From: Ramanand Patil
> Sent: Monday, May 13, 2019 12:40 PM
> To: Naoto Sato <naoto.sato at oracle.com>; Deepak Kejriwal 
> <deepak.kejriwal at oracle.com>; i18n-dev at openjdk.java.net; 
> core-libs-dev at openjdk.java.net
> Subject: RE: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker 
> incorrect for Peru
> 
> Hi Deepak,
> Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID.
> 
> Regards,
> Ramanand.
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Friday, May 10, 2019 6:12 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; 
> i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker 
> incorrect for Peru
> 
> Hi Deepak, here are my comments.
> 
> - FormatData_es_PE.java: Modify the copyright year to 2019.
> 
> - Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format.
> 
> - Bug8206879.java does not have proper copyright header.
> 
> Naoto
> 
> On 5/10/19 4:25 AM, Deepak Kejriwal wrote:
>> Hello,
>>
>>    
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8206879
>>
>>    
>>
>> The proposed fix is located at:
>>
>> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/
>>
>>    
>>
>> Summary
>>
>> In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.).
>>
>>    
>>
>> Regard,
>>
>> Deepak
>>
>>    
>>

From christoph.langer at sap.com  Wed May 15 13:25:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 15 May 2019 13:25:39 +0000
Subject: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for
 JDK-8213031
In-Reply-To: <6FCBB899-0E26-461A-A4C9-440D90090FA7@oracle.com>
References: <HE1PR0201MB226656E770657D840E1FEF228A2F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <AM6PR02MB51929210FF0E3A73571569138A3E0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB519262684DA223A733C7D41B8A3A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192C231B13810C8EF1F3E708A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <8CD9547E-D56E-440F-8DCD-020E26B959D5@oracle.com>
 <AM6PR02MB5192FD0666B75972ADE952458A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <6FCBB899-0E26-461A-A4C9-440D90090FA7@oracle.com>
Message-ID: <AM6PR02MB5192D24B64BA5CAA0BEA57E48A090@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Lance,

thanks for the quick turnaround. I tried to address your findings. Please find the new webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8222276.3/ 

> o FindEND()
> ? I know that endsub and comlen fields are not currently used by Zip FS but
> given they are valid fields in the header we should probably add a comment
> that they are not currently used which is why they are commented out?
> 
> there is a comment in line 1850 where the members of class END are
> declared. Shouldn't that suffice?
> 
> Personally, I would add a comment about the unused members in the
> method to make it easier?.

Ok, I've added comments.

> o line 2061 version(boolean)
> ? Could you add a comment to describe the method as the changes could be
> confusing to someone looking at this code for the 1st time
> 
> addressed in v2, please check
> 
> Definitely better but is still a bit confusing as it says stored =10 and
> zip64=stored (and the value is 45 ;-) ), can we tweak it a bit more

Check it now ??

> ? lines 2362 and 2462 are commented out but were not previously. Can you
> clarify why?
> 
> the variables "pos" and "locPos" aren't used thereafter, so no need to
> increment them at these places. Maybe I should delete the lines altogether?
> 
> OK, looking at this again (with extra coffee ;-) ) it makes sense and I would
> delete the lines. ?They are a leftover cut & paste code I suspect

Deleted.

> Can we move makeParentDirs() closer to buildNodeTree(), perhaps the
> same for removeFromTree()?

Done.

> Can the comment on line 1850 be worded better? ?I know you are trying to
> say that ?the lines commented out are not used but previously the fields
> were all together so being a bit more specific would help those coming later
> on to look at this code. ?Same for line 2025. ?Also can you add back the
> comment that writeCEN writes these fields out with a 0 value as we lost that
> comment?

I updated this, please check.

> line 1937: can you fix the typo ?tailing" which should be ?trailing? in the
> comment.

Done.

Does it look good now? It runs successfully through our regression testing system.

Thanks and best regards
Christoph


From christoph.langer at sap.com  Wed May 15 13:59:08 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 15 May 2019 13:59:08 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
Message-ID: <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi David, Martin,

thanks for looking into this.

Generally I share your view on this. It's not nice at all.

However, it's the only way I can see currently to get rid of the Errors in the Eclipse IDE. Maybe an idea would be to get this in but at the same time open a ticket to evaluate this code again from a compiler/spec perspective and make the according modifications?

Thanks
Christoph

> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Mittwoch, 15. Mai 2019 00:05
> To: Langer, Christoph <christoph.langer at sap.com>; Daniel Fuchs
> <daniel.fuchs at oracle.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> Cc: compiler-dev at openjdk.java.net; Martin Buchholz
> <martinrb at google.com>
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
> 
> Hi Christoph,
> 
> I'm very reluctant to see changes like this that the compiler folk have
> not determined are actually incorrect. That said ...
> 
> On 15/05/2019 7:03 am, Langer, Christoph wrote:
> > Thanks Daniel.
> >
> > Can anybody help reviewing the changes to:
> > src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> 
> The introduction of the intermediate local variable seems harmless
> (though why it should be necessary is another matter).
> 
> >
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav
> a
> 
> As you note this should be ok'd by jsr166 folk so I've cc'd Martin
> Buccholz. I dislike seeing a raw type introduced here though.
> 
> > and
> >
> src/java.management/share/classes/java/lang/management/ManagementF
> actory.java ?
> 
> Introducing an unchecked cast seems very crude. I'd want the core-libs
> stream experts to comment on this.
> 
> Cheers,
> David
> ----
> 
> > Thanks
> > Christoph
> >
> >> -----Original Message-----
> >> From: Daniel Fuchs <daniel.fuchs at oracle.com>
> >> Sent: Dienstag, 14. Mai 2019 18:04
> >> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-dev <core-
> libs-
> >> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>
> >> Cc: compiler-dev at openjdk.java.net
> >> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with
> the
> >> Eclipse Java Compiler
> >>
> >> Hi Christoph,
> >>
> >> That looks much better, thanks!
> >> (but still not commenting on the other changes ;-))
> >>
> >> best regards,
> >>
> >> -- daniel
> >>
> >> On 14/05/2019 13:57, Langer, Christoph wrote:
> >>> Hi Daniel,
> >>>
> >>>>> unfortunately, your proposed solution does not work with javac. I get
> >> this
> >>>> in the build:
> >>>>
> >>>> Oh darn. I should have double checked.
> >>>> Can we at least reduce the scope of the @SuppressedWarnings by
> >>>> introducing a private method that just has the return call?
> >>>
> >>> Sure, what about this one:
> >> http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ?
> >>>
> >>> Thanks
> >>> Christoph
> >>>
> >

From vicente.romero at oracle.com  Wed May 15 15:36:02 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 15 May 2019 11:36:02 -0400
Subject: RFR: JDK-8223726: j.l.c.MethodTypeDesc spec should contain precise
 assertions for one parameter's methods
Message-ID: <3e9df442-7b1c-cf06-b916-b357af2742e5@oracle.com>

Please review fix for [1] at [2], this is a simple fix that is just 
rewording the doc of a couple of methods at 
java.lang.constant.MethodTypeDesc,

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8223726
[2] http://cr.openjdk.java.net/~vromero/8223726/webrev.00/

From naoto.sato at oracle.com  Wed May 15 16:19:57 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 15 May 2019 09:19:57 -0700
Subject: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker
 incorrect for Peru
In-Reply-To: <714af9f3-8011-4b69-864a-3c6c717953c6@default>
References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default>
 <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com>
 <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default>
 <4c9d3c0b-2970-4cf8-a218-edef84751720@default>
 <f32312ed-32da-95c5-580f-8fe3f5c102a0@oracle.com>
 <714af9f3-8011-4b69-864a-3c6c717953c6@default>
Message-ID: <c9ba6f64-7040-123d-1b83-8b15c66593a2@oracle.com>

Thanks, Deepak. Looks good.

Naoto

On 5/15/19 6:13 AM, Deepak Kejriwal wrote:
> Thanks Naoto for review, please find below updated version of webrev:-
> 
> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.02/
> 
> Regards,
> Deepak
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Tuesday, May 14, 2019 10:17 PM
> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>; Ramanand Patil <ramanand.patil at oracle.com>; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru
> 
> There is a typo in the test file name (and other related locations, such as class name, constructor name, etc):
> 
> "Fomat" -> "Format"
> 
> Otherwise looks good.
> 
> Naoto
> 
> On 5/14/19 4:19 AM, Deepak Kejriwal wrote:
>> Thanks Ramanand and Naoto for review. Please find updated version of
>> webrev:-
>>
>> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.01/
>>
>> Regards,
>> Deepak
>>
>> -----Original Message-----
>> From: Ramanand Patil
>> Sent: Monday, May 13, 2019 12:40 PM
>> To: Naoto Sato <naoto.sato at oracle.com>; Deepak Kejriwal
>> <deepak.kejriwal at oracle.com>; i18n-dev at openjdk.java.net;
>> core-libs-dev at openjdk.java.net
>> Subject: RE: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker
>> incorrect for Peru
>>
>> Hi Deepak,
>> Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID.
>>
>> Regards,
>> Ramanand.
>>
>> -----Original Message-----
>> From: Naoto Sato
>> Sent: Friday, May 10, 2019 6:12 PM
>> To: Deepak Kejriwal <deepak.kejriwal at oracle.com>;
>> i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> Subject: Re: <i18n dev> [13] RFR: JDK-8206879: Currency decimal marker
>> incorrect for Peru
>>
>> Hi Deepak, here are my comments.
>>
>> - FormatData_es_PE.java: Modify the copyright year to 2019.
>>
>> - Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format.
>>
>> - Bug8206879.java does not have proper copyright header.
>>
>> Naoto
>>
>> On 5/10/19 4:25 AM, Deepak Kejriwal wrote:
>>> Hello,
>>>
>>>     
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8206879
>>>
>>>     
>>>
>>> The proposed fix is located at:
>>>
>>> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/
>>>
>>>     
>>>
>>> Summary
>>>
>>> In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.).
>>>
>>>     
>>>
>>> Regard,
>>>
>>> Deepak
>>>
>>>     
>>>

From joe.darcy at oracle.com  Wed May 15 17:45:50 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 15 May 2019 10:45:50 -0700
Subject: RFR: JDK-8223726: j.l.c.MethodTypeDesc spec should contain
 precise assertions for one parameter's methods
In-Reply-To: <3e9df442-7b1c-cf06-b916-b357af2742e5@oracle.com>
References: <3e9df442-7b1c-cf06-b916-b357af2742e5@oracle.com>
Message-ID: <cfa9fea6-60f4-a085-0fb6-b18996151c93@oracle.com>

Hi Vicente,

Should

 ?180????? * @throws NullPointerException if any argument is {@code null}
 ?181????? */
 ?182???? static DirectMethodHandleDesc ofConstructor(ClassDesc owner,
 ?183???????????????????????????????????????????????? ClassDesc... 
paramTypes) {

be "any argument or its contents is {@code null}", i.e. if the elements 
of paramTypes are null, is NPE thrown?

Otherwise, the change looks good.

Thanks,

-Joe

On 5/15/2019 8:36 AM, Vicente Romero wrote:
> Please review fix for [1] at [2], this is a simple fix that is just 
> rewording the doc of a couple of methods at 
> java.lang.constant.MethodTypeDesc,
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223726
> [2] http://cr.openjdk.java.net/~vromero/8223726/webrev.00/

From Roger.Riggs at oracle.com  Wed May 15 20:32:09 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 15 May 2019 16:32:09 -0400
Subject: RFR8220166 : Performance regression in deserialization
Message-ID: <d03c403b-fd69-5b62-2809-73cc39de5868@oracle.com>

Please review a change in the synchronization during the creation of an 
ObjectInputStream.
Currently, a synchronized block is used to initialize the streams filter 
is read the global serial filter
which becomes a bottleneck under high concurrency.? Since the value only 
ever changes from null to non-null
once, the synchronization is not needed.? Changing the field to volatile 
and removing
the synchronization on read should alleviate the contention.

Issue:
 ? https://bugs.openjdk.java.net/browse/JDK-8220166

Webrev:
 ? http://cr.openjdk.java.net/~rriggs/webrev-fix-8220166/index.html

Thanks, Roger


From shade at redhat.com  Wed May 15 20:44:44 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 15 May 2019 22:44:44 +0200
Subject: RFR8220166 : Performance regression in deserialization
In-Reply-To: <d03c403b-fd69-5b62-2809-73cc39de5868@oracle.com>
References: <d03c403b-fd69-5b62-2809-73cc39de5868@oracle.com>
Message-ID: <418843ab-c8d1-51f7-1894-e0f3fdf873dd@redhat.com>

On 5/15/19 10:32 PM, Roger Riggs wrote:
> Issue:
> ? https://bugs.openjdk.java.net/browse/JDK-8220166
> 
> Webrev:
> ? http://cr.openjdk.java.net/~rriggs/webrev-fix-8220166/index.html

This looks good to me, Roger.

I also marked issue to get it on our backporting interest queue.

-Aleksey


From vicente.romero at oracle.com  Wed May 15 21:27:58 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 15 May 2019 17:27:58 -0400
Subject: =?UTF-8?Q?RFR=3a_JDK-8223803=3a_j=2el=2ec=2eMethodTypeDesc=3a=3ains?=
 =?UTF-8?Q?ertParameterTypes=e2=80=8b_doesn=27t_control_type_of_parameters?=
Message-ID: <7f26e3c2-f28b-eef0-3ed9-538e1b43e529@oracle.com>

Please review fix for [1] at [2] and the related CSR at [3]. Method 
java.lang.constant.MethodTypeDesc::insertParameterTypes? should control 
the type of parameters being inserted. In particular, no parameter can 
be a class descriptor of primitive type |void|. This fix is updating the 
spec of the mentioned method plus it is adding a test to make sure that 
the implementation is in sync with the specification. As mentioned in 
the CSR and apiNote has been added to method 
j.l.c.ConstantDesc::resolveConstantDesc to clarify that a method type 
descriptor can have more than 255 argument slots so at resolution time, 
as a j.l.i.MethodType, errors can be thrown.

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8223803
[2] http://cr.openjdk.java.net/~vromero/8223803/webrev.00/
[3] https://bugs.openjdk.java.net/browse/JDK-8223997

From ivan.gerasimov at oracle.com  Thu May 16 02:47:32 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 15 May 2019 19:47:32 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <fedb1d4d-3284-8acd-c598-edc003b3e7a5@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
 <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>
 <fedb1d4d-3284-8acd-c598-edc003b3e7a5@oracle.com>
Message-ID: <a6b73d24-3174-0f2d-8dc7-4011183b00ce@oracle.com>

Thank you Pavel and Roger for reviewing!

I apologize for reiterating this.
After off-line discussion with Stuart Marks, the fix was modified once 
again.
The modifications were mostly stylistic:  The used terminology now 
reflects that we work with arrays (thus 'length', not 'size' or 'capacity').
Functionally, the fix remains exactly the same.

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

With kind regards,
Ivan

On 5/14/19 7:50 AM, Roger Riggs wrote:
> Hi Ivan,
>
> The updated patch looks fine.
>
> Strictly speaking, the change to Files.readAllBytes is not indicated 
> by the bug report
> so please update or comment on the bug report to mention that change.
>
> Thanks, Roger
>
>
> On 05/13/2019 10:44 AM, Pavel Rappo wrote:
>> Thanks for updating your patch. The updated code seems fine.
>>
>> -Pavel
>>
>>> On 11 May 2019, at 05:01, Ivan Gerasimov<ivan.gerasimov at oracle.com>  wrote:
>>>
>>> Hello!
>>>
>>> Please help review the updated fix.
>>>
>>> This new webrev includes changes suggested by Pavel, Peter and Roger.
>>>
>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
>>>
>>> Please note that the behavior of j.n.f.Files.readAllBytes() has changed slightly, so now it *may* be possible to read a file larger than (Integer.MAX_VALUE - 8), if VM is able to allocate that large array.
>>>
>>> With kind regards,
>>> Ivan
>>>
>>> On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
>>>> Hello!
>>>>
>>>> Jdk has several places with similar logic:  an array needs to be reallocated (by at least some defined amount), taking into account the maximum allowed size of arrays.
>>>>
>>>> There's clearly an opportunity for refactoring, so it is proposed to introduce a dedicated utility method for calculating the best new size of an array.
>>>>
>>>> Would you please help review this enhancement?
>>>>
>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>>>>
>>>> Mach5 job ran fine.
>>>>
>>>> Thanks in advance!
>>>>
>>> -- 
>>> With kind regards,
>>> Ivan Gerasimov
>>>
>

-- 
With kind regards,
Ivan Gerasimov


From david.holmes at oracle.com  Thu May 16 09:16:52 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 May 2019 19:16:52 +1000
Subject: RFR8220166 : Performance regression in deserialization
In-Reply-To: <d03c403b-fd69-5b62-2809-73cc39de5868@oracle.com>
References: <d03c403b-fd69-5b62-2809-73cc39de5868@oracle.com>
Message-ID: <c3f1c2ef-7587-404c-74be-24dd523f80b7@oracle.com>

Hi Roger,

On 16/05/2019 6:32 am, Roger Riggs wrote:
> Please review a change in the synchronization during the creation of an 
> ObjectInputStream.
> Currently, a synchronized block is used to initialize the streams filter 
> is read the global serial filter
> which becomes a bottleneck under high concurrency.? Since the value only 
> ever changes from null to non-null
> once, the synchronization is not needed.? Changing the field to volatile 
> and removing
> the synchronization on read should alleviate the contention.

That looks fine to me. Even if the value could change repeatedly you 
don't need the sync on the read, as long as its volatile.

Cheers,
David
-----

> Issue:
>  ? https://bugs.openjdk.java.net/browse/JDK-8220166
> 
> Webrev:
>  ? http://cr.openjdk.java.net/~rriggs/webrev-fix-8220166/index.html
> 
> Thanks, Roger
> 

From Alan.Bateman at oracle.com  Thu May 16 09:43:57 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 May 2019 10:43:57 +0100
Subject: RFR8220166 : Performance regression in deserialization
In-Reply-To: <d03c403b-fd69-5b62-2809-73cc39de5868@oracle.com>
References: <d03c403b-fd69-5b62-2809-73cc39de5868@oracle.com>
Message-ID: <cd5b2695-cd79-d067-3f2a-2518486cfad4@oracle.com>

On 15/05/2019 21:32, Roger Riggs wrote:
> Please review a change in the synchronization during the creation of 
> an ObjectInputStream.
> Currently, a synchronized block is used to initialize the streams 
> filter is read the global serial filter
> which becomes a bottleneck under high concurrency.? Since the value 
> only ever changes from null to non-null
> once, the synchronization is not needed.? Changing the field to 
> volatile and removing
> the synchronization on read should alleviate the contention.
>
> Issue:
> ? https://bugs.openjdk.java.net/browse/JDK-8220166
>
> Webrev:
> ? http://cr.openjdk.java.net/~rriggs/webrev-fix-8220166/index.html
This looks okay. In passing, getSerialFilter's javadoc doesn't make 
clear that it can return non-null when configured or set.? The setter is 
a bit clearer on this point.

-Alan

From Alan.Bateman at oracle.com  Thu May 16 13:14:21 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 May 2019 14:14:21 +0100
Subject: RFR : 8221696: MappedByteBuffer.force method to specify range
In-Reply-To: <4d7b9dc5-ceaa-0df7-bec7-ca39abe9e55a@redhat.com>
References: <2c9099f0-d95d-425a-c033-b22ad5c25231@redhat.com>
 <4ad97801-218f-2fa5-e8b5-3f14347c4320@oracle.com>
 <9218d37f-9820-9216-b125-8f3bc2d19e3d@redhat.com>
 <453045f6-0259-e098-8211-0187428adb9f@oracle.com>
 <b6e8c4cd-fa7a-74ae-4881-744883073bbe@redhat.com>
 <40cb2223-6d5a-4262-6293-2f187f578735@redhat.com>
 <4cda30a8-7d86-de1a-2ff9-ae1904563ead@redhat.com>
 <199698dd-a486-61f4-62c6-d99930e164d8@redhat.com>
 <DABFA78D-B493-45DB-9EF9-FFFA06523BC6@oracle.com>
 <4d7b9dc5-ceaa-0df7-bec7-ca39abe9e55a@redhat.com>
Message-ID: <91bdc97a-10c6-7475-c71e-f4a8d5c67dd9@oracle.com>



On 14/05/2019 09:00, Andrew Dinn wrote:
> Hi Mikael,
>
> Thanks for looking at this.
>
> On 13/05/2019 17:41, Mikael Vidstedt wrote:
>>
>> Would it be worth putting the logic in an aptly named (private) 
>> method? Something like:
>>
>> ...
>> private long alignDown(long address, long alignment) {
>> ??? return address & <whatever>;
>> }
>> ...
>> long mapBase = alignDown(address, ps);
>> ?
> Yes, that would probably be an improvement. However, I am afraid the 
> ship has already sailed. I pushed the patch last night on the strength 
> of an ok from Alan posted after he tested the patch on Windows and 
> MacOS. Perhaps I should fix this in the push of the associated JEP 
> implementation?
Mikael's suggestion seem okay. This is under the hood implementation so 
doesn't matter if there is a follow-on issue or you include it in the 
bigger patch. It might be easier to do the former while it's fresh in 
our minds.

-Alan

From lance.andersen at oracle.com  Thu May 16 13:44:25 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 16 May 2019 09:44:25 -0400
Subject: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for
 JDK-8213031
In-Reply-To: <AM6PR02MB5192D24B64BA5CAA0BEA57E48A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <HE1PR0201MB226656E770657D840E1FEF228A2F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <AM6PR02MB51929210FF0E3A73571569138A3E0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB519262684DA223A733C7D41B8A3A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192C231B13810C8EF1F3E708A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <8CD9547E-D56E-440F-8DCD-020E26B959D5@oracle.com>
 <AM6PR02MB5192FD0666B75972ADE952458A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <6FCBB899-0E26-461A-A4C9-440D90090FA7@oracle.com>
 <AM6PR02MB5192D24B64BA5CAA0BEA57E48A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <56562D6E-AFAA-4BE3-B0AD-04A2B106BA82@oracle.com>

Hi Christoph,

Thank you for the update.

Looks good.  One minor suggestion below that  you can take care of before you push without a new webrev.

Best,
Lance
> On May 15, 2019, at 9:25 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Lance,
> 
> thanks for the quick turnaround. I tried to address your findings. Please find the new webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8222276.3/ 
> 
>> o FindEND()
>> ? I know that endsub and comlen fields are not currently used by Zip FS but
>> given they are valid fields in the header we should probably add a comment
>> that they are not currently used which is why they are commented out?
>> 
>> there is a comment in line 1850 where the members of class END are
>> declared. Shouldn't that suffice?
>> 
>> Personally, I would add a comment about the unused members in the
>> method to make it easier?.
> 
> Ok, I've added comments.

+1
> 
>> o line 2061 version(boolean)
>> ? Could you add a comment to describe the method as the changes could be
>> confusing to someone looking at this code for the 1st time
>> 
>> addressed in v2, please check
>> 
>> Definitely better but is still a bit confusing as it says stored =10 and
>> zip64=stored (and the value is 45 ;-) ), can we tweak it a bit more
> 
> Check it now ??

Looks good
> 
>> ? lines 2362 and 2462 are commented out but were not previously. Can you
>> clarify why?
>> 
>> the variables "pos" and "locPos" aren't used thereafter, so no need to
>> increment them at these places. Maybe I should delete the lines altogether?
>> 
>> OK, looking at this again (with extra coffee ;-) ) it makes sense and I would
>> delete the lines.  They are a leftover cut & paste code I suspect
> 
> Deleted.

:-)
> 
>> Can we move makeParentDirs() closer to buildNodeTree(), perhaps the
>> same for removeFromTree()?
> 
> Done.
+1
> 
>> Can the comment on line 1850 be worded better?  I know you are trying to
>> say that  the lines commented out are not used but previously the fields
>> were all together so being a bit more specific would help those coming later
>> on to look at this code.  Same for line 2025.  Also can you add back the
>> comment that writeCEN writes these fields out with a 0 value as we lost that
>> comment?
> 
> I updated this, please check.

Can we tweak slightly to:

The fields that are commented out below ?...
> 
>> line 1937: can you fix the typo ?tailing" which should be ?trailing? in the
>> comment.
> 
> Done.
+
> 
> Does it look good now? It runs successfully through our regression testing system.
> 
> Thanks and best regards
> Christoph
> 

 <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 adinn at redhat.com  Thu May 16 14:49:40 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 16 May 2019 15:49:40 +0100
Subject: RFR (T): 8224042 Add private alignDown method to MappedByteBuffer
Message-ID: <a1ed09c6-0446-ec8a-1168-ed0bb1cf9b13@redhat.com>

Please review this trivial change to MapperByteBuffer which encapsulates
the page align down operation in a suitably named method.

JIRA:   https://bugs.openjdk.java.net/browse/JDK-8224042
webrev: http://cr.openjdk.java.net/~adinn/8224042/webrev.00/

Testing:
This was successfully exercised by running

  jdk/java/nio/channels/FileChannel/MapTest.java

The test rounds down a sequence of sub-page offsets to successive pages
within a mapped buffer during testing of MappedByteBuffer method force().

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 May 16 14:52:42 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 16 May 2019 15:52:42 +0100
Subject: RFR : 8221696: MappedByteBuffer.force method to specify range
In-Reply-To: <91bdc97a-10c6-7475-c71e-f4a8d5c67dd9@oracle.com>
References: <2c9099f0-d95d-425a-c033-b22ad5c25231@redhat.com>
 <4ad97801-218f-2fa5-e8b5-3f14347c4320@oracle.com>
 <9218d37f-9820-9216-b125-8f3bc2d19e3d@redhat.com>
 <453045f6-0259-e098-8211-0187428adb9f@oracle.com>
 <b6e8c4cd-fa7a-74ae-4881-744883073bbe@redhat.com>
 <40cb2223-6d5a-4262-6293-2f187f578735@redhat.com>
 <4cda30a8-7d86-de1a-2ff9-ae1904563ead@redhat.com>
 <199698dd-a486-61f4-62c6-d99930e164d8@redhat.com>
 <DABFA78D-B493-45DB-9EF9-FFFA06523BC6@oracle.com>
 <4d7b9dc5-ceaa-0df7-bec7-ca39abe9e55a@redhat.com>
 <91bdc97a-10c6-7475-c71e-f4a8d5c67dd9@oracle.com>
Message-ID: <dc14d7a2-1dc4-6875-9920-e4402d61349a@redhat.com>

On 16/05/2019 14:14, Alan Bateman wrote:
> Mikael's suggestion seem okay. This is under the hood implementation so
> doesn't matter if there is a follow-on issue or you include it in the
> bigger patch. It might be easier to do the former while it's fresh in
> our minds.
Indeed. I have raised JDK-8224042, patched and tested the code, uploaded
a webrev and posted an RFR (T) to core-libs-dev. Reviews welcome!

regards,


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

From andy.herrick at oracle.com  Thu May 16 14:59:22 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 16 May 2019 10:59:22 -0400
Subject: Problem with jpackage/Windows and using a different runtime
In-Reply-To: <d70b4b99-71f5-6430-c1c0-45400a456ca5@dataplan.de>
References: <d70b4b99-71f5-6430-c1c0-45400a456ca5@dataplan.de>
Message-ID: <855058aa-bcb6-c119-0c83-447e7402d52d@oracle.com>

Klaus:

My apologies for not getting back to you sooner.

I have tried the (nearly) the exact steps you give and can run the 
resultant app on windows.

My best guess is that it is caused by a problem we have when there are 
spaces in the path given to --runtime-image. (similar to 
https://bugs.openjdk.java.net/browse/JDK-8223953), but so far I have not 
been able to reproduce.

I assume ..\..\OpenJDK12\bin\myruntime resolves to a path including 
'Program Files'/OpenJDK12

For the failing case, can you post the contents of 
MyProject/application/app/application.cfg ?? Usually when a "jpackage 
create-app-image" command succeeds but the app does not run you can see 
the problem in the cfg file.

/Andy



On 5/9/2019 7:50 AM, Klaus Friese wrote:
> Hi,
>
> I downloaded the jpackage EA version from 
> https://jdk.java.net/jpackage/ for some tests and I run into problems 
> when using a different runtime (OpenJDK12) on Windows.
>
> This is my setting:
> OpenJDK12 installed in c:\Program Files\OpenJDK12
> OpenJDK13 with jpackage installed c:\Program Files\OpenJDK13
>
> I created runtimes for both versions with:
>
> ?? jlink --output myruntime
> ??? ??? --module-path ../jmods
> ??? ??? --add-modules ALL-MODULE-PATH
> ??? ??? --bind-services
> ??? ??? --compress=2
> ??? ??? --strip-native-commands
>
> I created the app with
>
> ?? jpackage create-app-image ^
> ??? ??? -o "/MyProject" ^
> ??? ??? -i /MyProject/path/to/my/jars ^
> ??? ??? -n application ^
> ??? ??? --runtime-image ..\..\OpenJDK12\bin\myruntime ^
> ??? ??? --main-class my.application.main.class ^
> ??? ??? --main-jar main.jar
>
> On Windows:
> When using the OpenJDK13 runtime everything is fine.
> When using the OpenJDK12 runtime the app doesn't start and I just get 
> the message "Failed to load JVM"
>
> On MacOS
> OpenJDK12 and OpenJDK13 are working fine.
>
> Is this an error in jpackage or is the error on my side?
>
> Best regards
> dataplan GmbH
> Klaus Friese
> System Engineer Applications
> ------------------------------------------------------------------------
>
>
> *dataplan GmbH*
> Stahltwiete 23
> 22761 Hamburg
>
> Gesch?ftsf?hrer: Dr. Wolfgang Zetsche
> HRB 31 083
> Gerichtsstand: Hamburg
> St. Nr.: DE118540281
>
> Tel: +49 40 398 44 20
> Fax: +49 40 390 26 39
>
> www.dataplan.de <http://www.dataplan.de/>
> www.facebook.de/dataplangmbh <http://www.facebook.de/dataplangmbh>
> www.twitter.com/dataplangmbh <https://twitter.com/dataplangmbh>
> kfriese at dataplan.de <mailto:kmueller at dataplan.de>


From thomas.stuefe at gmail.com  Thu May 16 15:54:46 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 16 May 2019 17:54:46 +0200
Subject: RFR (T): 8224042 Add private alignDown method to MappedByteBuffer
In-Reply-To: <a1ed09c6-0446-ec8a-1168-ed0bb1cf9b13@redhat.com>
References: <a1ed09c6-0446-ec8a-1168-ed0bb1cf9b13@redhat.com>
Message-ID: <CAA-vtUwDLExUyQxbc2vP+ku3-CGpSFekVWG9OehTXko-Y8i5Ug@mail.gmail.com>

Hi Andrew,

looks good and trivial. Method could be static.

Cheers, Thomas

On Thu, May 16, 2019 at 4:49 PM Andrew Dinn <adinn at redhat.com> wrote:

> Please review this trivial change to MapperByteBuffer which encapsulates
> the page align down operation in a suitably named method.
>
> JIRA:   https://bugs.openjdk.java.net/browse/JDK-8224042
> webrev: http://cr.openjdk.java.net/~adinn/8224042/webrev.00/
>
> Testing:
> This was successfully exercised by running
>
>   jdk/java/nio/channels/FileChannel/MapTest.java
>
> The test rounds down a sequence of sub-page offsets to successive pages
> within a mapped buffer during testing of MappedByteBuffer method force().
>
> 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 vicente.romero at oracle.com  Thu May 16 16:19:36 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 16 May 2019 12:19:36 -0400
Subject: RFR: JDK-8223726: j.l.c.MethodTypeDesc spec should contain
 precise assertions for one parameter's methods
In-Reply-To: <cfa9fea6-60f4-a085-0fb6-b18996151c93@oracle.com>
References: <3e9df442-7b1c-cf06-b916-b357af2742e5@oracle.com>
 <cfa9fea6-60f4-a085-0fb6-b18996151c93@oracle.com>
Message-ID: <545f2fa3-edfb-f0e2-1727-c32a3fcd56cd@oracle.com>

Hi Joe,

Yes you are correct, thanks, I have updated the spec for the method plus 
added a couple of tests to make sure that the right exception is being 
thrown [1],

Thanks,
Vicente

[1] http://cr.openjdk.java.net/~vromero/8223726/webrev.01/

On 5/15/19 1:45 PM, Joe Darcy wrote:
> Hi Vicente,
>
> Should
>
> ?180????? * @throws NullPointerException if any argument is {@code null}
> ?181????? */
> ?182???? static DirectMethodHandleDesc ofConstructor(ClassDesc owner,
> ?183???????????????????????????????????????????????? ClassDesc... 
> paramTypes) {
>
> be "any argument or its contents is {@code null}", i.e. if the 
> elements of paramTypes are null, is NPE thrown?
>
> Otherwise, the change looks good.
>
> Thanks,
>
> -Joe
>
> On 5/15/2019 8:36 AM, Vicente Romero wrote:
>> Please review fix for [1] at [2], this is a simple fix that is just 
>> rewording the doc of a couple of methods at 
>> java.lang.constant.MethodTypeDesc,
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223726
>> [2] http://cr.openjdk.java.net/~vromero/8223726/webrev.00/


From adinn at redhat.com  Thu May 16 16:24:28 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 16 May 2019 17:24:28 +0100
Subject: RFR (T): 8224042 Add private alignDown method to MappedByteBuffer
In-Reply-To: <CAA-vtUwDLExUyQxbc2vP+ku3-CGpSFekVWG9OehTXko-Y8i5Ug@mail.gmail.com>
References: <a1ed09c6-0446-ec8a-1168-ed0bb1cf9b13@redhat.com>
 <CAA-vtUwDLExUyQxbc2vP+ku3-CGpSFekVWG9OehTXko-Y8i5Ug@mail.gmail.com>
Message-ID: <e0a83c9e-30f1-8a7b-375a-c0bf97fde00e@redhat.com>

Hi Thomas,

Thanks for the review.

On 16/05/2019 16:54, Thomas St?fe wrote:
> looks good and trivial. Method could be static.

Yes, good point! I will modify accordingly and then push.

regards,


Andrew Dinn
-----------


From mikael.vidstedt at oracle.com  Thu May 16 16:24:50 2019
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 16 May 2019 09:24:50 -0700
Subject: RFR (T): 8224042 Add private alignDown method to MappedByteBuffer
In-Reply-To: <a1ed09c6-0446-ec8a-1168-ed0bb1cf9b13@redhat.com>
References: <a1ed09c6-0446-ec8a-1168-ed0bb1cf9b13@redhat.com>
Message-ID: <59072F33-2F33-4A6D-8D8B-C952B90CDC63@oracle.com>


Looks good, thanks for doing it!

Cheers,
Mikael

> On May 16, 2019, at 7:49 AM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> Please review this trivial change to MapperByteBuffer which encapsulates
> the page align down operation in a suitably named method.
> 
> JIRA:   https://bugs.openjdk.java.net/browse/JDK-8224042
> webrev: http://cr.openjdk.java.net/~adinn/8224042/webrev.00/
> 
> Testing:
> This was successfully exercised by running
> 
>  jdk/java/nio/channels/FileChannel/MapTest.java
> 
> The test rounds down a sequence of sub-page offsets to successive pages
> within a mapped buffer during testing of MappedByteBuffer method force().
> 
> 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  Thu May 16 16:27:10 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 May 2019 17:27:10 +0100
Subject: RFR (T): 8224042 Add private alignDown method to MappedByteBuffer
In-Reply-To: <a1ed09c6-0446-ec8a-1168-ed0bb1cf9b13@redhat.com>
References: <a1ed09c6-0446-ec8a-1168-ed0bb1cf9b13@redhat.com>
Message-ID: <80fecf97-89d9-612f-b935-c5657423642a@oracle.com>

On 16/05/2019 15:49, Andrew Dinn wrote:
> Please review this trivial change to MapperByteBuffer which encapsulates
> the page align down operation in a suitably named method.
>
> JIRA:   https://bugs.openjdk.java.net/browse/JDK-8224042
> webrev: http://cr.openjdk.java.net/~adinn/8224042/webrev.00/
>
Looks okay (private static, as Thomas prefers, is fine too).

-Alan

From adinn at redhat.com  Thu May 16 16:39:10 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 16 May 2019 17:39:10 +0100
Subject: RFR (T): 8224042 Add private alignDown method to MappedByteBuffer
In-Reply-To: <59072F33-2F33-4A6D-8D8B-C952B90CDC63@oracle.com>
References: <a1ed09c6-0446-ec8a-1168-ed0bb1cf9b13@redhat.com>
 <59072F33-2F33-4A6D-8D8B-C952B90CDC63@oracle.com>
Message-ID: <02e86135-8931-91b1-ec7a-7a5933c0288f@redhat.com>

On 16/05/2019 17:24, Mikael Vidstedt wrote:
> 
> Looks good, thanks for doing it!

Thanks for the review Mikael.

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 May 16 16:39:44 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 16 May 2019 17:39:44 +0100
Subject: RFR (T): 8224042 Add private alignDown method to MappedByteBuffer
In-Reply-To: <80fecf97-89d9-612f-b935-c5657423642a@oracle.com>
References: <a1ed09c6-0446-ec8a-1168-ed0bb1cf9b13@redhat.com>
 <80fecf97-89d9-612f-b935-c5657423642a@oracle.com>
Message-ID: <c8d9ecd6-2ecd-5897-4326-ec7ec58f2c29@redhat.com>

On 16/05/2019 17:27, Alan Bateman wrote:
> On 16/05/2019 15:49, Andrew Dinn wrote:
>> Please review this trivial change to MapperByteBuffer which encapsulates
>> the page align down operation in a suitably named method.
>>
>> JIRA:?? https://bugs.openjdk.java.net/browse/JDK-8224042
>> webrev: http://cr.openjdk.java.net/~adinn/8224042/webrev.00/
>>
> Looks okay (private static, as Thomas prefers, is fine too).
Thank you for the review, Alan.

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 joe.darcy at oracle.com  Thu May 16 16:41:45 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 16 May 2019 09:41:45 -0700
Subject: RFR: JDK-8223726: j.l.c.MethodTypeDesc spec should contain
 precise assertions for one parameter's methods
In-Reply-To: <545f2fa3-edfb-f0e2-1727-c32a3fcd56cd@oracle.com>
References: <3e9df442-7b1c-cf06-b916-b357af2742e5@oracle.com>
 <cfa9fea6-60f4-a085-0fb6-b18996151c93@oracle.com>
 <545f2fa3-edfb-f0e2-1727-c32a3fcd56cd@oracle.com>
Message-ID: <f81970bf-8833-1cb4-d1ca-1aea8c78784e@oracle.com>

Hi Vicente,

As the spec now includes a very small change to cover the array 
contents, please update the CSR and I'll quickly approve it.

Thanks,

-Joe

On 5/16/2019 9:19 AM, Vicente Romero wrote:
> Hi Joe,
>
> Yes you are correct, thanks, I have updated the spec for the method 
> plus added a couple of tests to make sure that the right exception is 
> being thrown [1],
>
> Thanks,
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8223726/webrev.01/
>
> On 5/15/19 1:45 PM, Joe Darcy wrote:
>> Hi Vicente,
>>
>> Should
>>
>> ?180????? * @throws NullPointerException if any argument is {@code null}
>> ?181????? */
>> ?182???? static DirectMethodHandleDesc ofConstructor(ClassDesc owner,
>> ?183 ClassDesc... paramTypes) {
>>
>> be "any argument or its contents is {@code null}", i.e. if the 
>> elements of paramTypes are null, is NPE thrown?
>>
>> Otherwise, the change looks good.
>>
>> Thanks,
>>
>> -Joe
>>
>> On 5/15/2019 8:36 AM, Vicente Romero wrote:
>>> Please review fix for [1] at [2], this is a simple fix that is just 
>>> rewording the doc of a couple of methods at 
>>> java.lang.constant.MethodTypeDesc,
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8223726
>>> [2] http://cr.openjdk.java.net/~vromero/8223726/webrev.00/
>

From vicente.romero at oracle.com  Thu May 16 16:57:23 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 16 May 2019 12:57:23 -0400
Subject: RFR: JDK-8223726: j.l.c.MethodTypeDesc spec should contain
 precise assertions for one parameter's methods
In-Reply-To: <f81970bf-8833-1cb4-d1ca-1aea8c78784e@oracle.com>
References: <3e9df442-7b1c-cf06-b916-b357af2742e5@oracle.com>
 <cfa9fea6-60f4-a085-0fb6-b18996151c93@oracle.com>
 <545f2fa3-edfb-f0e2-1727-c32a3fcd56cd@oracle.com>
 <f81970bf-8833-1cb4-d1ca-1aea8c78784e@oracle.com>
Message-ID: <374ddec1-5d2d-45ce-07f8-88d6cfdbcd4c@oracle.com>

done, I have restricted the scope of the CSR to method 
`j.l.c.MethodTypeDesc::ofConstructor` only which is the one for which 
the doc change is more important,

Thanks,
Vicente

On 5/16/19 12:41 PM, Joe Darcy wrote:
> Hi Vicente,
>
> As the spec now includes a very small change to cover the array 
> contents, please update the CSR and I'll quickly approve it.
>
> Thanks,
>
> -Joe
>
> On 5/16/2019 9:19 AM, Vicente Romero wrote:
>> Hi Joe,
>>
>> Yes you are correct, thanks, I have updated the spec for the method 
>> plus added a couple of tests to make sure that the right exception is 
>> being thrown [1],
>>
>> Thanks,
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8223726/webrev.01/
>>
>> On 5/15/19 1:45 PM, Joe Darcy wrote:
>>> Hi Vicente,
>>>
>>> Should
>>>
>>> ?180????? * @throws NullPointerException if any argument is {@code 
>>> null}
>>> ?181????? */
>>> ?182???? static DirectMethodHandleDesc ofConstructor(ClassDesc owner,
>>> ?183 ClassDesc... paramTypes) {
>>>
>>> be "any argument or its contents is {@code null}", i.e. if the 
>>> elements of paramTypes are null, is NPE thrown?
>>>
>>> Otherwise, the change looks good.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 5/15/2019 8:36 AM, Vicente Romero wrote:
>>>> Please review fix for [1] at [2], this is a simple fix that is just 
>>>> rewording the doc of a couple of methods at 
>>>> java.lang.constant.MethodTypeDesc,
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8223726
>>>> [2] http://cr.openjdk.java.net/~vromero/8223726/webrev.00/
>>


From philip.race at oracle.com  Thu May 16 19:30:06 2019
From: philip.race at oracle.com (Phil Race)
Date: Thu, 16 May 2019 12:30:06 -0700
Subject: RFR: 8223804: [macos] remove obsoleted reference to security
 framework in launcher code
Message-ID: <7f3f85b2-b2ae-6fec-2a9f-300573524213@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8223804
Webrev: http://cr.openjdk.java.net/~prr/8223804/

This is a small cleanup fix.
When doing a previous launcher fix : 
https://bugs.openjdk.java.net/browse/JDK-8222819
I failed to check if the removal there meant there were now unused 
imports in the
affected source file. There was one. And it seems there is also no 
longer a need to link
against the Security framework either.

-phil.

From Roger.Riggs at oracle.com  Thu May 16 19:33:51 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 16 May 2019 15:33:51 -0400
Subject: RFR: 8223804: [macos] remove obsoleted reference to security
 framework in launcher code
In-Reply-To: <7f3f85b2-b2ae-6fec-2a9f-300573524213@oracle.com>
References: <7f3f85b2-b2ae-6fec-2a9f-300573524213@oracle.com>
Message-ID: <735a671e-3759-e24f-5ebb-dd43a3075311@oracle.com>

Hi Phil,

Looks fine.

Roger


On 05/16/2019 03:30 PM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223804
> Webrev: http://cr.openjdk.java.net/~prr/8223804/
>
> This is a small cleanup fix.
> When doing a previous launcher fix : 
> https://bugs.openjdk.java.net/browse/JDK-8222819
> I failed to check if the removal there meant there were now unused 
> imports in the
> affected source file. There was one. And it seems there is also no 
> longer a need to link
> against the Security framework either.
>
> -phil.


From erik.joelsson at oracle.com  Thu May 16 19:45:33 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 16 May 2019 12:45:33 -0700
Subject: RFR: 8223804: [macos] remove obsoleted reference to security
 framework in launcher code
In-Reply-To: <7f3f85b2-b2ae-6fec-2a9f-300573524213@oracle.com>
References: <7f3f85b2-b2ae-6fec-2a9f-300573524213@oracle.com>
Message-ID: <b267f214-d088-b2ad-9222-5af9369e0903@oracle.com>

Looks good.

/Erik

On 2019-05-16 12:30, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223804
> Webrev: http://cr.openjdk.java.net/~prr/8223804/
>
> This is a small cleanup fix.
> When doing a previous launcher fix : 
> https://bugs.openjdk.java.net/browse/JDK-8222819
> I failed to check if the removal there meant there were now unused 
> imports in the
> affected source file. There was one. And it seems there is also no 
> longer a need to link
> against the Security framework either.
>
> -phil.

From vicente.romero at oracle.com  Thu May 16 19:58:02 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 16 May 2019 15:58:02 -0400
Subject: =?UTF-8?Q?Re=3a_RFR=3a_JDK-8223803=3a_j=2el=2ec=2eMethodTypeDesc=3a?=
 =?UTF-8?Q?=3ainsertParameterTypes=e2=80=8b_doesn=27t_control_type_of_parame?=
 =?UTF-8?Q?ters?=
In-Reply-To: <7f26e3c2-f28b-eef0-3ed9-538e1b43e529@oracle.com>
References: <7f26e3c2-f28b-eef0-3ed9-538e1b43e529@oracle.com>
Message-ID: <12586683-ac11-cfdc-6a5f-46f5167d390f@oracle.com>

ping

On 5/15/19 5:27 PM, Vicente Romero wrote:
> Please review fix for [1] at [2] and the related CSR at [3]. Method 
> java.lang.constant.MethodTypeDesc::insertParameterTypes? should 
> control the type of parameters being inserted. In particular, no 
> parameter can be a class descriptor of primitive type |void|. This fix 
> is updating the spec of the mentioned method plus it is adding a test 
> to make sure that the implementation is in sync with the 
> specification. As mentioned in the CSR and apiNote has been added to 
> method j.l.c.ConstantDesc::resolveConstantDesc to clarify that a 
> method type descriptor can have more than 255 argument slots so at 
> resolution time, as a j.l.i.MethodType, errors can be thrown.
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223803
> [2] http://cr.openjdk.java.net/~vromero/8223803/webrev.00/
> [3] https://bugs.openjdk.java.net/browse/JDK-8223997


From Roger.Riggs at oracle.com  Thu May 16 21:15:48 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 16 May 2019 17:15:48 -0400
Subject: =?UTF-8?Q?Re:_RFR:_JDK-8223803:_j.l.c.MethodTypeDesc::insertParamet?=
 =?UTF-8?Q?erTypes=e2=80=8b_doesn't_control_type_of_parameters?=
In-Reply-To: <7f26e3c2-f28b-eef0-3ed9-538e1b43e529@oracle.com>
References: <7f26e3c2-f28b-eef0-3ed9-538e1b43e529@oracle.com>
Message-ID: <c6c89d7f-20dc-44c9-0709-584976f21ffd@oracle.com>

Hi Vicente,

Looks ok.
And the CSR too.

Please re-wrap the lines to 80 chars to make diffs easier to read.
ConstantDesc.java and MethodTypeDesc.java

Thanks, Roger

On 05/15/2019 05:27 PM, Vicente Romero wrote:
> Please review fix for [1] at [2] and the related CSR at [3]. Method 
> java.lang.constant.MethodTypeDesc::insertParameterTypes? should 
> control the type of parameters being inserted. In particular, no 
> parameter can be a class descriptor of primitive type |void|. This fix 
> is updating the spec of the mentioned method plus it is adding a test 
> to make sure that the implementation is in sync with the 
> specification. As mentioned in the CSR and apiNote has been added to 
> method j.l.c.ConstantDesc::resolveConstantDesc to clarify that a 
> method type descriptor can have more than 255 argument slots so at 
> resolution time, as a j.l.i.MethodType, errors can be thrown.
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223803
> [2] http://cr.openjdk.java.net/~vromero/8223803/webrev.00/
> [3] https://bugs.openjdk.java.net/browse/JDK-8223997


From martinrb at google.com  Thu May 16 21:58:38 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 16 May 2019 14:58:38 -0700
Subject: RFR: jsr166 integration 2019-06
Message-ID: <CA+kOe09_4jniMDStZoBztpfF1bU2WDBP+hLo0eE-N6=LN9SdJg@mail.gmail.com>

https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html

Just another test timeout tweak:
8224024: java/util/concurrent/BlockingQueue/DrainToFails.java testBounded
fails intermittently
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/DrainToFails/index.html
https://bugs.openjdk.java.net/browse/JDK-8224024

8220478: java/util/concurrent/ConcurrentHashMap/ToArray.java timed out
intermittently
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/forkjoin/index.html
8223379: Clarify ForkJoinPool.getStealCount() javadoc
https://bugs.openjdk.java.net/browse/JDK-8220478

8223245: Miscellaneous changes imported from jsr166 CVS 2019-06
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html
https://bugs.openjdk.java.net/browse/JDK-8223245

From stuart.marks at oracle.com  Thu May 16 22:09:21 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 16 May 2019 15:09:21 -0700
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <CA+kOe0_9rORGxNEqss+i2ek8Vgcx9cEXxvh8g=4O4K71xt_yuw@mail.gmail.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <CA+kOe0_9rORGxNEqss+i2ek8Vgcx9cEXxvh8g=4O4K71xt_yuw@mail.gmail.com>
Message-ID: <e142a03f-0379-0643-cd2d-56d3dc2e2938@oracle.com>



On 5/14/19 9:16 PM, Martin Buchholz wrote:
>> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java

Regarding the change in this particular file, I'd suggest the following:


diff -r 006dadb903ab -r 92e1fdce45e0 
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
--- 
a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
Mon May 13 17:15:56 2019 -0700
+++ 
b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
Thu May 16 15:04:30 2019 -0700
@@ -1712,9 +1712,7 @@
          Map<?,?> m = (Map<?,?>) o;
          try {
              Comparator<? super K> cmp = comparator;
-            @SuppressWarnings("unchecked")
-            Iterator<Map.Entry<?,?>> it =
-                (Iterator<Map.Entry<?,?>>)m.entrySet().iterator();
+            Iterator<? extends Map.Entry<?,?>> it = m.entrySet().iterator();
              if (m instanceof SortedMap &&
                  ((SortedMap<?,?>)m).comparator() == cmp) {
                  Node<K,V> b, n;



I have no idea if it will be accepted by the Eclipse IDE, but this seems like a 
cleaner change to me than introducing a raw type.

***

Christoph,

On the general issue of compilation differences between javac and the Eclipse 
IDE, have you raised a bug with them?

s'marks

From vicente.romero at oracle.com  Thu May 16 22:39:37 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 16 May 2019 18:39:37 -0400
Subject: =?UTF-8?Q?Re=3a_RFR=3a_JDK-8223803=3a_j=2el=2ec=2eMethodTypeDesc=3a?=
 =?UTF-8?Q?=3ainsertParameterTypes=e2=80=8b_doesn=27t_control_type_of_parame?=
 =?UTF-8?Q?ters?=
In-Reply-To: <c6c89d7f-20dc-44c9-0709-584976f21ffd@oracle.com>
References: <7f26e3c2-f28b-eef0-3ed9-538e1b43e529@oracle.com>
 <c6c89d7f-20dc-44c9-0709-584976f21ffd@oracle.com>
Message-ID: <5ffeffaa-1621-3ce3-dd7c-79e873f5ba44@oracle.com>

Hi Roger,

Thanks for the review, I will do the re-wrapping before pushing,

Thanks,
Vicente

On 5/16/19 5:15 PM, Roger Riggs wrote:
> Hi Vicente,
>
> Looks ok.
> And the CSR too.
>
> Please re-wrap the lines to 80 chars to make diffs easier to read.
> ConstantDesc.java and MethodTypeDesc.java
>
> Thanks, Roger
>
> On 05/15/2019 05:27 PM, Vicente Romero wrote:
>> Please review fix for [1] at [2] and the related CSR at [3]. Method 
>> java.lang.constant.MethodTypeDesc::insertParameterTypes? should 
>> control the type of parameters being inserted. In particular, no 
>> parameter can be a class descriptor of primitive type |void|. This 
>> fix is updating the spec of the mentioned method plus it is adding a 
>> test to make sure that the implementation is in sync with the 
>> specification. As mentioned in the CSR and apiNote has been added to 
>> method j.l.c.ConstantDesc::resolveConstantDesc to clarify that a 
>> method type descriptor can have more than 255 argument slots so at 
>> resolution time, as a j.l.i.MethodType, errors can be thrown.
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223803
>> [2] http://cr.openjdk.java.net/~vromero/8223803/webrev.00/
>> [3] https://bugs.openjdk.java.net/browse/JDK-8223997
>


From vicente.romero at oracle.com  Thu May 16 22:52:20 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 16 May 2019 18:52:20 -0400
Subject: =?UTF-8?Q?Re=3a_RFR=3a_JDK-8223723=3a_j=2el=2ec=2eMethodTypeDesc=2e?=
 =?UTF-8?Q?dropParameterTypes=e2=80=8b_throws_the_undocumented_exception=3a_?=
 =?UTF-8?Q?IllegalArgumentException?=
In-Reply-To: <b3a7137f-3c4f-d303-7508-9f8366820cb6@oracle.com>
References: <b3a7137f-3c4f-d303-7508-9f8366820cb6@oracle.com>
Message-ID: <23e6c6fa-d18a-bef0-3af2-23c785ce1d0d@oracle.com>

Hi,

I still need a reviewer for this simple patch and CSR,

TIA,
Vicente

On 5/14/19 4:53 PM, Vicente Romero wrote:
> Please review fix for [1] at [2]. The implementation of method 
> java.lang.constant.MethodTypeDesc::dropParameterTypes was throwing a 
> non specified exception. The proposed fix is synchronizing the 
> implementation with the specification. Please also review the CSR at 
> [3]. Check the problem section in the CSR for more details,
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223723
> [2] http://cr.openjdk.java.net/~vromero/8223767/webrev.00/
> [3] https://bugs.openjdk.java.net/browse/JDK-8223918


From martinrb at google.com  Fri May 17 02:32:37 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 16 May 2019 19:32:37 -0700
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <e142a03f-0379-0643-cd2d-56d3dc2e2938@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <CA+kOe0_9rORGxNEqss+i2ek8Vgcx9cEXxvh8g=4O4K71xt_yuw@mail.gmail.com>
 <e142a03f-0379-0643-cd2d-56d3dc2e2938@oracle.com>
Message-ID: <CA+kOe08JHUyrDXbc7rKFcU8EEix5y39nQb4LNwtW0OxuGDtWXw@mail.gmail.com>

Stuart's cool type system hack is hard for me to grok, but it seems alright
to put into ConcurrentSkipListMap.java.  We could add it to the current
jsr166 integration.


*From: *Stuart Marks <stuart.marks at oracle.com>
*Date: *Thu, May 16, 2019 at 3:11 PM
*To: *Martin Buchholz, David Holmes, Doug Lea, Langer, Christoph
*Cc: *compiler-dev at openjdk.java.net, core-libs-dev, net-dev

On 5/14/19 9:16 PM, Martin Buchholz wrote:
> >>
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
>
> Regarding the change in this particular file, I'd suggest the following:
>
>
> diff -r 006dadb903ab -r 92e1fdce45e0
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
> ---
> a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
>
> Mon May 13 17:15:56 2019 -0700
> +++
> b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
>
> Thu May 16 15:04:30 2019 -0700
> @@ -1712,9 +1712,7 @@
>           Map<?,?> m = (Map<?,?>) o;
>           try {
>               Comparator<? super K> cmp = comparator;
> -            @SuppressWarnings("unchecked")
> -            Iterator<Map.Entry<?,?>> it =
> -                (Iterator<Map.Entry<?,?>>)m.entrySet().iterator();
> +            Iterator<? extends Map.Entry<?,?>> it =
> m.entrySet().iterator();
>               if (m instanceof SortedMap &&
>                   ((SortedMap<?,?>)m).comparator() == cmp) {
>                   Node<K,V> b, n;
>
>
>
> I have no idea if it will be accepted by the Eclipse IDE, but this seems
> like a
> cleaner change to me than introducing a raw type.
>
> ***
>
> Christoph,
>
> On the general issue of compilation differences between javac and the
> Eclipse
> IDE, have you raised a bug with them?
>
> s'marks
>

From stuart.marks at oracle.com  Fri May 17 03:42:35 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 16 May 2019 20:42:35 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>
Message-ID: <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com>

Hi Alan,

Whether you call them "ersatz" collections, "non-standard" collections, or 
collections with different membership semantics, they have been around in the 
collections framework from day one. This is perhaps unfortunate, and it may be 
considered to be bad design, but it is a fact.

The issue is not with undefined or implementation-specific behavior. The issue 
is that the specification as it stands is self-contradictory. In particular, it 
assumes that certain operations are symmetric that in fact are not, if you read 
other parts of the spec and derive logical conclusions from them. This is what 
I'm trying to fix. This is not a mere a matter of intellectual consistency. This 
state of affairs has real consequences. There is a whole family of bugs linked 
to this one which complain both about the performance issue and the semantic 
issue. All of these bugs are directly related to the self-contradictory nature 
of the current specification. With my changes, the spec is self-contradictory in 
fewer places. (There is, however, more work to be done; see JDK-8190545.)

Your lead point, though, is about performance. The performance optimization of 
AbstractSet.removeAll is one of those that assumes that the operation is 
symmetric, when in fact it isn't. As a rule, optimizations mustn't change 
semantics. Therefore, it has to go.

s'marks


From li.jiang at oracle.com  Fri May 17 04:04:29 2019
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Fri, 17 May 2019 12:04:29 +0800
Subject: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT
 provider
Message-ID: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com>

Hi all,

Please review the change to update the l10n names for Japanese era Reiwa 
in JDK COMPAT provider. The l10n names come from the CLDR 35.1, please 
refer this unicode chart[1] for l10n definitions.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8218781
Webrev:
http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/

In this change,
  - update the l10n names if they are defined in CLDR 35.1.
  - update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW 
style respectively.
  - In FormatData_th.java, the localized single character was used for 
previous eras. But we don't find the corresponding name in CLDR 35.1. 
Update it to 'R' according to CLDR 35.1.

[1] 
https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html


Thanks,
Leo

From javalists at cbfiddle.com  Fri May 17 05:06:43 2019
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 16 May 2019 22:06:43 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>
 <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com>
Message-ID: <C8F82E77-C1A6-4A7D-A984-8F2B32883620@cbfiddle.com>

Hi Stuart,

I believe I already accepted the fact of ersatz Collections.

Could you explain the inconsistency in the specification that affects removeAll()? I don?t see it.

In the current specification, the classes that can create ersatz Collections all call out the ersatz Collections in their documentation.

SortedSet:
Note that the ordering maintained by a sorted set (whether or not an
explicit comparator is provided) must be <i>consistent with equals</i> if
the sorted set is to correctly implement the {@code Set} interface.
The behavior of a sorted set <i>is</i> well-defined even if its
ordering is inconsistent with equals; it just fails to obey the general
contract of the {@code Set} interface.

TreeSet is similar

IdentityHashMap:

This class is <i>not</i> a general-purpose {@code Map} implementation!  While this class implements the {@code Map} interface, it
intentionally violates {@code Map's} general contract, which mandates the
use of the {@code equals} method when comparing objects.

IdentityHashMap.keySet:

While the object returned by this method implements the
{@code Set} interface, it does <i>not</i> obey {@code Set's} general
contract.  Like its backing map, the set returned by this method
defines element equality as reference-equality rather than
object-equality.  This affects the behavior of its {@code contains},
{@code remove}, {@code containsAll}, {@code equals}, and
{@code hashCode} methods.

The logical implication of not supporting the general contract is that Collection operations performed on an ersatz Collection may have
unexpected (implementation specific) effects, which implies that passing one of these ersatz Collections to a parameter of a Collection
type may have unexpected (implementation specific) effects.

In other words, whether removeAll is performed on an ersatz Collection or the parameter is an ersatz Collection, the effects may be
implementation specific and inconsistent with the specification of removeAll.

That is not to say that improving the design would not have benefit, of course it does. The bug reports you cite prove that.
However, the compatibility impact of the change needs to be taken into account.

  Alan



> On May 16, 2019, at 8:42 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi Alan,
> 
> Whether you call them "ersatz" collections, "non-standard" collections, or collections with different membership semantics, they have been around in the collections framework from day one. This is perhaps unfortunate, and it may be considered to be bad design, but it is a fact.
> 
> The issue is not with undefined or implementation-specific behavior. The issue is that the specification as it stands is self-contradictory. In particular, it assumes that certain operations are symmetric that in fact are not, if you read other parts of the spec and derive logical conclusions from them. This is what I'm trying to fix. This is not a mere a matter of intellectual consistency. This state of affairs has real consequences. There is a whole family of bugs linked to this one which complain both about the performance issue and the semantic issue. All of these bugs are directly related to the self-contradictory nature of the current specification. With my changes, the spec is self-contradictory in fewer places. (There is, however, more work to be done; see JDK-8190545.)
> 
> Your lead point, though, is about performance. The performance optimization of AbstractSet.removeAll is one of those that assumes that the operation is symmetric, when in fact it isn't. As a rule, optimizations mustn't change semantics. Therefore, it has to go.
> 
> s'marks
> 


From peter.levart at gmail.com  Fri May 17 06:48:34 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 17 May 2019 08:48:34 +0200
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <C8F82E77-C1A6-4A7D-A984-8F2B32883620@cbfiddle.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>
 <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com>
 <C8F82E77-C1A6-4A7D-A984-8F2B32883620@cbfiddle.com>
Message-ID: <ef9cde9c-909b-9387-3165-58e62a6bdbcc@gmail.com>

Hi Alan,

I can sympathize with the performance loss aspect of this patch, but I 
nevertheless think it is a move in the right direction. You must admit 
that the performance optimization of AbstractSet.removeAll was a rather 
shaky one (dependent on the relative sizes of the two collections) and 
as such very prone to sudden performance spikes that could occur for 
seemingly unknown reason. More importantly, the fact that the semantics 
of the method could change drastically dependent on such thing as 
relative sizes of the two collections was inexplicable. You may argue 
that the semantics of the method is undefined if called upon or passed 
an ersatz Collection instance, but even the undefined semantics may be 
consistent? - i.e. independent of such things as relative sizes of both 
collections.

It would be a perfect world if this optimization was not there to begin 
with. People would eventually find bottlenecks using this method and 
change their code to use explicit iteration or such. There may be 
perfectly valid code out there that uses conformant collection 
implementations that don't cause AbstractSet.removeAll to behave 
inconsistently and such code after this patch may perform badly. But it 
will perform consistently for cases that use ersatz Collections and that 
is more important in my opinion.

As Stuart says, optimizations mustn't change semantics. So is there a 
possibly narrower optimization, that doesn't change the semantics?

Here's a sketch of one:
- create a marker interface (could be JDK-internal) and mark all 
conforming Set implementations with it
- use AbstractSet.removeAll optimization only when both collections 
implement the marker interface


Regards, Peter

On 5/17/19 7:06 AM, Alan Snyder wrote:
> Hi Stuart,
>
> I believe I already accepted the fact of ersatz Collections.
>
> Could you explain the inconsistency in the specification that affects removeAll()? I don?t see it.
>
> In the current specification, the classes that can create ersatz Collections all call out the ersatz Collections in their documentation.
>
> SortedSet:
> Note that the ordering maintained by a sorted set (whether or not an
> explicit comparator is provided) must be <i>consistent with equals</i> if
> the sorted set is to correctly implement the {@code Set} interface.
> The behavior of a sorted set <i>is</i> well-defined even if its
> ordering is inconsistent with equals; it just fails to obey the general
> contract of the {@code Set} interface.
>
> TreeSet is similar
>
> IdentityHashMap:
>
> This class is <i>not</i> a general-purpose {@code Map} implementation!  While this class implements the {@code Map} interface, it
> intentionally violates {@code Map's} general contract, which mandates the
> use of the {@code equals} method when comparing objects.
>
> IdentityHashMap.keySet:
>
> While the object returned by this method implements the
> {@code Set} interface, it does <i>not</i> obey {@code Set's} general
> contract.  Like its backing map, the set returned by this method
> defines element equality as reference-equality rather than
> object-equality.  This affects the behavior of its {@code contains},
> {@code remove}, {@code containsAll}, {@code equals}, and
> {@code hashCode} methods.
>
> The logical implication of not supporting the general contract is that Collection operations performed on an ersatz Collection may have
> unexpected (implementation specific) effects, which implies that passing one of these ersatz Collections to a parameter of a Collection
> type may have unexpected (implementation specific) effects.
>
> In other words, whether removeAll is performed on an ersatz Collection or the parameter is an ersatz Collection, the effects may be
> implementation specific and inconsistent with the specification of removeAll.
>
> That is not to say that improving the design would not have benefit, of course it does. The bug reports you cite prove that.
> However, the compatibility impact of the change needs to be taken into account.
>
>    Alan
>
>
>
>> On May 16, 2019, at 8:42 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>
>> Hi Alan,
>>
>> Whether you call them "ersatz" collections, "non-standard" collections, or collections with different membership semantics, they have been around in the collections framework from day one. This is perhaps unfortunate, and it may be considered to be bad design, but it is a fact.
>>
>> The issue is not with undefined or implementation-specific behavior. The issue is that the specification as it stands is self-contradictory. In particular, it assumes that certain operations are symmetric that in fact are not, if you read other parts of the spec and derive logical conclusions from them. This is what I'm trying to fix. This is not a mere a matter of intellectual consistency. This state of affairs has real consequences. There is a whole family of bugs linked to this one which complain both about the performance issue and the semantic issue. All of these bugs are directly related to the self-contradictory nature of the current specification. With my changes, the spec is self-contradictory in fewer places. (There is, however, more work to be done; see JDK-8190545.)
>>
>> Your lead point, though, is about performance. The performance optimization of AbstractSet.removeAll is one of those that assumes that the operation is symmetric, when in fact it isn't. As a rule, optimizations mustn't change semantics. Therefore, it has to go.
>>
>> s'marks
>>


From christoph.langer at sap.com  Fri May 17 08:58:57 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 17 May 2019 08:58:57 +0000
Subject: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for
 JDK-8213031
In-Reply-To: <56562D6E-AFAA-4BE3-B0AD-04A2B106BA82@oracle.com>
References: <HE1PR0201MB226656E770657D840E1FEF228A2F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <AM6PR02MB51929210FF0E3A73571569138A3E0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB519262684DA223A733C7D41B8A3A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192C231B13810C8EF1F3E708A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <8CD9547E-D56E-440F-8DCD-020E26B959D5@oracle.com>
 <AM6PR02MB5192FD0666B75972ADE952458A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <6FCBB899-0E26-461A-A4C9-440D90090FA7@oracle.com>
 <AM6PR02MB5192D24B64BA5CAA0BEA57E48A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <56562D6E-AFAA-4BE3-B0AD-04A2B106BA82@oracle.com>
Message-ID: <AM6PR02MB5192F4F54B62DAFE90EEDAB18A0B0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Thank you Lance. I pushed it with your suggestion worked in.

From: Lance Andersen <lance.andersen at oracle.com>
Sent: Donnerstag, 16. Mai 2019 15:44
To: Langer, Christoph <christoph.langer at sap.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; nio-dev <nio-dev at openjdk.java.net>; Alan Bateman <Alan.Bateman at oracle.com>
Subject: Re: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031

Hi Christoph,

Thank you for the update.

Looks good.  One minor suggestion below that  you can take care of before you push without a new webrev.

Best,
Lance
On May 15, 2019, at 9:25 AM, Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:

Hi Lance,

thanks for the quick turnaround. I tried to address your findings. Please find the new webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8222276.3/


o FindEND()
? I know that endsub and comlen fields are not currently used by Zip FS but
given they are valid fields in the header we should probably add a comment
that they are not currently used which is why they are commented out?

there is a comment in line 1850 where the members of class END are
declared. Shouldn't that suffice?

Personally, I would add a comment about the unused members in the
method to make it easier?.

Ok, I've added comments.

+1


o line 2061 version(boolean)
? Could you add a comment to describe the method as the changes could be
confusing to someone looking at this code for the 1st time

addressed in v2, please check

Definitely better but is still a bit confusing as it says stored =10 and
zip64=stored (and the value is 45 ;-) ), can we tweak it a bit more

Check it now ??

Looks good



? lines 2362 and 2462 are commented out but were not previously. Can you
clarify why?

the variables "pos" and "locPos" aren't used thereafter, so no need to
increment them at these places. Maybe I should delete the lines altogether?

OK, looking at this again (with extra coffee ;-) ) it makes sense and I would
delete the lines.  They are a leftover cut & paste code I suspect

Deleted.

:-)



Can we move makeParentDirs() closer to buildNodeTree(), perhaps the
same for removeFromTree()?

Done.
+1



Can the comment on line 1850 be worded better?  I know you are trying to
say that  the lines commented out are not used but previously the fields
were all together so being a bit more specific would help those coming later
on to look at this code.  Same for line 2025.  Also can you add back the
comment that writeCEN writes these fields out with a 0 value as we lost that
comment?

I updated this, please check.

Can we tweak slightly to:

The fields that are commented out below ?...



line 1937: can you fix the typo ?tailing" which should be ?trailing? in the
comment.

Done.
+


Does it look good now? It runs successfully through our regression testing system.

Thanks and best regards
Christoph

[cid:image001.gif at 01D50C9F.854199E0]<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 deepak.kejriwal at oracle.com  Fri May 17 09:49:57 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Fri, 17 May 2019 02:49:57 -0700 (PDT)
Subject: [13] RFR: 8214565 and 8214563: Use {@systemProperty} for definitions
 of system properties
Message-ID: <a247ca74-b991-4b6a-8c8a-fb9885cd6502@default>

Hi all,

 

Please review the fix for following issues:-

 

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

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

 

Below is the webrev for above issues:

 

http://cr.openjdk.java.net/~dkejriwal/8214565_8214563/webrev.00/

 

Regards,

Deepak

 

From Alan.Bateman at oracle.com  Fri May 17 10:49:41 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 May 2019 11:49:41 +0100
Subject: [13] RFR: 8214565 and 8214563: Use {@systemProperty} for
 definitions of system properties
In-Reply-To: <a247ca74-b991-4b6a-8c8a-fb9885cd6502@default>
References: <a247ca74-b991-4b6a-8c8a-fb9885cd6502@default>
Message-ID: <7537dd9f-6392-1936-3e55-41cf8936bf48@oracle.com>

On 17/05/2019 10:49, Deepak Kejriwal wrote:
> Hi all,
>
>   
>
> Please review the fix for following issues:-
>
>   
>
> https://bugs.openjdk.java.net/browse/JDK-8214565
>
> https://bugs.openjdk.java.net/browse/JDK-8214563
>
>   
>
> Below is the webrev for above issues:
>
>   
>
> http://cr.openjdk.java.net/~dkejriwal/8214565_8214563/webrev.00/
>
This looks okay to me.

-Alan

From fujie at loongson.cn  Fri May 17 14:25:38 2019
From: fujie at loongson.cn (Jie Fu)
Date: Fri, 17 May 2019 22:25:38 +0800
Subject: RFR: 8224112: [TESTBUG]
 java/util/Base64/TestEncodingDecodingLength.java should be skipped with
 insufficient memory
Message-ID: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>

Hi all,

JBS:    https://bugs.openjdk.java.net/browse/JDK-8224112
Webrev: http://cr.openjdk.java.net/~jiefu/8224112/webrev.00/

java/util/Base64/TestEncodingDecodingLength.java may fail due to 
insufficient memory when our test machine is busy.
It might be better to skip it when the available memory is insufficient.
Could you please review it and give me some advice?

Thanks a lot.
Best regards,
Jie



From shade at redhat.com  Fri May 17 14:30:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 17 May 2019 16:30:37 +0200
Subject: RFR: 8224112: [TESTBUG]
 java/util/Base64/TestEncodingDecodingLength.java should be skipped with
 insufficient memory
In-Reply-To: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
References: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
Message-ID: <602a4ed6-a9aa-c9ba-ce91-75f7f584e33b@redhat.com>

On 5/17/19 4:25 PM, Jie Fu wrote:
> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8224112
> Webrev: http://cr.openjdk.java.net/~jiefu/8224112/webrev.00/
> 
> java/util/Base64/TestEncodingDecodingLength.java may fail due to insufficient memory when our test
> machine is busy.
> It might be better to skip it when the available memory is insufficient.
> Could you please review it and give me some advice?

I am against special casing like that: it may give you the false sense of passing the test when it
is actually broken. In other words, having the infrastructure-induced test failure is better than
having the test that allows bugs to creep in. Get more memory on a test machine, and maybe lobby for
jtreg to unhoard some [1].

Thanks,
-Aleksey

[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902454


From fujie at loongson.cn  Fri May 17 14:55:08 2019
From: fujie at loongson.cn (Jie Fu)
Date: Fri, 17 May 2019 22:55:08 +0800
Subject: RFR: 8224112: [TESTBUG]
 java/util/Base64/TestEncodingDecodingLength.java should be skipped with
 insufficient memory
In-Reply-To: <602a4ed6-a9aa-c9ba-ce91-75f7f584e33b@redhat.com>
References: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
 <602a4ed6-a9aa-c9ba-ce91-75f7f584e33b@redhat.com>
Message-ID: <b788a1fd-ed52-293a-6fbe-53642bb2c465@loongson.cn>

Okay.

Thank you Aleksey.

On 2019?05?17? 22:30, Aleksey Shipilev wrote:
> On 5/17/19 4:25 PM, Jie Fu wrote:
>> JBS:    https://bugs.openjdk.java.net/browse/JDK-8224112
>> Webrev: http://cr.openjdk.java.net/~jiefu/8224112/webrev.00/
>>
>> java/util/Base64/TestEncodingDecodingLength.java may fail due to insufficient memory when our test
>> machine is busy.
>> It might be better to skip it when the available memory is insufficient.
>> Could you please review it and give me some advice?
> I am against special casing like that: it may give you the false sense of passing the test when it
> is actually broken. In other words, having the infrastructure-induced test failure is better than
> having the test that allows bugs to creep in. Get more memory on a test machine, and maybe lobby for
> jtreg to unhoard some [1].
>
> Thanks,
> -Aleksey
>
> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902454
>



From vicente.romero at oracle.com  Fri May 17 14:55:36 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 17 May 2019 10:55:36 -0400
Subject: =?UTF-8?Q?Re=3a_RFR=3a_JDK-8223723=3a_j=2el=2ec=2eMethodTypeDesc=2e?=
 =?UTF-8?Q?dropParameterTypes=e2=80=8b_throws_the_undocumented_exception=3a_?=
 =?UTF-8?Q?IllegalArgumentException?=
In-Reply-To: <23e6c6fa-d18a-bef0-3af2-23c785ce1d0d@oracle.com>
References: <b3a7137f-3c4f-d303-7508-9f8366820cb6@oracle.com>
 <23e6c6fa-d18a-bef0-3af2-23c785ce1d0d@oracle.com>
Message-ID: <1d329c14-0a8c-0e83-853c-b366dd99e27f@oracle.com>

ping

On 5/16/19 6:52 PM, Vicente Romero wrote:
> Hi,
>
> I still need a reviewer for this simple patch and CSR,
>
> TIA,
> Vicente
>
> On 5/14/19 4:53 PM, Vicente Romero wrote:
>> Please review fix for [1] at [2]. The implementation of method 
>> java.lang.constant.MethodTypeDesc::dropParameterTypes was throwing a 
>> non specified exception. The proposed fix is synchronizing the 
>> implementation with the specification. Please also review the CSR at 
>> [3]. Check the problem section in the CSR for more details,
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223723
>> [2] http://cr.openjdk.java.net/~vromero/8223767/webrev.00/
>> [3] https://bugs.openjdk.java.net/browse/JDK-8223918
>


From Alan.Bateman at oracle.com  Fri May 17 15:00:02 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 May 2019 16:00:02 +0100
Subject: RFR: 8224112: [TESTBUG]
 java/util/Base64/TestEncodingDecodingLength.java should be skipped with
 insufficient memory
In-Reply-To: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
References: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
Message-ID: <62a48da8-fa6b-729f-c719-cbb0fb1f2ac2@oracle.com>

On 17/05/2019 15:25, Jie Fu wrote:
> Hi all,
>
> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8224112
> Webrev: http://cr.openjdk.java.net/~jiefu/8224112/webrev.00/
>
> java/util/Base64/TestEncodingDecodingLength.java may fail due to 
> insufficient memory when our test machine is busy.
> It might be better to skip it when the available memory is insufficient.
> Could you please review it and give me some advice?
The issue isn't clear. The test only runs when on 64-bit systems with >= 
10GB memory. Is the issue related to the -concurrency setting that you 
specify to jtreg?

-Alan

From Roger.Riggs at oracle.com  Fri May 17 15:04:50 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 17 May 2019 11:04:50 -0400
Subject: [13] RFR: 8214565 and 8214563: Use {@systemProperty} for
 definitions of system properties
In-Reply-To: <7537dd9f-6392-1936-3e55-41cf8936bf48@oracle.com>
References: <a247ca74-b991-4b6a-8c8a-fb9885cd6502@default>
 <7537dd9f-6392-1936-3e55-41cf8936bf48@oracle.com>
Message-ID: <e7572c44-ccab-b85f-6e2b-2b36a2837a69@oracle.com>

Hi,
AsynchronousChannelProvider.java: line 144:? needs a space in 
"anunspecified"
 ? That sentence isn't very well worded, but is outside the scope of 
this change to add the tag.

Otherwise, looks fine.

Roger




On 05/17/2019 06:49 AM, Alan Bateman wrote:
> On 17/05/2019 10:49, Deepak Kejriwal wrote:
>> Hi all,
>>
>>
>> Please review the fix for following issues:-
>>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8214565
>>
>> https://bugs.openjdk.java.net/browse/JDK-8214563
>>
>>
>> Below is the webrev for above issues:
>>
>>
>> http://cr.openjdk.java.net/~dkejriwal/8214565_8214563/webrev.00/
>>
> This looks okay to me.
>
> -Alan


From vicente.romero at oracle.com  Fri May 17 15:47:56 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 17 May 2019 11:47:56 -0400
Subject: RFR: JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented
 exception IllegalArgumentException
In-Reply-To: <953e6ae5-365d-251a-901f-a58fc889d9f5@oracle.com>
References: <953e6ae5-365d-251a-901f-a58fc889d9f5@oracle.com>
Message-ID: <a1e553c8-7a08-05b6-6a44-fbec0f5e6b88@oracle.com>

ping

On 5/14/19 6:37 PM, Vicente Romero wrote:
> Please review fix [1] for [2] and the corresponding CSR at [3]. The 
> fix is just adding a missing @throws at method 
> j.l.c.MethodHandleDesc::of. It is a one liner fix,
>
> Thanks,
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8223725/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8223725
> [3] https://bugs.openjdk.java.net/browse/JDK-8223920


From javalists at cbfiddle.com  Fri May 17 15:51:58 2019
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 17 May 2019 08:51:58 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <ef9cde9c-909b-9387-3165-58e62a6bdbcc@gmail.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>
 <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com>
 <C8F82E77-C1A6-4A7D-A984-8F2B32883620@cbfiddle.com>
 <ef9cde9c-909b-9387-3165-58e62a6bdbcc@gmail.com>
Message-ID: <387E2F97-B1C6-4C94-973C-6D0CD8F0EE9A@cbfiddle.com>

Hi Peter,

I agree that the size based optimization is problematic.

What I would most like to preserve is the performance advantages of using hash coding, which apparently was a goal of the original design:

"implementations of the various Collections Framework interfaces are free to take advantage of the specified behavior of underlying {@link Object} methods wherever the implementor deems it appropriate"

Promoting ersatz Collections to first class citizens would be a significant incompatible change to the specification because it invalidates this statement.

I note that the statement refers to *all* implementations of the Collections Framework interface, not just JDK implementations, so a JDK-internal solution is inadequate.

I agree that some way of identifying ersatz Collections at run time could be useful. It?s tricky, however, as SortedSets and TreeSets are ersatz based on the behavior of the comparator/compare method, which is not discoverable, which means the application must provide that information.

  Alan









> On May 16, 2019, at 11:48 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Alan,
> 
> I can sympathize with the performance loss aspect of this patch, but I nevertheless think it is a move in the right direction. You must admit that the performance optimization of AbstractSet.removeAll was a rather shaky one (dependent on the relative sizes of the two collections) and as such very prone to sudden performance spikes that could occur for seemingly unknown reason. More importantly, the fact that the semantics of the method could change drastically dependent on such thing as relative sizes of the two collections was inexplicable. You may argue that the semantics of the method is undefined if called upon or passed an ersatz Collection instance, but even the undefined semantics may be consistent  - i.e. independent of such things as relative sizes of both collections.
> 
> It would be a perfect world if this optimization was not there to begin with. People would eventually find bottlenecks using this method and change their code to use explicit iteration or such. There may be perfectly valid code out there that uses conformant collection implementations that don't cause AbstractSet.removeAll to behave inconsistently and such code after this patch may perform badly. But it will perform consistently for cases that use ersatz Collections and that is more important in my opinion.
> 
> As Stuart says, optimizations mustn't change semantics. So is there a possibly narrower optimization, that doesn't change the semantics?
> 
> Here's a sketch of one:
> - create a marker interface (could be JDK-internal) and mark all conforming Set implementations with it
> - use AbstractSet.removeAll optimization only when both collections implement the marker interface
> 
> 
> Regards, Peter
> 
> On 5/17/19 7:06 AM, Alan Snyder wrote:
>> Hi Stuart,
>> 
>> I believe I already accepted the fact of ersatz Collections.
>> 
>> Could you explain the inconsistency in the specification that affects removeAll()? I don?t see it.
>> 
>> In the current specification, the classes that can create ersatz Collections all call out the ersatz Collections in their documentation.
>> 
>> SortedSet:
>> Note that the ordering maintained by a sorted set (whether or not an
>> explicit comparator is provided) must be <i>consistent with equals</i> if
>> the sorted set is to correctly implement the {@code Set} interface.
>> The behavior of a sorted set <i>is</i> well-defined even if its
>> ordering is inconsistent with equals; it just fails to obey the general
>> contract of the {@code Set} interface.
>> 
>> TreeSet is similar
>> 
>> IdentityHashMap:
>> 
>> This class is <i>not</i> a general-purpose {@code Map} implementation!  While this class implements the {@code Map} interface, it
>> intentionally violates {@code Map's} general contract, which mandates the
>> use of the {@code equals} method when comparing objects.
>> 
>> IdentityHashMap.keySet:
>> 
>> While the object returned by this method implements the
>> {@code Set} interface, it does <i>not</i> obey {@code Set's} general
>> contract.  Like its backing map, the set returned by this method
>> defines element equality as reference-equality rather than
>> object-equality.  This affects the behavior of its {@code contains},
>> {@code remove}, {@code containsAll}, {@code equals}, and
>> {@code hashCode} methods.
>> 
>> The logical implication of not supporting the general contract is that Collection operations performed on an ersatz Collection may have
>> unexpected (implementation specific) effects, which implies that passing one of these ersatz Collections to a parameter of a Collection
>> type may have unexpected (implementation specific) effects.
>> 
>> In other words, whether removeAll is performed on an ersatz Collection or the parameter is an ersatz Collection, the effects may be
>> implementation specific and inconsistent with the specification of removeAll.
>> 
>> That is not to say that improving the design would not have benefit, of course it does. The bug reports you cite prove that.
>> However, the compatibility impact of the change needs to be taken into account.
>> 
>>   Alan
>> 
>> 
>> 
>>> On May 16, 2019, at 8:42 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>> 
>>> Hi Alan,
>>> 
>>> Whether you call them "ersatz" collections, "non-standard" collections, or collections with different membership semantics, they have been around in the collections framework from day one. This is perhaps unfortunate, and it may be considered to be bad design, but it is a fact.
>>> 
>>> The issue is not with undefined or implementation-specific behavior. The issue is that the specification as it stands is self-contradictory. In particular, it assumes that certain operations are symmetric that in fact are not, if you read other parts of the spec and derive logical conclusions from them. This is what I'm trying to fix. This is not a mere a matter of intellectual consistency. This state of affairs has real consequences. There is a whole family of bugs linked to this one which complain both about the performance issue and the semantic issue. All of these bugs are directly related to the self-contradictory nature of the current specification. With my changes, the spec is self-contradictory in fewer places. (There is, however, more work to be done; see JDK-8190545.)
>>> 
>>> Your lead point, though, is about performance. The performance optimization of AbstractSet.removeAll is one of those that assumes that the operation is symmetric, when in fact it isn't. As a rule, optimizations mustn't change semantics. Therefore, it has to go.
>>> 
>>> s'marks
>>> 
> 


From naoto.sato at oracle.com  Fri May 17 16:39:35 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 17 May 2019 09:39:35 -0700
Subject: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT
 provider
In-Reply-To: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com>
References: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com>
Message-ID: <17c58d5d-c26c-09e1-2ae5-b5109646ecc0@oracle.com>

Hi Leo,

Overall looks good. One comment to the test case is that I would avoid 
using the name "JavaTimeSupplementary" or "JTS", as they are the 
implementation detail. Actually, a DateTimeFormatException may not 
necessarily be caused by a missing JavaTimeSupplementary resource in the 
runtime.

Naoto

On 5/16/19 9:04 PM, li.jiang at oracle.com wrote:
> Hi all,
> 
> Please review the change to update the l10n names for Japanese era Reiwa 
> in JDK COMPAT provider. The l10n names come from the CLDR 35.1, please 
> refer this unicode chart[1] for l10n definitions.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8218781
> Webrev:
> http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/
> 
> In this change,
>  ?- update the l10n names if they are defined in CLDR 35.1.
>  ?- update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW 
> style respectively.
>  ?- In FormatData_th.java, the localized single character was used for 
> previous eras. But we don't find the corresponding name in CLDR 35.1. 
> Update it to 'R' according to CLDR 35.1.
> 
> [1] 
> https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html 
> 
> 
> 
> Thanks,
> Leo

From vicente.romero at oracle.com  Fri May 17 16:55:26 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 17 May 2019 12:55:26 -0400
Subject: RFR: JDK-8223914: specification of j.l.c.MethodTypeDesc::of should
 document better the exceptions thrown
Message-ID: <8991ce18-0b54-d0e8-3dcd-6581fde5141b@oracle.com>

Please review simple fix for [1] at [2] plus the CSR at [3]. This fix is 
simply documenting all the missing cases in which method 
java.lang.constant.MethodTypeDesc::of can throw exceptions. A test has 
been added to cover the missing cases.

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8223914
[2] http://cr.openjdk.java.net/~vromero/8223914/webrev.00/
[3] https://bugs.openjdk.java.net/browse/JDK-8224136

From Roger.Riggs at oracle.com  Fri May 17 17:35:19 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 17 May 2019 13:35:19 -0400
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <a6b73d24-3174-0f2d-8dc7-4011183b00ce@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
 <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>
 <fedb1d4d-3284-8acd-c598-edc003b3e7a5@oracle.com>
 <a6b73d24-3174-0f2d-8dc7-4011183b00ce@oracle.com>
Message-ID: <80c054be-4a23-7851-ba1b-a00b9bd9cc47@oracle.com>

Hi Ivan,

The new calcLength method name is too generic, it does not say enough 
about its function.
There is no indication that the purpose is to resize an array.
As for size vs length, sometime size is more evocative of the function 
being performed
than 'length' and is more natural.? In most cases, size and length are 
understood to be synonyms
and capacity is a very apt term for how many elements can be held.

Can I recommend resizedLength.

Regards, Roger



On 05/15/2019 10:47 PM, Ivan Gerasimov wrote:
> Thank you Pavel and Roger for reviewing!
>
> I apologize for reiterating this.
> After off-line discussion with Stuart Marks, the fix was modified once 
> again.
!!
> The modifications were mostly stylistic:? The used terminology now 
> reflects that we work with arrays (thus 'length', not 'size' or 
> 'capacity').
> Functionally, the fix remains exactly the same.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/02/webrev/
>
> With kind regards,
> Ivan
>
> On 5/14/19 7:50 AM, Roger Riggs wrote:
>> Hi Ivan,
>>
>> The updated patch looks fine.
>>
>> Strictly speaking, the change to Files.readAllBytes is not indicated 
>> by the bug report
>> so please update or comment on the bug report to mention that change.
>>
>> Thanks, Roger
>>
>>
>> On 05/13/2019 10:44 AM, Pavel Rappo wrote:
>>> Thanks for updating your patch. The updated code seems fine.
>>>
>>> -Pavel
>>>
>>>> On 11 May 2019, at 05:01, Ivan Gerasimov<ivan.gerasimov at oracle.com>  wrote:
>>>>
>>>> Hello!
>>>>
>>>> Please help review the updated fix.
>>>>
>>>> This new webrev includes changes suggested by Pavel, Peter and Roger.
>>>>
>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
>>>>
>>>> Please note that the behavior of j.n.f.Files.readAllBytes() has changed slightly, so now it *may* be possible to read a file larger than (Integer.MAX_VALUE - 8), if VM is able to allocate that large array.
>>>>
>>>> With kind regards,
>>>> Ivan
>>>>
>>>> On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
>>>>> Hello!
>>>>>
>>>>> Jdk has several places with similar logic:  an array needs to be reallocated (by at least some defined amount), taking into account the maximum allowed size of arrays.
>>>>>
>>>>> There's clearly an opportunity for refactoring, so it is proposed to introduce a dedicated utility method for calculating the best new size of an array.
>>>>>
>>>>> Would you please help review this enhancement?
>>>>>
>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>>>>>
>>>>> Mach5 job ran fine.
>>>>>
>>>>> Thanks in advance!
>>>>>
>>>> -- 
>>>> With kind regards,
>>>> Ivan Gerasimov
>>>>
>>
>
> -- 
> With kind regards,
> Ivan Gerasimov


From Roger.Riggs at oracle.com  Fri May 17 18:05:37 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 17 May 2019 14:05:37 -0400
Subject: RFR: JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented
 exception IllegalArgumentException
In-Reply-To: <953e6ae5-365d-251a-901f-a58fc889d9f5@oracle.com>
References: <953e6ae5-365d-251a-901f-a58fc889d9f5@oracle.com>
Message-ID: <6f066d47-cd8d-00d8-17ec-502e36088028@oracle.com>

Hi Vicente,

What's the difference in the IAE exceptions describing IAE's as
being "incorrect formats' vs 'is invalid' or 'not valid'?

Each requires a spec for valid and invalid strings or is undefined.

Can the new IAE use the same language as is used for the ofDescriptor 
method?
Avoiding any question about differences.

69:? Also, is the word 'lookup' overloaded?? Is 'lookup' is significant 
in this context?

Roger


On 05/14/2019 06:37 PM, Vicente Romero wrote:
> Please review fix [1] for [2] and the corresponding CSR at [3]. The 
> fix is just adding a missing @throws at method 
> j.l.c.MethodHandleDesc::of. It is a one liner fix,
>
> Thanks,
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8223725/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8223725
> [3] https://bugs.openjdk.java.net/browse/JDK-8223920


From Roger.Riggs at oracle.com  Fri May 17 18:18:23 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 17 May 2019 14:18:23 -0400
Subject: =?UTF-8?Q?Re:_RFR:_JDK-8223723:_j.l.c.MethodTypeDesc.dropParameterT?=
 =?UTF-8?Q?ypes=e2=80=8b_throws_the_undocumented_exception:_IllegalArgumentE?=
 =?UTF-8?Q?xception?=
In-Reply-To: <23e6c6fa-d18a-bef0-3af2-23c785ce1d0d@oracle.com>
References: <b3a7137f-3c4f-d303-7508-9f8366820cb6@oracle.com>
 <23e6c6fa-d18a-bef0-3af2-23c785ce1d0d@oracle.com>
Message-ID: <0c15f347-e6c7-9b60-0559-398cb6ac1b2f@oracle.com>

Hi Vicente,

Method j.l.c.MethodTypeDesc.dropParameterTypes? throws an exception in a 
case
I would change the CSR summary to "Method 
j.l.c.MethodTypeDesc.dropParameterTypes? should specify 
IndexOutOfBoundsException"
to focus on the new behavior.

The link to the webrev looks ok, but has the fix for 8223725 instead.

Roger


On 05/16/2019 06:52 PM, Vicente Romero wrote:
> Hi,
>
> I still need a reviewer for this simple patch and CSR,
>
> TIA,
> Vicente
>
> On 5/14/19 4:53 PM, Vicente Romero wrote:
>> Please review fix for [1] at [2]. The implementation of method 
>> java.lang.constant.MethodTypeDesc::dropParameterTypes was throwing a 
>> non specified exception. The proposed fix is synchronizing the 
>> implementation with the specification. Please also review the CSR at 
>> [3]. Check the problem section in the CSR for more details,
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223723
>> [2] http://cr.openjdk.java.net/~vromero/8223767/webrev.00/
>> [3] https://bugs.openjdk.java.net/browse/JDK-8223918
>


From ivan.gerasimov at oracle.com  Fri May 17 18:45:42 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 17 May 2019 11:45:42 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <80c054be-4a23-7851-ba1b-a00b9bd9cc47@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
 <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>
 <fedb1d4d-3284-8acd-c598-edc003b3e7a5@oracle.com>
 <a6b73d24-3174-0f2d-8dc7-4011183b00ce@oracle.com>
 <80c054be-4a23-7851-ba1b-a00b9bd9cc47@oracle.com>
Message-ID: <f6d01fe9-fc58-5c42-1089-7e282a574241@oracle.com>

Hi Roger!

I think that not only the name, but also the arguments compose the 
signature.
So, calcLength(oldLength, minGrowth, prefGrowth) is meant to be read as 
"given old length and the amount(s) to grow, calculate the new length".
And since this method is placed into ArraysSupport, it should be clear 
that it is an array's length.

I understand that in certain contexts size may sound more natural than 
length.
Here, however, using 'length' should be a hint that we're dealing with 
array.length.

With kind regards,
Ivan

On 5/17/19 10:35 AM, Roger Riggs wrote:
> Hi Ivan,
>
> The new calcLength method name is too generic, it does not say enough 
> about its function.
> There is no indication that the purpose is to resize an array.
> As for size vs length, sometime size is more evocative of the function 
> being performed
> than 'length' and is more natural.  In most cases, size and length are 
> understood to be synonyms
> and capacity is a very apt term for how many elements can be held.
>
> Can I recommend resizedLength.
>
> Regards, Roger
>
>
>
> On 05/15/2019 10:47 PM, Ivan Gerasimov wrote:
>> Thank you Pavel and Roger for reviewing!
>>
>> I apologize for reiterating this.
>> After off-line discussion with Stuart Marks, the fix was modified 
>> once again.
> !!
>> The modifications were mostly stylistic:  The used terminology now 
>> reflects that we work with arrays (thus 'length', not 'size' or 
>> 'capacity').
>> Functionally, the fix remains exactly the same.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/02/webrev/
>>
>> With kind regards,
>> Ivan
>>
>> On 5/14/19 7:50 AM, Roger Riggs wrote:
>>> Hi Ivan,
>>>
>>> The updated patch looks fine.
>>>
>>> Strictly speaking, the change to Files.readAllBytes is not indicated 
>>> by the bug report
>>> so please update or comment on the bug report to mention that change.
>>>
>>> Thanks, Roger
>>>
>>>
>>> On 05/13/2019 10:44 AM, Pavel Rappo wrote:
>>>> Thanks for updating your patch. The updated code seems fine.
>>>>
>>>> -Pavel
>>>>
>>>>> On 11 May 2019, at 05:01, Ivan Gerasimov<ivan.gerasimov at oracle.com>  wrote:
>>>>>
>>>>> Hello!
>>>>>
>>>>> Please help review the updated fix.
>>>>>
>>>>> This new webrev includes changes suggested by Pavel, Peter and Roger.
>>>>>
>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
>>>>>
>>>>> Please note that the behavior of j.n.f.Files.readAllBytes() has changed slightly, so now it *may* be possible to read a file larger than (Integer.MAX_VALUE - 8), if VM is able to allocate that large array.
>>>>>
>>>>> With kind regards,
>>>>> Ivan
>>>>>
>>>>> On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
>>>>>> Hello!
>>>>>>
>>>>>> Jdk has several places with similar logic:  an array needs to be reallocated (by at least some defined amount), taking into account the maximum allowed size of arrays.
>>>>>>
>>>>>> There's clearly an opportunity for refactoring, so it is proposed to introduce a dedicated utility method for calculating the best new size of an array.
>>>>>>
>>>>>> Would you please help review this enhancement?
>>>>>>
>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>>>>>>
>>>>>> Mach5 job ran fine.
>>>>>>
>>>>>> Thanks in advance!
>>>>>>
>>>>> -- 
>>>>> With kind regards,
>>>>> Ivan Gerasimov
>>>>>
>>>
>>
>> -- 
>> With kind regards,
>> Ivan Gerasimov
>

-- 
With kind regards,
Ivan Gerasimov


From vicente.romero at oracle.com  Fri May 17 19:58:29 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 17 May 2019 15:58:29 -0400
Subject: RFR: JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented
 exception IllegalArgumentException
In-Reply-To: <6f066d47-cd8d-00d8-17ec-502e36088028@oracle.com>
References: <953e6ae5-365d-251a-901f-a58fc889d9f5@oracle.com>
 <6f066d47-cd8d-00d8-17ec-502e36088028@oracle.com>
Message-ID: <397f5929-41dc-72ca-505c-c4532994481f@oracle.com>

Hi Roger,

Thanks for the review, my apologies, I made a mistake an applied the 
change to the wrong method. I have corrected the patch [1] and the CSR 
[2]. I have updated the language used as you suggested,

Thanks,
Vicente

[1] http://cr.openjdk.java.net/~vromero/8223725/webrev.01/
[2] https://bugs.openjdk.java.net/browse/JDK-8223920

On 5/17/19 2:05 PM, Roger Riggs wrote:
> Hi Vicente,
>
> What's the difference in the IAE exceptions describing IAE's as
> being "incorrect formats' vs 'is invalid' or 'not valid'?
>
> Each requires a spec for valid and invalid strings or is undefined.
>
> Can the new IAE use the same language as is used for the ofDescriptor 
> method?
> Avoiding any question about differences.
>
> 69:? Also, is the word 'lookup' overloaded?? Is 'lookup' is 
> significant in this context?
>
> Roger
>
>
> On 05/14/2019 06:37 PM, Vicente Romero wrote:
>> Please review fix [1] for [2] and the corresponding CSR at [3]. The 
>> fix is just adding a missing @throws at method 
>> j.l.c.MethodHandleDesc::of. It is a one liner fix,
>>
>> Thanks,
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8223725/webrev.00/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8223725
>> [3] https://bugs.openjdk.java.net/browse/JDK-8223920
>


From vicente.romero at oracle.com  Fri May 17 20:14:58 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 17 May 2019 16:14:58 -0400
Subject: =?UTF-8?Q?Re=3a_RFR=3a_JDK-8223723=3a_j=2el=2ec=2eMethodTypeDesc=2e?=
 =?UTF-8?Q?dropParameterTypes=e2=80=8b_throws_the_undocumented_exception=3a_?=
 =?UTF-8?Q?IllegalArgumentException?=
In-Reply-To: <0c15f347-e6c7-9b60-0559-398cb6ac1b2f@oracle.com>
References: <b3a7137f-3c4f-d303-7508-9f8366820cb6@oracle.com>
 <23e6c6fa-d18a-bef0-3af2-23c785ce1d0d@oracle.com>
 <0c15f347-e6c7-9b60-0559-398cb6ac1b2f@oracle.com>
Message-ID: <63c39e33-f58b-bc45-427c-813de2e484af@oracle.com>

Hi Roger,

Thanks again for the reviews, I have modified the CSR summary after your 
suggestion [1]. I have also fixed the issue with the webrev link [2],

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8223918
[2] http://cr.openjdk.java.net/~vromero/8223723/webrev.01/

On 5/17/19 2:18 PM, Roger Riggs wrote:
> Hi Vicente,
>
> Method j.l.c.MethodTypeDesc.dropParameterTypes? throws an exception in 
> a case
> I would change the CSR summary to "Method 
> j.l.c.MethodTypeDesc.dropParameterTypes? should specify 
> IndexOutOfBoundsException"
> to focus on the new behavior.
>
> The link to the webrev looks ok, but has the fix for 8223725 instead.
>
> Roger
>
>
> On 05/16/2019 06:52 PM, Vicente Romero wrote:
>> Hi,
>>
>> I still need a reviewer for this simple patch and CSR,
>>
>> TIA,
>> Vicente
>>
>> On 5/14/19 4:53 PM, Vicente Romero wrote:
>>> Please review fix for [1] at [2]. The implementation of method 
>>> java.lang.constant.MethodTypeDesc::dropParameterTypes was throwing a 
>>> non specified exception. The proposed fix is synchronizing the 
>>> implementation with the specification. Please also review the CSR at 
>>> [3]. Check the problem section in the CSR for more details,
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8223723
>>> [2] http://cr.openjdk.java.net/~vromero/8223767/webrev.00/
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8223918
>>
>


From Roger.Riggs at oracle.com  Fri May 17 20:53:22 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 17 May 2019 16:53:22 -0400
Subject: =?UTF-8?Q?Re:_RFR:_JDK-8223723:_j.l.c.MethodTypeDesc.dropParameterT?=
 =?UTF-8?Q?ypes=e2=80=8b_throws_the_undocumented_exception:_IllegalArgumentE?=
 =?UTF-8?Q?xception?=
In-Reply-To: <63c39e33-f58b-bc45-427c-813de2e484af@oracle.com>
References: <b3a7137f-3c4f-d303-7508-9f8366820cb6@oracle.com>
 <23e6c6fa-d18a-bef0-3af2-23c785ce1d0d@oracle.com>
 <0c15f347-e6c7-9b60-0559-398cb6ac1b2f@oracle.com>
 <63c39e33-f58b-bc45-427c-813de2e484af@oracle.com>
Message-ID: <0364ef78-bff4-8b21-e169-20df27b9622b@oracle.com>

Hi Vicente,

Looks fine.

Please add a "." at the end of the summary 2nd sentence.

BTW, are you aware of the range checking methods in 
java.util.Objects.checkFromToIndex(from, to, length)?
They make it easy avoid to check all the conditions on subranges.

Thanks, Roger


On 05/17/2019 04:14 PM, Vicente Romero wrote:
> Hi Roger,
>
> Thanks again for the reviews, I have modified the CSR summary after 
> your suggestion [1]. I have also fixed the issue with the webrev link 
> [2],
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223918
> [2] http://cr.openjdk.java.net/~vromero/8223723/webrev.01/
>
> On 5/17/19 2:18 PM, Roger Riggs wrote:
>> Hi Vicente,
>>
>> Method j.l.c.MethodTypeDesc.dropParameterTypes? throws an exception 
>> in a case
>> I would change the CSR summary to "Method 
>> j.l.c.MethodTypeDesc.dropParameterTypes? should specify 
>> IndexOutOfBoundsException"
>> to focus on the new behavior.
>>
>> The link to the webrev looks ok, but has the fix for 8223725 instead.
>>
>> Roger
>>
>>
>> On 05/16/2019 06:52 PM, Vicente Romero wrote:
>>> Hi,
>>>
>>> I still need a reviewer for this simple patch and CSR,
>>>
>>> TIA,
>>> Vicente
>>>
>>> On 5/14/19 4:53 PM, Vicente Romero wrote:
>>>> Please review fix for [1] at [2]. The implementation of method 
>>>> java.lang.constant.MethodTypeDesc::dropParameterTypes was throwing 
>>>> a non specified exception. The proposed fix is synchronizing the 
>>>> implementation with the specification. Please also review the CSR 
>>>> at [3]. Check the problem section in the CSR for more details,
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8223723
>>>> [2] http://cr.openjdk.java.net/~vromero/8223767/webrev.00/
>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8223918
>>>
>>
>


From naoto.sato at oracle.com  Fri May 17 22:43:09 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 17 May 2019 15:43:09 -0700
Subject: [13] RFR: 8224105: Cannot parse JapaneseDate string on some specified
 locales
Message-ID: <fc0763f3-6ce0-0a49-6b47-e3e7c2aba060@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8224105/webrev.00/

CLDR does not provide entire localized Japanese era names in locales 
mentioned in the bug report. The parsing has been failing as they have 
duplicate names, despite the duplicates are empty strings.

Naoto

From stuart.marks at oracle.com  Fri May 17 22:56:27 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 17 May 2019 15:56:27 -0700
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>

Hi Christoph,

I'm still not entirely sure why this is so, but the introduction of a local 
variable in MethodHandles.java seems to make things work for Eclipse. Addition 
of a local variable seems to be minimally invasive, so it makes sense to see if 
this technique can be applied to other cases.

(In ConcurrentSkipListMap the issue seems to be solved by addition of wildcards, 
as I had suggested previously, and it cleans up the unchecked cast that was 
there in the first place. So I think that one is ok already.)

In ManagementFactory.java, an unchecked cast and warnings suppression is 
introduced, and in ExchangeImpl.java a helper method was introduced. I've found 
ways to introduce local variables that make Eclipse happy for these cases. 
(Well, on localized test cases; I haven't built the whole JDK with Eclipse.) See 
diffs below.

The type of the local variable in ExchangeImpl.java is a mouthful. Interestingly 
I had to change Function.identity() to the lambda x -> x. I think this is 
because Function.identity() returns a function that doesn't allow its return 
type to vary from its argument, whereas x -> x allows a widening conversion. 
(This might provide a clue as to the differences between javac and Eclipse here, 
but a full understanding eludes me.)

s'marks



diff -r 006dadb903ab 
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
--- 
a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
Mon May 13 17:15:56 2019 -0700
+++ 
b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java 
Fri May 17 15:46:14 2019 -0700
@@ -1712,9 +1712,7 @@
          Map<?,?> m = (Map<?,?>) o;
          try {
              Comparator<? super K> cmp = comparator;
-            @SuppressWarnings("unchecked")
-            Iterator<Map.Entry<?,?>> it =
-                (Iterator<Map.Entry<?,?>>)m.entrySet().iterator();
+            Iterator<? extends Map.Entry<?,?>> it = m.entrySet().iterator();
              if (m instanceof SortedMap &&
                  ((SortedMap<?,?>)m).comparator() == cmp) {
                  Node<K,V> b, n;
diff -r 006dadb903ab 
src/java.management/share/classes/java/lang/management/ManagementFactory.java
--- 
a/src/java.management/share/classes/java/lang/management/ManagementFactory.java 
Mon May 13 17:15:56 2019 -0700
+++ 
b/src/java.management/share/classes/java/lang/management/ManagementFactory.java 
Fri May 17 15:46:14 2019 -0700
@@ -872,12 +872,12 @@
      public static Set<Class<? extends PlatformManagedObject>>
             getPlatformManagementInterfaces()
      {
-        return platformComponents()
+        Stream<Class<? extends PlatformManagedObject>> pmos = platformComponents()
                  .stream()
                  .flatMap(pc -> pc.mbeanInterfaces().stream())
                  .filter(clazz -> 
PlatformManagedObject.class.isAssignableFrom(clazz))
-                .map(clazz -> clazz.asSubclass(PlatformManagedObject.class))
-                .collect(Collectors.toSet());
+                .map(clazz -> clazz.asSubclass(PlatformManagedObject.class));
+         return pmos.collect(Collectors.toSet());
      }

      private static final String NOTIF_EMITTER =
diff -r 006dadb903ab 
src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
--- a/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java 
Mon May 13 17:15:56 2019 -0700
+++ b/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java 
Fri May 17 15:46:14 2019 -0700
@@ -92,8 +92,9 @@
              CompletableFuture<Http2Connection> c2f = 
c2.getConnectionFor(request, exchange);
              if (debug.on())
                  debug.log("get: Trying to get HTTP/2 connection");
-            return c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange, 
connection))
-                    .thenCompose(Function.identity());
+            CompletableFuture<CompletableFuture<? extends ExchangeImpl<U>>> fxi =
+                c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange, 
connection));
+            return fxi.thenCompose(x -> x);
          }
      }



From fujie at loongson.cn  Sat May 18 01:17:33 2019
From: fujie at loongson.cn (Jie Fu)
Date: Sat, 18 May 2019 09:17:33 +0800
Subject: RFR: 8224112: [TESTBUG]
 java/util/Base64/TestEncodingDecodingLength.java should be skipped with
 insufficient memory
In-Reply-To: <62a48da8-fa6b-729f-c719-cbb0fb1f2ac2@oracle.com>
References: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
 <62a48da8-fa6b-729f-c719-cbb0fb1f2ac2@oracle.com>
Message-ID: <56348c1d-5c74-fa34-c9f6-9204ca20a88f@loongson.cn>

Hi Alan,

On 2019/5/17 ??11:00, Alan Bateman wrote:
> The issue isn't clear. The test only runs when on 64-bit systems with 
> >= 10GB memory. Is the issue related to the -concurrency setting that 
> you specify to jtreg?
No. Even we set the concurrency=1, the issue may still occur.
os.maxMemory >= 10g just check whether the capacity of physical memory 
is >= 10g, not the available memory to be used.

Our test machine has only 16GB physical memory and is shared by many 
people in our group.
The test seems to fail occasionally especially when the test machine is 
busy.
I'm trying to find a better solution to this problem.

Best regards,
Jie


From fujie at loongson.cn  Sat May 18 08:10:57 2019
From: fujie at loongson.cn (Jie Fu)
Date: Sat, 18 May 2019 16:10:57 +0800
Subject: RFR: 8224112: [TESTBUG]
 java/util/Base64/TestEncodingDecodingLength.java should be skipped with
 insufficient memory
In-Reply-To: <b788a1fd-ed52-293a-6fbe-53642bb2c465@loongson.cn>
References: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
 <602a4ed6-a9aa-c9ba-ce91-75f7f584e33b@redhat.com>
 <b788a1fd-ed52-293a-6fbe-53642bb2c465@loongson.cn>
Message-ID: <7440642b-1daa-a375-7b55-fb809ab5d8d8@loongson.cn>

Hi all,

Please review the updated version: 
http://cr.openjdk.java.net/~jiefu/8224112/webrev.01/

If the memory isn't enough, the test won't run (filtered out by the 
"requires" tag) instead of being skipped in the previous patch.
It fixes the false sense of passing problem pointed out by Aleksey.
Could you please review it and give me some advice?

Thanks a lot.
Best regards,
Jie

On 2019/5/17 ??10:55, Jie Fu wrote:
> Okay.
>
> Thank you Aleksey.
>
> On 2019?05?17? 22:30, Aleksey Shipilev wrote:
>> On 5/17/19 4:25 PM, Jie Fu wrote:
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224112
>>> Webrev: http://cr.openjdk.java.net/~jiefu/8224112/webrev.00/
>>>
>>> java/util/Base64/TestEncodingDecodingLength.java may fail due to 
>>> insufficient memory when our test
>>> machine is busy.
>>> It might be better to skip it when the available memory is 
>>> insufficient.
>>> Could you please review it and give me some advice?
>> I am against special casing like that: it may give you the false 
>> sense of passing the test when it
>> is actually broken. In other words, having the infrastructure-induced 
>> test failure is better than
>> having the test that allows bugs to creep in. Get more memory on a 
>> test machine, and maybe lobby for
>> jtreg to unhoard some [1].
>>
>> Thanks,
>> -Aleksey
>>
>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902454
>>
>
>


From Alan.Bateman at oracle.com  Sat May 18 08:25:48 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 18 May 2019 09:25:48 +0100
Subject: RFR: 8224112: [TESTBUG]
 java/util/Base64/TestEncodingDecodingLength.java should be skipped with
 insufficient memory
In-Reply-To: <56348c1d-5c74-fa34-c9f6-9204ca20a88f@loongson.cn>
References: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
 <62a48da8-fa6b-729f-c719-cbb0fb1f2ac2@oracle.com>
 <56348c1d-5c74-fa34-c9f6-9204ca20a88f@loongson.cn>
Message-ID: <79bbba1f-9e3c-74fe-f38c-c45c4bb34d1e@oracle.com>

On 18/05/2019 02:17, Jie Fu wrote:
> Hi Alan,
>
> On 2019/5/17 ??11:00, Alan Bateman wrote:
>> The issue isn't clear. The test only runs when on 64-bit systems with 
>> >= 10GB memory. Is the issue related to the -concurrency setting that 
>> you specify to jtreg?
> No. Even we set the concurrency=1, the issue may still occur.
> os.maxMemory >= 10g just check whether the capacity of physical memory 
> is >= 10g, not the available memory to be used.
>
> Our test machine has only 16GB physical memory and is shared by many 
> people in our group.
> The test seems to fail occasionally especially when the test machine 
> is busy.
> I'm trying to find a better solution to this problem.
I'm guessing this must be an embedded system with no swap configured. If 
so then I don't think this is solvable without reserving the machine 
when you need to run tests. This test uses 6-8GB of memory and there are 
several other tests that consume lots of memory too. If several people 
are trying to run tests or do builds at the same time then I assume 
you'll have issues in many areas. I see your patch to have the test skip 
when there isn't 6GB of "free memory" but I assume you'll still have 
intermittent failures when someone else tries to run resource hungry 
tests at around the same time.

-Alan

From shade at redhat.com  Sat May 18 09:00:03 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Sat, 18 May 2019 11:00:03 +0200
Subject: RFR: 8224112: [TESTBUG]
 java/util/Base64/TestEncodingDecodingLength.java should be skipped with
 insufficient memory
In-Reply-To: <7440642b-1daa-a375-7b55-fb809ab5d8d8@loongson.cn>
References: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
 <602a4ed6-a9aa-c9ba-ce91-75f7f584e33b@redhat.com>
 <b788a1fd-ed52-293a-6fbe-53642bb2c465@loongson.cn>
 <7440642b-1daa-a375-7b55-fb809ab5d8d8@loongson.cn>
Message-ID: <6eaf4971-af3d-850b-33c7-1554f98794c6@redhat.com>

On 5/18/19 10:10 AM, Jie Fu wrote:
> If the memory isn't enough, the test won't run (filtered out by the "requires" tag) instead of
> being skipped in the previous patch. It fixes the false sense of passing problem pointed out by
> Aleksey. Could you please review it and give me some advice?
Still against it, sorry. You are asking to skip the test based on the transient state of the system,
that is not related to the product at all. Suppose the test fails due to a product bug. A developer
can run the tests on busy machine, get the test skipped because there is no free memory (it is
hoarded by other developers), and come thinking that product is not broken. Checking the "free
memory" does not resolve the false sense of passing tests in that scenario.

Once again, having the infrastructure-induced (false) test failure is better than having the test
that allows bugs to creep in. Get more memory on a test machine (16 GB on a shared test machine is
heavily problematic!), or figure out the ways you schedule tests -- maybe with the help of CI that
serializes test runs (that is what I do), or skip the test failure manually when analyzing the
results (that is what I do as well).

-Aleksey


From fujie at loongson.cn  Sat May 18 09:06:04 2019
From: fujie at loongson.cn (Jie Fu)
Date: Sat, 18 May 2019 17:06:04 +0800
Subject: RFR: 8224112: [TESTBUG]
 java/util/Base64/TestEncodingDecodingLength.java should be skipped with
 insufficient memory
In-Reply-To: <79bbba1f-9e3c-74fe-f38c-c45c4bb34d1e@oracle.com>
References: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
 <62a48da8-fa6b-729f-c719-cbb0fb1f2ac2@oracle.com>
 <56348c1d-5c74-fa34-c9f6-9204ca20a88f@loongson.cn>
 <79bbba1f-9e3c-74fe-f38c-c45c4bb34d1e@oracle.com>
Message-ID: <964d2e24-10a9-f7ee-3a82-91131a8eba85@loongson.cn>

Hi Alan,

Oh, we just have 2G swap buffer on our machine.
Yes, we do have observed some other intermittent failures due to 
memory/network/GUI reasons, but this case is the most frequently 
observed one.
I just try to improve the test stability since it seems impossible to 
always keep others away from the machine when doing the tests.

Thanks.
Best regards,
Jie

On 2019/5/18 ??4:25, Alan Bateman wrote:
> On 18/05/2019 02:17, Jie Fu wrote:
>> Hi Alan,
>>
>> On 2019/5/17 ??11:00, Alan Bateman wrote:
>>> The issue isn't clear. The test only runs when on 64-bit systems 
>>> with >= 10GB memory. Is the issue related to the -concurrency 
>>> setting that you specify to jtreg?
>> No. Even we set the concurrency=1, the issue may still occur.
>> os.maxMemory >= 10g just check whether the capacity of physical 
>> memory is >= 10g, not the available memory to be used.
>>
>> Our test machine has only 16GB physical memory and is shared by many 
>> people in our group.
>> The test seems to fail occasionally especially when the test machine 
>> is busy.
>> I'm trying to find a better solution to this problem.
> I'm guessing this must be an embedded system with no swap configured. 
> If so then I don't think this is solvable without reserving the 
> machine when you need to run tests. This test uses 6-8GB of memory and 
> there are several other tests that consume lots of memory too. If 
> several people are trying to run tests or do builds at the same time 
> then I assume you'll have issues in many areas. I see your patch to 
> have the test skip when there isn't 6GB of "free memory" but I assume 
> you'll still have intermittent failures when someone else tries to run 
> resource hungry tests at around the same time.
>
> -Alan


From fujie at loongson.cn  Sat May 18 09:14:40 2019
From: fujie at loongson.cn (Jie Fu)
Date: Sat, 18 May 2019 17:14:40 +0800
Subject: RFR: 8224112: [TESTBUG]
 java/util/Base64/TestEncodingDecodingLength.java should be skipped with
 insufficient memory
In-Reply-To: <6eaf4971-af3d-850b-33c7-1554f98794c6@redhat.com>
References: <192c6bab-523a-33f3-3175-d6ad1116ee4c@loongson.cn>
 <602a4ed6-a9aa-c9ba-ce91-75f7f584e33b@redhat.com>
 <b788a1fd-ed52-293a-6fbe-53642bb2c465@loongson.cn>
 <7440642b-1daa-a375-7b55-fb809ab5d8d8@loongson.cn>
 <6eaf4971-af3d-850b-33c7-1554f98794c6@redhat.com>
Message-ID: <983f604e-3db6-6e99-1832-290822214cad@loongson.cn>

Okay, I see.

Thank you very much, Aleksey.

On 2019/5/18 ??5:00, Aleksey Shipilev wrote:
> On 5/18/19 10:10 AM, Jie Fu wrote:
>> If the memory isn't enough, the test won't run (filtered out by the "requires" tag) instead of
>> being skipped in the previous patch. It fixes the false sense of passing problem pointed out by
>> Aleksey. Could you please review it and give me some advice?
> Still against it, sorry. You are asking to skip the test based on the transient state of the system,
> that is not related to the product at all. Suppose the test fails due to a product bug. A developer
> can run the tests on busy machine, get the test skipped because there is no free memory (it is
> hoarded by other developers), and come thinking that product is not broken. Checking the "free
> memory" does not resolve the false sense of passing tests in that scenario.
>
> Once again, having the infrastructure-induced (false) test failure is better than having the test
> that allows bugs to creep in. Get more memory on a test machine (16 GB on a shared test machine is
> heavily problematic!), or figure out the ways you schedule tests -- maybe with the help of CI that
> serializes test runs (that is what I do), or skip the test failure manually when analyzing the
> results (that is what I do as well).
>
> -Aleksey
>


From Alan.Bateman at oracle.com  Sat May 18 09:31:41 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 18 May 2019 10:31:41 +0100
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <fd756aff51134b15a40fe55247d4a87e@sap.com>
 <CA+3eh13dP-tCdq4H4z3KWJZQzfMJYqDNkx9fMh3tNfL08RCtDg@mail.gmail.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <a3e64312-d902-b751-d55d-0af1c4c6e3c5@oracle.com>
 <953449f0913340f6a94ae3d83611fd92@sap.com>
 <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>
 <HE1PR0201MB2266326D98F5119796990BFC8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
 <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <fad24c8f-aa40-821e-fa15-9cbe32b0eb76@oracle.com>

On 09/05/2019 16:16, Langer, Christoph wrote:
> Hi Alan,
>
> I've got a new iteration for the zipfs POSIX support and addressed your concerns: http://cr.openjdk.java.net/~clanger/webrevs/8213031.9/
Thanks. I think you've addressed most of my points. The only thing that 
isn't clear is the group owner as I thought we had converged on using 
the zip file's group owner.? If I read the code correctly then it uses 
the file owner (and makes the assumption that defaultOwner is 
initialized before initGroup is called).

In passing, the name of the PosixFileAttributeView implementation should 
probably be ZipPosixFileAttributeView rather than 
ZipFilePosixAttributeViewPosix. Also EntryPosix extends Entry, should 
probably be PosixEntry. Not important as these are internal but noticed 
them when scanning the changes.

Also in passing, there are several places using 
AccessController.doPrivileged that are bit ugly due to the casting. The 
doPrivileged methods are awkward to use with lambda expressions (not 
your doing) but one approach that I find readable is to separate the 
creation of the action, e.g. file the zip file owner it could be:

PrivilegedExceptionAction<UserPrincipal> pa = () -> Files.getOwner(zfpath);
return AccessController.doPrivileged(pa).

In the same area, the code in initOwner catches UOE but that will always 
be wrapped in PAE.

Not important to the discussion here of course.

> :
> I have updated module-info a little bit to reflect the latest changes. Is it now time to focus on the CSR?
>
The "For extended POSIX support ..." paragraph has the property name 
from a previous iteration so I assume you'll update that. I think it 
would be using to put quotes around the names too. It also specifies the 
fallback group owner to be the file owner but I think we converged on 
use the zip file's group owner where possible.

A small bit of word smiting required but I think this is really close to 
writing the CSR.

-Alan




From li.jiang at oracle.com  Sat May 18 13:23:23 2019
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Sat, 18 May 2019 21:23:23 +0800
Subject: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT
 provider
In-Reply-To: <17c58d5d-c26c-09e1-2ae5-b5109646ecc0@oracle.com>
References: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com>
 <17c58d5d-c26c-09e1-2ae5-b5109646ecc0@oracle.com>
Message-ID: <e3c617b9-b364-7b79-f92d-6b93cdc543c7@oracle.com>

Hi Naoto,

Please review the updated webrev:
http://cr.openjdk.java.net/~ljiang/8218781/webrev.01/

In this update, renamed the data provider names and test case name to 
improve the readability.

Thanks,
Leo

On 5/18/19 12:39 AM, naoto.sato at oracle.com wrote:
> Hi Leo,
> 
> Overall looks good. One comment to the test case is that I would avoid 
> using the name "JavaTimeSupplementary" or "JTS", as they are the 
> implementation detail. Actually, a DateTimeFormatException may not 
> necessarily be caused by a missing JavaTimeSupplementary resource in the 
> runtime.
> 
> Naoto
> 
> On 5/16/19 9:04 PM, li.jiang at oracle.com wrote:
>> Hi all,
>>
>> Please review the change to update the l10n names for Japanese era 
>> Reiwa in JDK COMPAT provider. The l10n names come from the CLDR 35.1, 
>> please refer this unicode chart[1] for l10n definitions.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8218781
>> Webrev:
>> http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/
>>
>> In this change,
>> ??- update the l10n names if they are defined in CLDR 35.1.
>> ??- update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW 
>> style respectively.
>> ??- In FormatData_th.java, the localized single character was used for 
>> previous eras. But we don't find the corresponding name in CLDR 35.1. 
>> Update it to 'R' according to CLDR 35.1.
>>
>> [1] 
>> https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html 
>>
>>
>>
>> Thanks,
>> Leo

From naoto.sato at oracle.com  Sun May 19 13:55:25 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Sun, 19 May 2019 06:55:25 -0700
Subject: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT
 provider
In-Reply-To: <e3c617b9-b364-7b79-f92d-6b93cdc543c7@oracle.com>
References: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com>
 <17c58d5d-c26c-09e1-2ae5-b5109646ecc0@oracle.com>
 <e3c617b9-b364-7b79-f92d-6b93cdc543c7@oracle.com>
Message-ID: <ba76507e-966f-6926-23c2-4c1548c811cb@oracle.com>

Looks good.

Naoto

On 5/18/19 6:23 AM, li.jiang at oracle.com wrote:
> Hi Naoto,
> 
> Please review the updated webrev:
> http://cr.openjdk.java.net/~ljiang/8218781/webrev.01/
> 
> In this update, renamed the data provider names and test case name to 
> improve the readability.
> 
> Thanks,
> Leo
> 
> On 5/18/19 12:39 AM, naoto.sato at oracle.com wrote:
>> Hi Leo,
>>
>> Overall looks good. One comment to the test case is that I would avoid 
>> using the name "JavaTimeSupplementary" or "JTS", as they are the 
>> implementation detail. Actually, a DateTimeFormatException may not 
>> necessarily be caused by a missing JavaTimeSupplementary resource in 
>> the runtime.
>>
>> Naoto
>>
>> On 5/16/19 9:04 PM, li.jiang at oracle.com wrote:
>>> Hi all,
>>>
>>> Please review the change to update the l10n names for Japanese era 
>>> Reiwa in JDK COMPAT provider. The l10n names come from the CLDR 35.1, 
>>> please refer this unicode chart[1] for l10n definitions.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8218781
>>> Webrev:
>>> http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/
>>>
>>> In this change,
>>> ??- update the l10n names if they are defined in CLDR 35.1.
>>> ??- update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW 
>>> style respectively.
>>> ??- In FormatData_th.java, the localized single character was used 
>>> for previous eras. But we don't find the corresponding name in CLDR 
>>> 35.1. Update it to 'R' according to CLDR 35.1.
>>>
>>> [1] 
>>> https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html 
>>>
>>>
>>>
>>> Thanks,
>>> Leo

From li.jiang at oracle.com  Sun May 19 14:16:19 2019
From: li.jiang at oracle.com (li.jiang at oracle.com)
Date: Sun, 19 May 2019 22:16:19 +0800
Subject: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT
 provider
In-Reply-To: <ba76507e-966f-6926-23c2-4c1548c811cb@oracle.com>
References: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com>
 <17c58d5d-c26c-09e1-2ae5-b5109646ecc0@oracle.com>
 <e3c617b9-b364-7b79-f92d-6b93cdc543c7@oracle.com>
 <ba76507e-966f-6926-23c2-4c1548c811cb@oracle.com>
Message-ID: <63483dac-f105-3feb-0855-8ea9bb7dddec@oracle.com>

Thank you, pushed.

/Leo

On 5/19/19 9:55 PM, naoto.sato at oracle.com wrote:
> Looks good.
> 
> Naoto
> 
> On 5/18/19 6:23 AM, li.jiang at oracle.com wrote:
>> Hi Naoto,
>>
>> Please review the updated webrev:
>> http://cr.openjdk.java.net/~ljiang/8218781/webrev.01/
>>
>> In this update, renamed the data provider names and test case name to 
>> improve the readability.
>>
>> Thanks,
>> Leo
>>
>> On 5/18/19 12:39 AM, naoto.sato at oracle.com wrote:
>>> Hi Leo,
>>>
>>> Overall looks good. One comment to the test case is that I would 
>>> avoid using the name "JavaTimeSupplementary" or "JTS", as they are 
>>> the implementation detail. Actually, a DateTimeFormatException may 
>>> not necessarily be caused by a missing JavaTimeSupplementary resource 
>>> in the runtime.
>>>
>>> Naoto
>>>
>>> On 5/16/19 9:04 PM, li.jiang at oracle.com wrote:
>>>> Hi all,
>>>>
>>>> Please review the change to update the l10n names for Japanese era 
>>>> Reiwa in JDK COMPAT provider. The l10n names come from the CLDR 
>>>> 35.1, please refer this unicode chart[1] for l10n definitions.
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8218781
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/
>>>>
>>>> In this change,
>>>> ??- update the l10n names if they are defined in CLDR 35.1.
>>>> ??- update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW 
>>>> style respectively.
>>>> ??- In FormatData_th.java, the localized single character was used 
>>>> for previous eras. But we don't find the corresponding name in CLDR 
>>>> 35.1. Update it to 'R' according to CLDR 35.1.
>>>>
>>>> [1] 
>>>> https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html 
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Leo

From joe.darcy at oracle.com  Sun May 19 19:09:02 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 19 May 2019 12:09:02 -0700
Subject: JDK 13 RFR of JDK-8224174: java.lang.Number has a default constructor
Message-ID: <a41e25f6-1df5-201e-1ada-dff377443783@oracle.com>

Hello,

While doing some other work, I noticed that java.lang.Number relies on 
an implicit default constructor. Until there is a lint warning to find 
these cases systematically (JDK-8071961: Add javac lint warning when a 
default constructor is created), please review the diff below to address 
this particular instance.

Thanks,

-Joe


 ?public abstract class Number implements java.io.Serializable {
 ???? /**
+???? * Constructor for subclasses to call.
+???? */
+??? public Number() {super();}
+
+??? /**


From joe.darcy at oracle.com  Sun May 19 19:36:55 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 19 May 2019 12:36:55 -0700
Subject: JDK 13 RFR of JDK-8224175: Fix inconsistencies in @jls and @jvms tags
Message-ID: <478b540e-35a0-b9df-8bf3-c03b0422af8f@oracle.com>

Hello,

Thanks to some tooling developed by Jon Gibbons, inconsistencies in the 
section names and numbers in the @jls and @jvms javadoc tags in the jdk 
and the names and numbers of the current specifications have been 
identified. These inconsistencies should be fixed.

The names and numbers of the section titles in JLS and JVMS are *mostly* 
stable, but a few sections have changed most notably for the usage of 
@jls tags:

 ??? * 8.9 "Enum" -> "Enum Type" in Java SE 8
 ??? * 5.1.2 "Widening Primitive Conversions" -> "Widening Primitive 
*Conversion*" in Java SE 7

Two uses of "@jvms 5.3 Run-time package" refer to the term "Run-time 
package" defined in that section. The term was replaced by the section 
name in both cases.

In java.lang.SuppressWarnings, a reference to the section "5.5.2 Checked 
Casts and Unchecked Casts", which was removed in Java SE 9, was replaced 
with a reference to the enclosing section "5.5. Casting Contexts".

The usage of @jls in jshell was less consistent and has been regularized.

Full webrev at:

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

Patch below.

Thanks,

-Joe

--- old/src/java.base/share/classes/java/lang/Byte.java 2019-05-19 
12:16:26.705761266 -0700
+++ new/src/java.base/share/classes/java/lang/Byte.java 2019-05-19 
12:16:26.137761266 -0700
@@ -356,7 +356,7 @@
 ???? /**
 ????? * Returns the value of this {@code Byte} as a {@code short} after
 ????? * a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public short shortValue() {
 ???????? return (short)value;
@@ -365,7 +365,7 @@
 ???? /**
 ????? * Returns the value of this {@code Byte} as an {@code int} after
 ????? * a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public int intValue() {
 ???????? return (int)value;
@@ -374,7 +374,7 @@
 ???? /**
 ????? * Returns the value of this {@code Byte} as a {@code long} after
 ????? * a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public long longValue() {
 ???????? return (long)value;
@@ -383,7 +383,7 @@
 ???? /**
 ????? * Returns the value of this {@code Byte} as a {@code float} after
 ????? * a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public float floatValue() {
 ???????? return (float)value;
@@ -392,7 +392,7 @@
 ???? /**
 ????? * Returns the value of this {@code Byte} as a {@code double}
 ????? * after a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public double doubleValue() {
 ???????? return (double)value;
--- old/src/java.base/share/classes/java/lang/Class.java 2019-05-19 
12:16:27.597761266 -0700
+++ new/src/java.base/share/classes/java/lang/Class.java 2019-05-19 
12:16:27.161761266 -0700
@@ -999,7 +999,7 @@
 ????? *
 ????? * @since 9
 ????? * @spec JPMS
-???? * @jls 6.7? Fully Qualified Names
+???? * @jls 6.7 Fully Qualified Names
 ????? */
 ???? public String getPackageName() {
 ???????? String pn = this.packageName;
@@ -3910,7 +3910,8 @@
 ????? *???????? SecurityManager#checkPackageAccess s.checkPackageAccess()}
 ????? *???????? denies access to the package of the returned class
 ????? * @since 11
-???? * @jvms 4.7.28 and 4.7.29 NestHost and NestMembers attributes
+???? * @jvms 4.7.28 The {@code NestHost} Attribute
+???? * @jvms 4.7.29 The {@code NestMembers} Attribute
 ????? * @jvms 5.4.4 Access Control
 ????? */
 ???? @CallerSensitive
--- old/src/java.base/share/classes/java/lang/ClassLoader.java 
2019-05-19 12:16:28.429761266 -0700
+++ new/src/java.base/share/classes/java/lang/ClassLoader.java 
2019-05-19 12:16:28.041761266 -0700
@@ -222,7 +222,7 @@
 ? * or a fully qualified name as defined by
 ? * <cite>The Java&trade; Language Specification</cite>.
 ? *
- * @jls 6.7? Fully Qualified Names
+ * @jls 6.7 Fully Qualified Names
 ? * @jls 13.1 The Form of a Binary
 ? * @see????? #resolveClass(Class)
 ? * @since 1.0
@@ -2194,7 +2194,7 @@
 ????? * @revised 9
 ????? * @spec JPMS
 ????? *
-???? * @jvms 5.3 Run-time package
+???? * @jvms 5.3 Creation and Loading
 ????? * @see <a href="{@docRoot}/../specs/jar/jar.html#package-sealing">
 ????? *????? The JAR File Specification: Package Sealing</a>
 ????? */
@@ -2228,7 +2228,7 @@
 ????? * @throws? NullPointerException
 ????? *????????? if {@code name} is {@code null}.
 ????? *
-???? * @jvms 5.3 Run-time package
+???? * @jvms 5.3 Creation and Loading
 ????? *
 ????? * @since? 9
 ????? * @spec JPMS
@@ -2255,7 +2255,7 @@
 ????? *???????? this class loader; or an zero length array if no 
package has been
 ????? *???????? defined by this class loader.
 ????? *
-???? * @jvms 5.3 Run-time package
+???? * @jvms 5.3 Creation and Loading
 ????? *
 ????? * @since? 9
 ????? * @spec JPMS
--- old/src/java.base/share/classes/java/lang/Double.java 2019-05-19 
12:16:29.205761266 -0700
+++ new/src/java.base/share/classes/java/lang/Double.java 2019-05-19 
12:16:28.809761266 -0700
@@ -673,7 +673,7 @@
 ????? *
 ????? * @return? the {@code double} value represented by this object
 ????? *????????? converted to type {@code byte}
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? * @since 1.1
 ????? */
 ???? public byte byteValue() {
@@ -686,7 +686,7 @@
 ????? *
 ????? * @return? the {@code double} value represented by this object
 ????? *????????? converted to type {@code short}
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? * @since 1.1
 ????? */
 ???? public short shortValue() {
@@ -696,7 +696,7 @@
 ???? /**
 ????? * Returns the value of this {@code Double} as an {@code int}
 ????? * after a narrowing primitive conversion.
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? *
 ????? * @return? the {@code double} value represented by this object
 ????? *????????? converted to type {@code int}
@@ -711,7 +711,7 @@
 ????? *
 ????? * @return? the {@code double} value represented by this object
 ????? *????????? converted to type {@code long}
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? */
 ???? public long longValue() {
 ???????? return (long)value;
@@ -723,7 +723,7 @@
 ????? *
 ????? * @return? the {@code double} value represented by this object
 ????? *????????? converted to type {@code float}
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? * @since 1.0
 ????? */
 ???? public float floatValue() {
--- old/src/java.base/share/classes/java/lang/Float.java 2019-05-19 
12:16:30.133761266 -0700
+++ new/src/java.base/share/classes/java/lang/Float.java 2019-05-19 
12:16:29.637761266 -0700
@@ -602,7 +602,7 @@
 ????? *
 ????? * @return? the {@code float} value represented by this object
 ????? *????????? converted to type {@code byte}
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? */
 ???? public byte byteValue() {
 ???????? return (byte)value;
@@ -614,7 +614,7 @@
 ????? *
 ????? * @return? the {@code float} value represented by this object
 ????? *????????? converted to type {@code short}
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? * @since 1.1
 ????? */
 ???? public short shortValue() {
@@ -627,7 +627,7 @@
 ????? *
 ????? * @return? the {@code float} value represented by this object
 ????? *????????? converted to type {@code int}
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? */
 ???? public int intValue() {
 ???????? return (int)value;
@@ -639,7 +639,7 @@
 ????? *
 ????? * @return? the {@code float} value represented by this object
 ????? *????????? converted to type {@code long}
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? */
 ???? public long longValue() {
 ???????? return (long)value;
@@ -661,7 +661,7 @@
 ????? *
 ????? * @return the {@code float} value represented by this
 ????? *???????? object converted to type {@code double}
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public double doubleValue() {
 ???????? return (double)value;
--- old/src/java.base/share/classes/java/lang/FunctionalInterface.java 
2019-05-19 12:16:31.105761266 -0700
+++ new/src/java.base/share/classes/java/lang/FunctionalInterface.java 
2019-05-19 12:16:30.609761266 -0700
@@ -57,7 +57,7 @@
 ? * regardless of whether or not a {@code FunctionalInterface}
 ? * annotation is present on the interface declaration.
 ? *
- * @jls 4.3.2. The Class Object
+ * @jls 4.3.2 The Class Object
 ? * @jls 9.8 Functional Interfaces
 ? * @jls 9.4.3 Interface Method Body
 ? * @jls 9.6.4.9 @FunctionalInterface
--- old/src/java.base/share/classes/java/lang/Integer.java 2019-05-19 
12:16:31.997761266 -0700
+++ new/src/java.base/share/classes/java/lang/Integer.java 2019-05-19 
12:16:31.529761266 -0700
@@ -1120,7 +1120,7 @@
 ???? /**
 ????? * Returns the value of this {@code Integer} as a {@code byte}
 ????? * after a narrowing primitive conversion.
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? */
 ???? public byte byteValue() {
 ???????? return (byte)value;
@@ -1129,7 +1129,7 @@
 ???? /**
 ????? * Returns the value of this {@code Integer} as a {@code short}
 ????? * after a narrowing primitive conversion.
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? */
 ???? public short shortValue() {
 ???????? return (short)value;
@@ -1147,7 +1147,7 @@
 ???? /**
 ????? * Returns the value of this {@code Integer} as a {@code long}
 ????? * after a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? * @see Integer#toUnsignedLong(int)
 ????? */
 ???? public long longValue() {
@@ -1157,7 +1157,7 @@
 ???? /**
 ????? * Returns the value of this {@code Integer} as a {@code float}
 ????? * after a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public float floatValue() {
 ???????? return (float)value;
@@ -1166,7 +1166,7 @@
 ???? /**
 ????? * Returns the value of this {@code Integer} as a {@code double}
 ????? * after a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public double doubleValue() {
 ???????? return (double)value;
--- old/src/java.base/share/classes/java/lang/Long.java 2019-05-19 
12:16:32.785761266 -0700
+++ new/src/java.base/share/classes/java/lang/Long.java 2019-05-19 
12:16:32.369761266 -0700
@@ -1339,7 +1339,7 @@
 ???? /**
 ????? * Returns the value of this {@code Long} as a {@code byte} after
 ????? * a narrowing primitive conversion.
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? */
 ???? public byte byteValue() {
 ???????? return (byte)value;
@@ -1348,7 +1348,7 @@
 ???? /**
 ????? * Returns the value of this {@code Long} as a {@code short} after
 ????? * a narrowing primitive conversion.
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? */
 ???? public short shortValue() {
 ???????? return (short)value;
@@ -1357,7 +1357,7 @@
 ???? /**
 ????? * Returns the value of this {@code Long} as an {@code int} after
 ????? * a narrowing primitive conversion.
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? */
 ???? public int intValue() {
 ???????? return (int)value;
@@ -1375,7 +1375,7 @@
 ???? /**
 ????? * Returns the value of this {@code Long} as a {@code float} after
 ????? * a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public float floatValue() {
 ???????? return (float)value;
@@ -1384,7 +1384,7 @@
 ???? /**
 ????? * Returns the value of this {@code Long} as a {@code double}
 ????? * after a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public double doubleValue() {
 ???????? return (double)value;
--- old/src/java.base/share/classes/java/lang/Number.java 2019-05-19 
12:16:33.561761266 -0700
+++ new/src/java.base/share/classes/java/lang/Number.java 2019-05-19 
12:16:33.157761266 -0700
@@ -48,8 +48,8 @@
 ? *
 ? * @author????? Lee Boynton
 ? * @author????? Arthur van Hoff
- * @jls 5.1.2 Widening Primitive Conversions
- * @jls 5.1.3 Narrowing Primitive Conversions
+ * @jls 5.1.2 Widening Primitive Conversion
+ * @jls 5.1.3 Narrowing Primitive Conversion
 ? * @since?? 1.0
 ? */
 ?public abstract class Number implements java.io.Serializable {
--- old/src/java.base/share/classes/java/lang/Package.java 2019-05-19 
12:16:34.325761266 -0700
+++ new/src/java.base/share/classes/java/lang/Package.java 2019-05-19 
12:16:33.929761266 -0700
@@ -108,7 +108,7 @@
 ? * <em>named modules</em>.? Instead those packages are automatically 
defined
 ? * and have no specification and implementation versioning information.
 ? *
- * @jvms 5.3 Run-time package
+ * @jvms 5.3 Creation and Loading
 ? * @see <a href="{@docRoot}/../specs/jar/jar.html#package-sealing">
 ? * The JAR File Specification: Package Sealing</a>
 ? * @see ClassLoader#definePackage(String, String, String, String, 
String, String, String, URL)
--- old/src/java.base/share/classes/java/lang/Short.java 2019-05-19 
12:16:35.109761266 -0700
+++ new/src/java.base/share/classes/java/lang/Short.java 2019-05-19 
12:16:34.701761266 -0700
@@ -352,7 +352,7 @@
 ???? /**
 ????? * Returns the value of this {@code Short} as a {@code byte} after
 ????? * a narrowing primitive conversion.
-???? * @jls 5.1.3 Narrowing Primitive Conversions
+???? * @jls 5.1.3 Narrowing Primitive Conversion
 ????? */
 ???? public byte byteValue() {
 ???????? return (byte)value;
@@ -370,7 +370,7 @@
 ???? /**
 ????? * Returns the value of this {@code Short} as an {@code int} after
 ????? * a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public int intValue() {
 ???????? return (int)value;
@@ -379,7 +379,7 @@
 ???? /**
 ????? * Returns the value of this {@code Short} as a {@code long} after
 ????? * a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public long longValue() {
 ???????? return (long)value;
@@ -388,7 +388,7 @@
 ???? /**
 ????? * Returns the value of this {@code Short} as a {@code float}
 ????? * after a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public float floatValue() {
 ???????? return (float)value;
@@ -397,7 +397,7 @@
 ???? /**
 ????? * Returns the value of this {@code Short} as a {@code double}
 ????? * after a widening primitive conversion.
-???? * @jls 5.1.2 Widening Primitive Conversions
+???? * @jls 5.1.2 Widening Primitive Conversion
 ????? */
 ???? public double doubleValue() {
 ???????? return (double)value;
--- old/src/java.base/share/classes/java/lang/SuppressWarnings.java 
2019-05-19 12:16:35.933761266 -0700
+++ new/src/java.base/share/classes/java/lang/SuppressWarnings.java 
2019-05-19 12:16:35.485761266 -0700
@@ -49,7 +49,7 @@
 ? * @jls 4.8 Raw Types
 ? * @jls 4.12.2 Variables of Reference Type
 ? * @jls 5.1.9 Unchecked Conversion
- * @jls 5.5.2 Checked Casts and Unchecked Casts
+ * @jls 5.5 Casting Contexts
 ? * @jls 9.6.4.5 @SuppressWarnings
 ? */
 ?@Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, 
MODULE})
--- old/src/java.base/share/classes/java/lang/constant/Constable.java 
2019-05-19 12:16:36.717761266 -0700
+++ new/src/java.base/share/classes/java/lang/constant/Constable.java 
2019-05-19 12:16:36.285761266 -0700
@@ -59,7 +59,7 @@
 ? * method handles, but not necessarily those produced by method handle
 ? * combinators.)
 ? * @jvms 4.4 The Constant Pool
- * @jvms 4.4.10 The CONSTANT_InvokeDynamic_info Structure
+ * @jvms 4.4.10 The {@code CONSTANT_Dynamic_info} and {@code 
CONSTANT_InvokeDynamic_info} Structures
 ? *
 ? * @since 12
 ? */
--- old/src/java.base/share/classes/java/lang/reflect/Method.java 
2019-05-19 12:16:37.521761266 -0700
+++ new/src/java.base/share/classes/java/lang/reflect/Method.java 
2019-05-19 12:16:37.117761266 -0700
@@ -403,7 +403,7 @@
 ????? * @return a string describing this {@code Method}
 ????? *
 ????? * @jls 8.4.3 Method Modifiers
-???? * @jls 9.4?? Method Declarations
+???? * @jls 9.4 Method Declarations
 ????? * @jls 9.6.1 Annotation Type Elements
 ????? */
 ???? public String toString() {
@@ -474,7 +474,7 @@
 ????? * @since 1.5
 ????? *
 ????? * @jls 8.4.3 Method Modifiers
-???? * @jls 9.4?? Method Declarations
+???? * @jls 9.4 Method Declarations
 ????? * @jls 9.6.1 Annotation Type Elements
 ????? */
 ???? @Override
--- old/src/java.base/share/classes/java/lang/reflect/Modifier.java 
2019-05-19 12:16:38.353761266 -0700
+++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java 
2019-05-19 12:16:37.917761266 -0700
@@ -394,7 +394,7 @@

 ???? /**
 ????? * The Java source modifiers that can be applied to a field.
-???? * @jls 8.3.1? Field Modifiers
+???? * @jls 8.3.1 Field Modifiers
 ????? */
 ???? private static final int FIELD_MODIFIERS =
 ???????? Modifier.PUBLIC???????? | Modifier.PROTECTED??? | 
Modifier.PRIVATE |
--- 
old/src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java 
2019-05-19 12:16:39.161761266 -0700
+++ 
new/src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java 
2019-05-19 12:16:38.757761266 -0700
@@ -114,7 +114,7 @@
 ? *
 ? * @since 1.8
 ? * @jls 9.6 Annotation Types
- * @jls 9.6.3.3 @Inherited
+ * @jls 9.6.4.3 {@code @Inherited}
 ? */
 ?public interface AnnotatedConstruct {
 ???? /**
--- 
old/src/java.compiler/share/classes/javax/lang/model/element/Element.java 
2019-05-19 12:16:40.001761266 -0700
+++ 
new/src/java.compiler/share/classes/javax/lang/model/element/Element.java 
2019-05-19 12:16:39.525761266 -0700
@@ -196,7 +196,7 @@
 ????? * @see ModuleElement#getEnclosedElements
 ????? * @see Elements#getAllMembers
 ????? * @jls 8.8.9 Default Constructor
-???? * @jls 8.9 Enums
+???? * @jls 8.9 Enum Types
 ????? * @revised 9
 ????? * @spec JPMS
 ????? */
--- 
old/src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java 
2019-05-19 12:16:40.801761266 -0700
+++ 
new/src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java 
2019-05-19 12:16:40.397761266 -0700
@@ -111,7 +111,7 @@
 ????? * More specifically, an <i>inner</i> type element is any nested 
type element that
 ????? * is not {@linkplain Modifier#STATIC static}.
 ????? * @return whether or not the constant is nested
-???? * @jls 14.3 Inner Classes and Enclosing Instances
+???? * @jls 14.3 Local Class Declarations
 ????? */
 ???? public boolean isNested() {
 ???????? return this != TOP_LEVEL;
--- old/src/java.compiler/share/classes/javax/lang/model/util/Types.java 
2019-05-19 12:16:41.557761266 -0700
+++ new/src/java.compiler/share/classes/javax/lang/model/util/Types.java 
2019-05-19 12:16:41.161761266 -0700
@@ -104,7 +104,7 @@
 ????? * @return {@code true} if and only if the first type is assignable
 ????? *????????? to the second
 ????? * @throws IllegalArgumentException if given a type for an 
executable, package, or module
-???? * @jls 5.2 Assignment Conversion
+???? * @jls 5.2 Assignment Contexts
 ????? */
 ???? boolean isAssignable(TypeMirror t1, TypeMirror t2);

@@ -115,7 +115,7 @@
 ????? * @param t2? the second type
 ????? * @return {@code true} if and only if the first type contains the 
second
 ????? * @throws IllegalArgumentException if given a type for an 
executable, package, or module
-???? * @jls 4.5.1.1 Type Argument Containment and Equivalence
+???? * @jls 4.5.1 Type Arguments of Parameterized Types
 ????? */
 ???? boolean contains(TypeMirror t1, TypeMirror t2);

--- 
old/src/jdk.compiler/share/classes/com/sun/source/tree/BinaryTree.java 
2019-05-19 12:16:42.329761266 -0700
+++ 
new/src/jdk.compiler/share/classes/com/sun/source/tree/BinaryTree.java 
2019-05-19 12:16:41.929761266 -0700
@@ -40,8 +40,8 @@
 ? * @jls 15.20 Relational Operators
 ? * @jls 15.21 Equality Operators
 ? * @jls 15.22 Bitwise and Logical Operators
- * @jls 15.23 Conditional-And Operator &&
- * @jls 15.24 Conditional-Or Operator ||
+ * @jls 15.23 Conditional-And Operator {@code &&}
+ * @jls 15.24 Conditional-Or Operator {@code ||}
 ? *
 ? * @author Peter von der Ah&eacute;
 ? * @author Jonathan Gibbons
--- 
old/src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java 
2019-05-19 12:16:43.285761266 -0700
+++ 
new/src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java 
2019-05-19 12:16:42.797761266 -0700
@@ -45,7 +45,7 @@
 ? * @jls 8.5.1 Static Member Type Declarations
 ? * @jls 8.8.3 Constructor Modifiers
 ? * @jls 9.1.1 Interface Modifiers
- * @jls 9.7?? Annotations
+ * @jls 9.7 Annotations
 ? *
 ? * @author Peter von der Ah&eacute;
 ? * @author Jonathan Gibbons
--- 
old/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java 
2019-05-19 12:16:44.213761266 -0700
+++ 
new/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java 
2019-05-19 12:16:43.721761266 -0700
@@ -2733,7 +2733,7 @@
 ????? * signature</em> of the other.? This is <b>not</b> an equivalence
 ????? * relation.
 ????? *
-???? * @jls section 8.4.2.
+???? * @jls 8.4.2 Method Signature
 ????? * @see #overrideEquivalent(Type t, Type s)
 ????? * @param t first signature (possibly raw).
 ????? * @param s second signature (could be subjected to erasure).
@@ -2752,7 +2752,7 @@
 ????? * equivalence</em>.? This is the natural extension of
 ????? * isSubSignature to an equivalence relation.
 ????? *
-???? * @jls section 8.4.2.
+???? * @jls 8.4.2 Method Signature
 ????? * @see #isSubSignature(Type t, Type s)
 ????? * @param t a signature (possible raw, could be subjected to
 ????? * erasure).
@@ -4214,7 +4214,7 @@

 ???? /**
 ????? * Return-Type-Substitutable.
-???? * @jls section 8.4.5
+???? * @jls 8.4.5 Method Result
 ????? */
 ???? public boolean returnTypeSubstitutable(Type r1, Type r2) {
 ???????? if (hasSameArgs(r1, r2))
--- 
old/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java 
2019-05-19 12:16:45.077761266 -0700
+++ 
new/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java 
2019-05-19 12:16:44.657761266 -0700
@@ -4222,7 +4222,7 @@
 ????????? * @param tree??? The tree making up the variable reference.
 ????????? * @param env???? The current environment.
 ????????? * @param v?????? The variable's symbol.
-???????? * @jls? section 8.9 Enums
+???????? * @jls 8.9 Enum Types
 ????????? */
 ???????? private void checkEnumInitializer(JCTree tree, 
Env<AttrContext> env, VarSymbol v) {
 ???????????? // JLS:
--- old/src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java 
2019-05-19 12:16:45.941761266 -0700
+++ new/src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java 
2019-05-19 12:16:45.505761266 -0700
@@ -36,7 +36,7 @@
 ? * and thus is thread-safe.
 ? *
 ? * @since 9
- * @jls 15: Expression.
+ * @jls 15 Expressions
 ? */
 ?public class ExpressionSnippet extends Snippet {

--- old/src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java 
2019-05-19 12:16:47.045761266 -0700
+++ new/src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java 
2019-05-19 12:16:46.629761266 -0700
@@ -36,7 +36,7 @@
 ? * and thus is thread-safe.
 ? *
 ? * @since 9
- * @jls 8.3: importDeclaration.
+ * @jls 7.5 Import Declarations
 ? */
 ?public class ImportSnippet extends PersistentSnippet {

--- old/src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java 
2019-05-19 12:16:48.501761266 -0700
+++ new/src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java 
2019-05-19 12:16:48.093761266 -0700
@@ -37,7 +37,7 @@
 ? * and thus is thread-safe.
 ? *
 ? * @since 9
- * @jls 8.4: MethodDeclaration.
+ * @jls 8.4 Method Declarations
 ? */
 ?public class MethodSnippet extends DeclarationSnippet {

--- old/src/jdk.jshell/share/classes/jdk/jshell/Snippet.java 2019-05-19 
12:16:49.593761266 -0700
+++ new/src/jdk.jshell/share/classes/jdk/jshell/Snippet.java 2019-05-19 
12:16:49.173761266 -0700
@@ -73,7 +73,7 @@
 ????????? * ({@link 
jdk.jshell.Snippet.SubKind#SINGLE_STATIC_IMPORT_SUBKIND}) --
 ????????? * use {@link jdk.jshell.Snippet#subKind()} to distinguish.
 ????????? *
-???????? * @jls 8.3: importDeclaration.
+???????? * @jls 7.5 Import Declarations
 ????????? * <P>
 ????????? * An import declaration is {@linkplain Kind#isPersistent() 
persistent}.
 ????????? */
@@ -91,7 +91,7 @@
 ????????? * annotation interfaces -- see {@link 
jdk.jshell.Snippet.SubKind} to
 ????????? * differentiate.
 ????????? *
-???????? * @jls 7.6: TypeDeclaration.
+???????? * @jls 7.6 Top Level Type Declarations
 ????????? * <P>
 ????????? * A type declaration is {@linkplain Kind#isPersistent() 
persistent}.
 ????????? */
@@ -101,7 +101,7 @@
 ????????? * A method declaration.
 ????????? * The snippet is an instance of {@link jdk.jshell.MethodSnippet}.
 ????????? *
-???????? * @jls 8.4: MethodDeclaration.
+???????? * @jls 8.4 Method Declarations
 ????????? * <P>
 ????????? * A method declaration is {@linkplain Kind#isPersistent() 
persistent}.
 ????????? */
@@ -116,7 +116,7 @@
 ????????? * variable representing an expression -- see
 ????????? * {@link jdk.jshell.Snippet.SubKind}to differentiate.
 ????????? *
-???????? * @jls 8.3: FieldDeclaration.
+???????? * @jls 8.3 Field Declarations
 ????????? * <P>
 ????????? * A variable declaration is {@linkplain Kind#isPersistent() 
persistent}.
 ????????? */
@@ -133,7 +133,7 @@
 ????????? * All other expression forms (operators, method calls, ...) 
generate a
 ????????? * scratch variable and so are instead of the VAR Kind.
 ????????? *
-???????? * @jls 15: Expression.
+???????? * @jls 15 Expressions
 ????????? */
 ???????? EXPRESSION(false),

@@ -141,7 +141,7 @@
 ????????? * A statement.
 ????????? * The snippet is an instance of {@link 
jdk.jshell.StatementSnippet}.
 ????????? *
-???????? * @jls 14.5: Statement.
+???????? * @jls 14.5 Statements
 ????????? */
 ???????? STATEMENT(false),

@@ -185,99 +185,97 @@
 ???????? /**
 ????????? * Single-Type-Import Declaration.
 ????????? * An import declaration of a single type.
-???????? * @jls 7.5.1 SingleTypeImportDeclaration.
+???????? * @jls 7.5.1 Single-Type-Import Declarations
 ????????? */
 ???????? SINGLE_TYPE_IMPORT_SUBKIND(Kind.IMPORT),

 ???????? /**
 ????????? * Type-Import-on-Demand Declaration.
 ????????? * A non-static "star" import.
-???????? * @jls 7.5.2. TypeImportOnDemandDeclaration.
+???????? * @jls 7.5.2 Type-Import-on-Demand Declarations
 ????????? */
 ???????? TYPE_IMPORT_ON_DEMAND_SUBKIND(Kind.IMPORT),

 ???????? /**
 ????????? * Single-Static-Import Declaration.
 ????????? * An import of a static member.
-???????? * @jls 7.5.3 Single-Static-Import.
+???????? * @jls 7.5.3 Single-Static-Import Declarations
 ????????? */
 ???????? SINGLE_STATIC_IMPORT_SUBKIND(Kind.IMPORT),

 ???????? /**
 ????????? * Static-Import-on-Demand Declaration.
 ????????? * A static "star" import of all static members of a named type.
-???????? * @jls 7.5.4. Static-Import-on-Demand Static "star" import.
+???????? * @jls 7.5.4 Static-Import-on-Demand Declarations
 ????????? */
 ???????? STATIC_IMPORT_ON_DEMAND_SUBKIND(Kind.IMPORT),

 ???????? /**
 ????????? * A class declaration.
 ????????? * A {@code SubKind} of {@link Kind#TYPE_DECL}.
-???????? * @jls 8.1. NormalClassDeclaration.
+???????? * @jls 8.1 Class Declarations
 ????????? */
 ???????? CLASS_SUBKIND(Kind.TYPE_DECL),

 ???????? /**
 ????????? * An interface declaration.
 ????????? * A {@code SubKind} of {@link Kind#TYPE_DECL}.
-???????? * @jls 9.1. NormalInterfaceDeclaration.
+???????? * @jls 9.1 Interface Declarations
 ????????? */
 ???????? INTERFACE_SUBKIND(Kind.TYPE_DECL),

 ???????? /**
 ????????? * An enum declaration.
 ????????? * A {@code SubKind} of {@link Kind#TYPE_DECL}.
-???????? * @jls 8.9. EnumDeclaration.
+???????? * @jls 8.9 Enum Types
 ????????? */
 ???????? ENUM_SUBKIND(Kind.TYPE_DECL),

 ???????? /**
 ????????? * An annotation interface declaration. A {@code SubKind} of
 ????????? * {@link Kind#TYPE_DECL}.
-???????? * @jls 9.6. AnnotationTypeDeclaration.
+???????? * @jls 9.6 Annotation Types
 ????????? */
 ???????? ANNOTATION_TYPE_SUBKIND(Kind.TYPE_DECL),

 ???????? /**
 ????????? * A method. The only {@code SubKind} for {@link Kind#METHOD}.
-???????? * @jls 8.4. MethodDeclaration.
+???????? * @jls 8.4 Method Declarations
 ????????? */
 ???????? METHOD_SUBKIND(Kind.METHOD),

 ???????? /**
 ????????? * A variable declaration without initializer.
 ????????? * A {@code SubKind} of {@link Kind#VAR}.
-???????? * @jls 8.3. VariableDeclarator without VariableInitializer in
-???????? * FieldDeclaration.
+???????? * @jls 8.3 Field Declarations
 ????????? */
 ???????? VAR_DECLARATION_SUBKIND(Kind.VAR, true, true),

 ???????? /**
 ????????? * A variable declaration with an initializer expression. A
 ????????? * {@code SubKind} of {@link Kind#VAR}.
-???????? * @jls 8.3. VariableDeclarator with VariableInitializer in
-???????? * FieldDeclaration.
+???????? * @jls 8.3 Field Declarations
 ????????? */
 ???????? VAR_DECLARATION_WITH_INITIALIZER_SUBKIND(Kind.VAR, true, true),

 ???????? /**
 ????????? * An expression whose value has been stored in a temporary 
variable. A
 ????????? * {@code SubKind} of {@link Kind#VAR}.
-???????? * @jls 15. Primary.
+???????? * @jls 15 Expressions
 ????????? */
 ???????? TEMP_VAR_EXPRESSION_SUBKIND(Kind.VAR, true, true),

 ???????? /**
 ????????? * A simple variable reference expression. A {@code SubKind} of
 ????????? * {@link Kind#EXPRESSION}.
-???????? * @jls 15.11. Field Access as 3.8. Identifier.
+???????? * @jls 15.11 Field Access Expressions
 ????????? */
 ???????? VAR_VALUE_SUBKIND(Kind.EXPRESSION, true, true),

 ???????? /**
 ????????? * An assignment expression. A {@code SubKind} of
 ????????? * {@link Kind#EXPRESSION}.
-???????? * @jls 15.26. Assignment.
+???????? * @jls 15.26 Assignment Operators
 ????????? */
 ???????? ASSIGNMENT_SUBKIND(Kind.EXPRESSION, true, true),

@@ -289,7 +287,7 @@

 ???????? /**
 ????????? * A statement. The only {@code SubKind} for {@link 
Kind#STATEMENT}.
-???????? * @jls 14.5. Statement.
+???????? * @jls 14.5 Statements
 ????????? */
 ???????? STATEMENT_SUBKIND(Kind.STATEMENT, true, false),

--- old/src/jdk.jshell/share/classes/jdk/jshell/StatementSnippet.java 
2019-05-19 12:16:50.421761266 -0700
+++ new/src/jdk.jshell/share/classes/jdk/jshell/StatementSnippet.java 
2019-05-19 12:16:49.985761266 -0700
@@ -36,7 +36,7 @@
 ? * and thus is thread-safe.
 ? *
 ? * @since 9
- * @jls 14.5: Statement.
+ * @jls 14.5 Statements
 ? */
 ?public class StatementSnippet extends Snippet {

--- old/src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java 
2019-05-19 12:16:51.549761266 -0700
+++ new/src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java 
2019-05-19 12:16:51.117761266 -0700
@@ -39,7 +39,7 @@
 ? * and thus is thread-safe.
 ? *
 ? * @since 9
- * @jls 8.3: FieldDeclaration.
+ * @jls 8.3 Field Declarations
 ? */
 ?public class VarSnippet extends DeclarationSnippet {



From peter.levart at gmail.com  Mon May 20 06:17:04 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 20 May 2019 08:17:04 +0200
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <f6d01fe9-fc58-5c42-1089-7e282a574241@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
 <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>
 <fedb1d4d-3284-8acd-c598-edc003b3e7a5@oracle.com>
 <a6b73d24-3174-0f2d-8dc7-4011183b00ce@oracle.com>
 <80c054be-4a23-7851-ba1b-a00b9bd9cc47@oracle.com>
 <f6d01fe9-fc58-5c42-1089-7e282a574241@oracle.com>
Message-ID: <ebdbe8f3-b108-0ce9-38b3-d154d96f8d8b@gmail.com>

Hi Ivan, Roger,

What about "calcNewLength" ?

The word "new" gives enough hint as to what the method does - it 
calculates the length of new array to be allocated instead of old one.

Regards, Peter

On 5/17/19 8:45 PM, Ivan Gerasimov wrote:
> Hi Roger!
>
> I think that not only the name, but also the arguments compose the 
> signature.
> So, calcLength(oldLength, minGrowth, prefGrowth) is meant to be read 
> as "given old length and the amount(s) to grow, calculate the new 
> length".
> And since this method is placed into ArraysSupport, it should be clear 
> that it is an array's length.
>
> I understand that in certain contexts size may sound more natural than 
> length.
> Here, however, using 'length' should be a hint that we're dealing with 
> array.length.
>
> With kind regards,
> Ivan
>
> On 5/17/19 10:35 AM, Roger Riggs wrote:
>> Hi Ivan,
>>
>> The new calcLength method name is too generic, it does not say enough 
>> about its function.
>> There is no indication that the purpose is to resize an array.
>> As for size vs length, sometime size is more evocative of the 
>> function being performed
>> than 'length' and is more natural.? In most cases, size and length 
>> are understood to be synonyms
>> and capacity is a very apt term for how many elements can be held.
>>
>> Can I recommend resizedLength.
>>
>> Regards, Roger
>>
>>
>>
>> On 05/15/2019 10:47 PM, Ivan Gerasimov wrote:
>>> Thank you Pavel and Roger for reviewing!
>>>
>>> I apologize for reiterating this.
>>> After off-line discussion with Stuart Marks, the fix was modified 
>>> once again.
>> !!
>>> The modifications were mostly stylistic:? The used terminology now 
>>> reflects that we work with arrays (thus 'length', not 'size' or 
>>> 'capacity').
>>> Functionally, the fix remains exactly the same.
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/02/webrev/
>>>
>>> With kind regards,
>>> Ivan
>>>
>>> On 5/14/19 7:50 AM, Roger Riggs wrote:
>>>> Hi Ivan,
>>>>
>>>> The updated patch looks fine.
>>>>
>>>> Strictly speaking, the change to Files.readAllBytes is not 
>>>> indicated by the bug report
>>>> so please update or comment on the bug report to mention that change.
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>> On 05/13/2019 10:44 AM, Pavel Rappo wrote:
>>>>> Thanks for updating your patch. The updated code seems fine.
>>>>>
>>>>> -Pavel
>>>>>
>>>>>> On 11 May 2019, at 05:01, Ivan 
>>>>>> Gerasimov<ivan.gerasimov at oracle.com>? wrote:
>>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> Please help review the updated fix.
>>>>>>
>>>>>> This new webrev includes changes suggested by Pavel, Peter and 
>>>>>> Roger.
>>>>>>
>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
>>>>>>
>>>>>> Please note that the behavior of j.n.f.Files.readAllBytes() has 
>>>>>> changed slightly, so now it *may* be possible to read a file 
>>>>>> larger than (Integer.MAX_VALUE - 8), if VM is able to allocate 
>>>>>> that large array.
>>>>>>
>>>>>> With kind regards,
>>>>>> Ivan
>>>>>>
>>>>>> On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
>>>>>>> Hello!
>>>>>>>
>>>>>>> Jdk has several places with similar logic:? an array needs to be 
>>>>>>> reallocated (by at least some defined amount), taking into 
>>>>>>> account the maximum allowed size of arrays.
>>>>>>>
>>>>>>> There's clearly an opportunity for refactoring, so it is 
>>>>>>> proposed to introduce a dedicated utility method for calculating 
>>>>>>> the best new size of an array.
>>>>>>>
>>>>>>> Would you please help review this enhancement?
>>>>>>>
>>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>>>>>>>
>>>>>>> Mach5 job ran fine.
>>>>>>>
>>>>>>> Thanks in advance!
>>>>>>>
>>>>>> -- 
>>>>>> With kind regards,
>>>>>> Ivan Gerasimov
>>>>>>
>>>>
>>>
>>> -- 
>>> With kind regards,
>>> Ivan Gerasimov
>>
>


From jon.harper87 at gmail.com  Fri May 17 10:06:36 2019
From: jon.harper87 at gmail.com (Jon Harper)
Date: Fri, 17 May 2019 12:06:36 +0200
Subject: jpackage: better error messages when things go wrong ?
Message-ID: <CAK8-Ou9mKUxFm+cYMtOr-t8p9sjjm56et2kmVa2WMveADB2E4Q@mail.gmail.com>

Many things can go wrong when launching an app package with jpackage
(1). If the app doesn't work enough to get basic logging, then the
only error message you get is
"Failed to launch JVM" (with javapackager form jdk 8 you also had
"Error Invoking Method"..)

I think it would be a great improvement if more explicit error message
could be shown so that users can provide more details to developers
trying to fix their problems. In almost all cases I saw, there was a
java exception associated with the problem and its message and
stacktrace allowed very easy debugging.

On windows, could the message use the same structure as
https://docs.microsoft.com/en-us/windows/desktop/uxguide/images/mess-error-image43.png
( from the article
https://docs.microsoft.com/en-us/windows/desktop/uxguide/mess-error )
to show the actual Exception, its message and stacktrace in the
details ?

Cheers,
Jon

(1):
A non exhaustive list of problems where an Exception and it's message
(not even the stacktrace) allow to diagnose the problem instantly. The
point is not to highlight these bugs in particular, just that some
problems will always happen.
- maybe your image links to a high glibc version?
https://bugzilla.redhat.com/show_bug.cgi?id=1700927 (
java.lang.UnsatisfiedLinkError:
/tmp/gse-fedo/runtime/lib/amd64/libnio.so:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found )
- maybe you have spaces in your paths:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060096.html
- maybe your favorite dependency management tool produced a broken
classpath and some vital jars are missing (ClassNotFoundException:
FooBar)
- maybe the jpackage your are using has a bug and produces a broken
image https://bugzilla.redhat.com/show_bug.cgi?id=1700884 (
FileNotFoundException: tzdb.dat)

Note: This is from javapackager from jdk8 from which the behavior in
jpackage is inherited.

Jon

From jon.harper87 at gmail.com  Fri May 17 10:16:27 2019
From: jon.harper87 at gmail.com (Jon Harper)
Date: Fri, 17 May 2019 12:16:27 +0200
Subject: jpackage: uniform error messages on different platforms
Message-ID: <CAK8-Ou_ELd_SKM3XywJCar2coM9teuxFwsqHnw8jKWP6jrpSgg@mail.gmail.com>

when things go wrong launching an app packaged with jpackage, the
behavior is different accross platform:
- on windows it show a popup
- on other platforms it logs to stdout

I think it would be better if the behavior was consistent:
- provide popups on other platforms when the program is launched from
a file explorer
- provide messages on the console on windows when there is one.

Maybe all this can be autodetected, or maybe it should there should be
a global --console (like --winconsole today) that cotnrols how the
error messages are displayed ?

Cheers,
Jon

From ivan.gerasimov at oracle.com  Mon May 20 09:11:22 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 20 May 2019 02:11:22 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <ebdbe8f3-b108-0ce9-38b3-d154d96f8d8b@gmail.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
 <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>
 <fedb1d4d-3284-8acd-c598-edc003b3e7a5@oracle.com>
 <a6b73d24-3174-0f2d-8dc7-4011183b00ce@oracle.com>
 <80c054be-4a23-7851-ba1b-a00b9bd9cc47@oracle.com>
 <f6d01fe9-fc58-5c42-1089-7e282a574241@oracle.com>
 <ebdbe8f3-b108-0ce9-38b3-d154d96f8d8b@gmail.com>
Message-ID: <963e71b7-4d1d-79cf-45a6-d5e2e813885b@oracle.com>

Hi Peter!


On 5/19/19 11:17 PM, Peter Levart wrote:
> Hi Ivan, Roger,
>
> What about "calcNewLength" ?
>
> The word "new" gives enough hint as to what the method does - it 
> calculates the length of new array to be allocated instead of old one.
>
Yes, I think it was one of intermediate names.
But then, it seemed that the New part is redundant, as it does not add 
much:  "calculate length" and "calculate new length" sound very similar, 
while the former is shorter.

With kind regards,
Ivan

> Regards, Peter
>
> On 5/17/19 8:45 PM, Ivan Gerasimov wrote:
>> Hi Roger!
>>
>> I think that not only the name, but also the arguments compose the 
>> signature.
>> So, calcLength(oldLength, minGrowth, prefGrowth) is meant to be read 
>> as "given old length and the amount(s) to grow, calculate the new 
>> length".
>> And since this method is placed into ArraysSupport, it should be 
>> clear that it is an array's length.
>>
>> I understand that in certain contexts size may sound more natural 
>> than length.
>> Here, however, using 'length' should be a hint that we're dealing 
>> with array.length.
>>
>> With kind regards,
>> Ivan
>>
>> On 5/17/19 10:35 AM, Roger Riggs wrote:
>>> Hi Ivan,
>>>
>>> The new calcLength method name is too generic, it does not say 
>>> enough about its function.
>>> There is no indication that the purpose is to resize an array.
>>> As for size vs length, sometime size is more evocative of the 
>>> function being performed
>>> than 'length' and is more natural.  In most cases, size and length 
>>> are understood to be synonyms
>>> and capacity is a very apt term for how many elements can be held.
>>>
>>> Can I recommend resizedLength.
>>>
>>> Regards, Roger
>>>
>>>
>>>
>>> On 05/15/2019 10:47 PM, Ivan Gerasimov wrote:
>>>> Thank you Pavel and Roger for reviewing!
>>>>
>>>> I apologize for reiterating this.
>>>> After off-line discussion with Stuart Marks, the fix was modified 
>>>> once again.
>>> !!
>>>> The modifications were mostly stylistic:  The used terminology now 
>>>> reflects that we work with arrays (thus 'length', not 'size' or 
>>>> 'capacity').
>>>> Functionally, the fix remains exactly the same.
>>>>
>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/02/webrev/
>>>>
>>>> With kind regards,
>>>> Ivan
>>>>
>>>> On 5/14/19 7:50 AM, Roger Riggs wrote:
>>>>> Hi Ivan,
>>>>>
>>>>> The updated patch looks fine.
>>>>>
>>>>> Strictly speaking, the change to Files.readAllBytes is not 
>>>>> indicated by the bug report
>>>>> so please update or comment on the bug report to mention that change.
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>> On 05/13/2019 10:44 AM, Pavel Rappo wrote:
>>>>>> Thanks for updating your patch. The updated code seems fine.
>>>>>>
>>>>>> -Pavel
>>>>>>
>>>>>>> On 11 May 2019, at 05:01, Ivan 
>>>>>>> Gerasimov<ivan.gerasimov at oracle.com>  wrote:
>>>>>>>
>>>>>>> Hello!
>>>>>>>
>>>>>>> Please help review the updated fix.
>>>>>>>
>>>>>>> This new webrev includes changes suggested by Pavel, Peter and 
>>>>>>> Roger.
>>>>>>>
>>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
>>>>>>>
>>>>>>> Please note that the behavior of j.n.f.Files.readAllBytes() has 
>>>>>>> changed slightly, so now it *may* be possible to read a file 
>>>>>>> larger than (Integer.MAX_VALUE - 8), if VM is able to allocate 
>>>>>>> that large array.
>>>>>>>
>>>>>>> With kind regards,
>>>>>>> Ivan
>>>>>>>
>>>>>>> On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> Jdk has several places with similar logic:  an array needs to 
>>>>>>>> be reallocated (by at least some defined amount), taking into 
>>>>>>>> account the maximum allowed size of arrays.
>>>>>>>>
>>>>>>>> There's clearly an opportunity for refactoring, so it is 
>>>>>>>> proposed to introduce a dedicated utility method for 
>>>>>>>> calculating the best new size of an array.
>>>>>>>>
>>>>>>>> Would you please help review this enhancement?
>>>>>>>>
>>>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>>>>>>>>
>>>>>>>> Mach5 job ran fine.
>>>>>>>>
>>>>>>>> Thanks in advance!
>>>>>>>>
>>>>>>> -- 
>>>>>>> With kind regards,
>>>>>>> Ivan Gerasimov
>>>>>>>
>>>>>
>>>>
>>>> -- 
>>>> With kind regards,
>>>> Ivan Gerasimov
>>>
>>
>
>

-- 
With kind regards,
Ivan Gerasimov


From peter.levart at gmail.com  Mon May 20 10:14:16 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 20 May 2019 12:14:16 +0200
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <963e71b7-4d1d-79cf-45a6-d5e2e813885b@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
 <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>
 <fedb1d4d-3284-8acd-c598-edc003b3e7a5@oracle.com>
 <a6b73d24-3174-0f2d-8dc7-4011183b00ce@oracle.com>
 <80c054be-4a23-7851-ba1b-a00b9bd9cc47@oracle.com>
 <f6d01fe9-fc58-5c42-1089-7e282a574241@oracle.com>
 <ebdbe8f3-b108-0ce9-38b3-d154d96f8d8b@gmail.com>
 <963e71b7-4d1d-79cf-45a6-d5e2e813885b@oracle.com>
Message-ID: <378e0a23-233b-9948-2fad-6c69379c4bfb@gmail.com>



On 5/20/19 11:11 AM, Ivan Gerasimov wrote:
> Hi Peter!
>
>
> On 5/19/19 11:17 PM, Peter Levart wrote:
>> Hi Ivan, Roger,
>>
>> What about "calcNewLength" ?
>>
>> The word "new" gives enough hint as to what the method does - it 
>> calculates the length of new array to be allocated instead of old one.
>>
> Yes, I think it was one of intermediate names.
> But then, it seemed that the New part is redundant, as it does not add 
> much:? "calculate length" and "calculate new length" sound very 
> similar, while the former is shorter.

I feel it does add a tiny bit to clarity. This is internal API, so it's 
not that important, and from its use it is immediately obvious what's 
going on, but even you felt that saying:

 > calcLength(oldLength, minGrowth, prefGrowth) is meant to be read as 
"given old length and the amount(s) to grow, calculate the new length"

is more clear than:

 > calcLength(oldLength, minGrowth, prefGrowth) is meant to be read as 
"given old length and the amount(s) to grow, calculate the length"

If a word is redundant then it is "calc". It is obvious that any 
function calculates something. So what about "newLength()" ?

Regards, Peter

>
> With kind regards,
> Ivan
>
>> Regards, Peter
>>
>> On 5/17/19 8:45 PM, Ivan Gerasimov wrote:
>>> Hi Roger!
>>>
>>> I think that not only the name, but also the arguments compose the 
>>> signature.
>>> So, calcLength(oldLength, minGrowth, prefGrowth) is meant to be read 
>>> as "given old length and the amount(s) to grow, calculate the new 
>>> length".
>>> And since this method is placed into ArraysSupport, it should be 
>>> clear that it is an array's length.
>>>
>>> I understand that in certain contexts size may sound more natural 
>>> than length.
>>> Here, however, using 'length' should be a hint that we're dealing 
>>> with array.length.
>>>
>>> With kind regards,
>>> Ivan
>>>
>>> On 5/17/19 10:35 AM, Roger Riggs wrote:
>>>> Hi Ivan,
>>>>
>>>> The new calcLength method name is too generic, it does not say 
>>>> enough about its function.
>>>> There is no indication that the purpose is to resize an array.
>>>> As for size vs length, sometime size is more evocative of the 
>>>> function being performed
>>>> than 'length' and is more natural.? In most cases, size and length 
>>>> are understood to be synonyms
>>>> and capacity is a very apt term for how many elements can be held.
>>>>
>>>> Can I recommend resizedLength.
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>>
>>>> On 05/15/2019 10:47 PM, Ivan Gerasimov wrote:
>>>>> Thank you Pavel and Roger for reviewing!
>>>>>
>>>>> I apologize for reiterating this.
>>>>> After off-line discussion with Stuart Marks, the fix was modified 
>>>>> once again.
>>>> !!
>>>>> The modifications were mostly stylistic:? The used terminology now 
>>>>> reflects that we work with arrays (thus 'length', not 'size' or 
>>>>> 'capacity').
>>>>> Functionally, the fix remains exactly the same.
>>>>>
>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/02/webrev/
>>>>>
>>>>> With kind regards,
>>>>> Ivan
>>>>>
>>>>> On 5/14/19 7:50 AM, Roger Riggs wrote:
>>>>>> Hi Ivan,
>>>>>>
>>>>>> The updated patch looks fine.
>>>>>>
>>>>>> Strictly speaking, the change to Files.readAllBytes is not 
>>>>>> indicated by the bug report
>>>>>> so please update or comment on the bug report to mention that 
>>>>>> change.
>>>>>>
>>>>>> Thanks, Roger
>>>>>>
>>>>>>
>>>>>> On 05/13/2019 10:44 AM, Pavel Rappo wrote:
>>>>>>> Thanks for updating your patch. The updated code seems fine.
>>>>>>>
>>>>>>> -Pavel
>>>>>>>
>>>>>>>> On 11 May 2019, at 05:01, Ivan 
>>>>>>>> Gerasimov<ivan.gerasimov at oracle.com>? wrote:
>>>>>>>>
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> Please help review the updated fix.
>>>>>>>>
>>>>>>>> This new webrev includes changes suggested by Pavel, Peter and 
>>>>>>>> Roger.
>>>>>>>>
>>>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
>>>>>>>>
>>>>>>>> Please note that the behavior of j.n.f.Files.readAllBytes() has 
>>>>>>>> changed slightly, so now it *may* be possible to read a file 
>>>>>>>> larger than (Integer.MAX_VALUE - 8), if VM is able to allocate 
>>>>>>>> that large array.
>>>>>>>>
>>>>>>>> With kind regards,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>> On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> Jdk has several places with similar logic:? an array needs to 
>>>>>>>>> be reallocated (by at least some defined amount), taking into 
>>>>>>>>> account the maximum allowed size of arrays.
>>>>>>>>>
>>>>>>>>> There's clearly an opportunity for refactoring, so it is 
>>>>>>>>> proposed to introduce a dedicated utility method for 
>>>>>>>>> calculating the best new size of an array.
>>>>>>>>>
>>>>>>>>> Would you please help review this enhancement?
>>>>>>>>>
>>>>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>>>>>>>>>
>>>>>>>>> Mach5 job ran fine.
>>>>>>>>>
>>>>>>>>> Thanks in advance!
>>>>>>>>>
>>>>>>>> -- 
>>>>>>>> With kind regards,
>>>>>>>> Ivan Gerasimov
>>>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> With kind regards,
>>>>> Ivan Gerasimov
>>>>
>>>
>>
>>
>


From ivan.gerasimov at oracle.com  Mon May 20 10:45:52 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 20 May 2019 03:45:52 -0700
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <378e0a23-233b-9948-2fad-6c69379c4bfb@gmail.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
 <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>
 <fedb1d4d-3284-8acd-c598-edc003b3e7a5@oracle.com>
 <a6b73d24-3174-0f2d-8dc7-4011183b00ce@oracle.com>
 <80c054be-4a23-7851-ba1b-a00b9bd9cc47@oracle.com>
 <f6d01fe9-fc58-5c42-1089-7e282a574241@oracle.com>
 <ebdbe8f3-b108-0ce9-38b3-d154d96f8d8b@gmail.com>
 <963e71b7-4d1d-79cf-45a6-d5e2e813885b@oracle.com>
 <378e0a23-233b-9948-2fad-6c69379c4bfb@gmail.com>
Message-ID: <332cfd22-ea11-0415-acdf-3c128d01b788@oracle.com>

Hi Peter!


On 5/20/19 3:14 AM, Peter Levart wrote:
>
>
> On 5/20/19 11:11 AM, Ivan Gerasimov wrote:
>> Hi Peter!
>>
>>
>> On 5/19/19 11:17 PM, Peter Levart wrote:
>>> Hi Ivan, Roger,
>>>
>>> What about "calcNewLength" ?
>>>
>>> The word "new" gives enough hint as to what the method does - it 
>>> calculates the length of new array to be allocated instead of old one.
>>>
>> Yes, I think it was one of intermediate names.
>> But then, it seemed that the New part is redundant, as it does not 
>> add much:  "calculate length" and "calculate new length" sound very 
>> similar, while the former is shorter.
>
> I feel it does add a tiny bit to clarity. This is internal API, so 
> it's not that important, and from its use it is immediately obvious 
> what's going on, but even you felt that saying:
>
> > calcLength(oldLength, minGrowth, prefGrowth) is meant to be read as 
> "given old length and the amount(s) to grow, calculate the new length"
>
> is more clear than:
>
> > calcLength(oldLength, minGrowth, prefGrowth) is meant to be read as 
> "given old length and the amount(s) to grow, calculate the length"
>
> If a word is redundant then it is "calc". It is obvious that any 
> function calculates something. So what about "newLength()" ?
>
:-)
I'm fine with newLength, as it's even shorter than calcLength.

I agree with you that it's obvious from its usage what it's doing. And 
the javadoc of this method and comments for the arguments make it 
absolutely clear.

I can rename it before pushing, if I hear no other objections.

With kind regards,
Ivan

> Regards, Peter
>
>>
>> With kind regards,
>> Ivan
>>
>>> Regards, Peter
>>>
>>> On 5/17/19 8:45 PM, Ivan Gerasimov wrote:
>>>> Hi Roger!
>>>>
>>>> I think that not only the name, but also the arguments compose the 
>>>> signature.
>>>> So, calcLength(oldLength, minGrowth, prefGrowth) is meant to be 
>>>> read as "given old length and the amount(s) to grow, calculate the 
>>>> new length".
>>>> And since this method is placed into ArraysSupport, it should be 
>>>> clear that it is an array's length.
>>>>
>>>> I understand that in certain contexts size may sound more natural 
>>>> than length.
>>>> Here, however, using 'length' should be a hint that we're dealing 
>>>> with array.length.
>>>>
>>>> With kind regards,
>>>> Ivan
>>>>
>>>> On 5/17/19 10:35 AM, Roger Riggs wrote:
>>>>> Hi Ivan,
>>>>>
>>>>> The new calcLength method name is too generic, it does not say 
>>>>> enough about its function.
>>>>> There is no indication that the purpose is to resize an array.
>>>>> As for size vs length, sometime size is more evocative of the 
>>>>> function being performed
>>>>> than 'length' and is more natural.  In most cases, size and length 
>>>>> are understood to be synonyms
>>>>> and capacity is a very apt term for how many elements can be held.
>>>>>
>>>>> Can I recommend resizedLength.
>>>>>
>>>>> Regards, Roger
>>>>>
>>>>>
>>>>>
>>>>> On 05/15/2019 10:47 PM, Ivan Gerasimov wrote:
>>>>>> Thank you Pavel and Roger for reviewing!
>>>>>>
>>>>>> I apologize for reiterating this.
>>>>>> After off-line discussion with Stuart Marks, the fix was modified 
>>>>>> once again.
>>>>> !!
>>>>>> The modifications were mostly stylistic:  The used terminology 
>>>>>> now reflects that we work with arrays (thus 'length', not 'size' 
>>>>>> or 'capacity').
>>>>>> Functionally, the fix remains exactly the same.
>>>>>>
>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/02/webrev/
>>>>>>
>>>>>> With kind regards,
>>>>>> Ivan
>>>>>>
>>>>>> On 5/14/19 7:50 AM, Roger Riggs wrote:
>>>>>>> Hi Ivan,
>>>>>>>
>>>>>>> The updated patch looks fine.
>>>>>>>
>>>>>>> Strictly speaking, the change to Files.readAllBytes is not 
>>>>>>> indicated by the bug report
>>>>>>> so please update or comment on the bug report to mention that 
>>>>>>> change.
>>>>>>>
>>>>>>> Thanks, Roger
>>>>>>>
>>>>>>>
>>>>>>> On 05/13/2019 10:44 AM, Pavel Rappo wrote:
>>>>>>>> Thanks for updating your patch. The updated code seems fine.
>>>>>>>>
>>>>>>>> -Pavel
>>>>>>>>
>>>>>>>>> On 11 May 2019, at 05:01, Ivan 
>>>>>>>>> Gerasimov<ivan.gerasimov at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> Please help review the updated fix.
>>>>>>>>>
>>>>>>>>> This new webrev includes changes suggested by Pavel, Peter and 
>>>>>>>>> Roger.
>>>>>>>>>
>>>>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
>>>>>>>>>
>>>>>>>>> Please note that the behavior of j.n.f.Files.readAllBytes() 
>>>>>>>>> has changed slightly, so now it *may* be possible to read a 
>>>>>>>>> file larger than (Integer.MAX_VALUE - 8), if VM is able to 
>>>>>>>>> allocate that large array.
>>>>>>>>>
>>>>>>>>> With kind regards,
>>>>>>>>> Ivan
>>>>>>>>>
>>>>>>>>> On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
>>>>>>>>>> Hello!
>>>>>>>>>>
>>>>>>>>>> Jdk has several places with similar logic:  an array needs to 
>>>>>>>>>> be reallocated (by at least some defined amount), taking into 
>>>>>>>>>> account the maximum allowed size of arrays.
>>>>>>>>>>
>>>>>>>>>> There's clearly an opportunity for refactoring, so it is 
>>>>>>>>>> proposed to introduce a dedicated utility method for 
>>>>>>>>>> calculating the best new size of an array.
>>>>>>>>>>
>>>>>>>>>> Would you please help review this enhancement?
>>>>>>>>>>
>>>>>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>>>>>>>>>>
>>>>>>>>>> Mach5 job ran fine.
>>>>>>>>>>
>>>>>>>>>> Thanks in advance!
>>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> With kind regards,
>>>>>>>>> Ivan Gerasimov
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> With kind regards,
>>>>>> Ivan Gerasimov
>>>>>
>>>>
>>>
>>>
>>
>
>

-- 
With kind regards,
Ivan Gerasimov


From roger.riggs at oracle.com  Mon May 20 13:00:02 2019
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 20 May 2019 09:00:02 -0400
Subject: JDK 13 RFR of JDK-8224174: java.lang.Number has a default
 constructor
In-Reply-To: <a41e25f6-1df5-201e-1ada-dff377443783@oracle.com>
References: <a41e25f6-1df5-201e-1ada-dff377443783@oracle.com>
Message-ID: <260e1f61-63f2-c641-fb87-ced3354fd3a7@oracle.com>

Hi Joe,

Looks fine.

Should the bug be labeled noreg-doc?

Is this worthy of a CSR? It seems like make-work except that it does change
the formal Java SE spec that is generated from javadoc.

Roger

On 5/19/19 3:09 PM, Joe Darcy wrote:
> Hello,
>
> While doing some other work, I noticed that java.lang.Number relies on 
> an implicit default constructor. Until there is a lint warning to find 
> these cases systematically (JDK-8071961: Add javac lint warning when a 
> default constructor is created), please review the diff below to 
> address this particular instance.
>
> Thanks,
>
> -Joe
>
>
> ?public abstract class Number implements java.io.Serializable {
> ???? /**
> +???? * Constructor for subclasses to call.
> +???? */
> +??? public Number() {super();}
> +
> +??? /**
>


From thomas.stuefe at gmail.com  Mon May 20 14:15:34 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 20 May 2019 16:15:34 +0200
Subject: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to
 exec() jspawnhelper does not result in an error
Message-ID: <CAA-vtUwEu7RSL7vdQuzGziopQvUXomSLEOsFaDjzSQvxL5uvZA@mail.gmail.com>

Hi all,

(old mail thread:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html)

May I please have your reviews and opinions for the following bug fix:

issue: https://bugs.openjdk.java.net/browse/JDK-8223777
cr:
http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error-alternate-impl/webrev.00/webrev/

---

The fix implements Florians proposal: the jspawnhelper will signal its
aliveness to the parent process the moment it gains control. If the parent
process does not get the signal, it assumes exec'ing the jspawnhelper never
worked.

I only do this for posix_spawn mode, out of cautiousness.

(Note that I kept the fix as minimal as possible. I found a minor bug and
some improvement possibilities and opened follow up issues to track them:
JDK-8224180 and JDK-8224181).

Thanks, Thomas

From fweimer at redhat.com  Mon May 20 14:24:31 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 20 May 2019 16:24:31 +0200
Subject: RFR(s): (new approach) 8223777: In posix_spawn mode,
 failing to exec() jspawnhelper does not result in an error
In-Reply-To: <CAA-vtUwEu7RSL7vdQuzGziopQvUXomSLEOsFaDjzSQvxL5uvZA@mail.gmail.com>
 ("Thomas \=\?utf-8\?Q\?St\=C3\=BCfe\=22's\?\= message of "Mon,
 20 May 2019 16:15:34 +0200")
References: <CAA-vtUwEu7RSL7vdQuzGziopQvUXomSLEOsFaDjzSQvxL5uvZA@mail.gmail.com>
Message-ID: <87ef4ti4ps.fsf@oldenburg2.str.redhat.com>

* Thomas St?fe:

> Hi all,
>
> (old mail thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html)
>
> May I please have your reviews and opinions for the following bug fix:
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8223777
> cr: http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error-alternate-impl/webrev.00/webrev/
>
> ---

I wonder if you should use 0 as the value for CHILD_IS_ALIVE.  All
integers could be valid errno values.  But if you check for errors from
the restartableWrite call (and call _exit), I don't think there is a
risk of confusion, so the value does not have to be distinct.

Thanks,
Florian

From alexey.semenyuk at oracle.com  Mon May 20 15:27:30 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 20 May 2019 11:27:30 -0400
Subject: RFR: JDK-8224222: Inno setup 6 broke jpackage
Message-ID: <00d2aaa2-db60-cd20-f7a0-77f988632718@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).

- Improve code detecting version of Inno Setup to make it work with Inno 
Setup v6 updates.

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

[2] http://cr.openjdk.java.net/~asemenyuk/8224222/webrev.00/

Thanks,
Alexey

From joe.darcy at oracle.com  Mon May 20 15:58:18 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 20 May 2019 08:58:18 -0700
Subject: JDK 13 RFR of JDK-8224174: java.lang.Number has a default
 constructor
In-Reply-To: <260e1f61-63f2-c641-fb87-ced3354fd3a7@oracle.com>
References: <a41e25f6-1df5-201e-1ada-dff377443783@oracle.com>
 <260e1f61-63f2-c641-fb87-ced3354fd3a7@oracle.com>
Message-ID: <446f1162-a584-d04a-e1db-ec7a11475aa7@oracle.com>

Hi Roger,

On 5/20/2019 6:00 AM, Roger Riggs wrote:
> Hi Joe,
>
> Looks fine.
>
> Should the bug be labeled noreg-doc?


Sure; I wasn't planning to write any tests for it.


>
> Is this worthy of a CSR? It seems like make-work except that it does 
> change
> the formal Java SE spec that is generated from javadoc.

Fair point; new CSR at:

 ??? https://bugs.openjdk.java.net/browse/JDK-8224232

Thanks for the review,

-Joe



From brian.burkhalter at oracle.com  Mon May 20 16:20:06 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 20 May 2019 09:20:06 -0700
Subject: JDK 13 RFR of JDK-8224174: java.lang.Number has a default
 constructor
In-Reply-To: <446f1162-a584-d04a-e1db-ec7a11475aa7@oracle.com>
References: <a41e25f6-1df5-201e-1ada-dff377443783@oracle.com>
 <260e1f61-63f2-c641-fb87-ced3354fd3a7@oracle.com>
 <446f1162-a584-d04a-e1db-ec7a11475aa7@oracle.com>
Message-ID: <906E0572-4CA2-4FC9-B338-A4DF7DBD2FEA@oracle.com>

Hi Joe,

> On May 20, 2019, at 8:58 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
>> Looks fine.

+1

>> Is this worthy of a CSR? It seems like make-work except that it does change
>> the formal Java SE spec that is generated from javadoc.
> 
> Fair point; new CSR at:
> 
>     https://bugs.openjdk.java.net/browse/JDK-8224232 <https://bugs.openjdk.java.net/browse/JDK-8224232>
Reviewed.

Brian

From Roger.Riggs at oracle.com  Mon May 20 16:59:06 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 20 May 2019 12:59:06 -0400
Subject: RFR 8223593 : Refactor code for reallocating storage
In-Reply-To: <332cfd22-ea11-0415-acdf-3c128d01b788@oracle.com>
References: <026582f7-7513-431b-d86d-0a2fd24cab39@oracle.com>
 <64b291a4-75a2-0c2c-c4d7-ff335601bd17@oracle.com>
 <A843B114-E050-4C6A-9A07-11922CB691D4@oracle.com>
 <fedb1d4d-3284-8acd-c598-edc003b3e7a5@oracle.com>
 <a6b73d24-3174-0f2d-8dc7-4011183b00ce@oracle.com>
 <80c054be-4a23-7851-ba1b-a00b9bd9cc47@oracle.com>
 <f6d01fe9-fc58-5c42-1089-7e282a574241@oracle.com>
 <ebdbe8f3-b108-0ce9-38b3-d154d96f8d8b@gmail.com>
 <963e71b7-4d1d-79cf-45a6-d5e2e813885b@oracle.com>
 <378e0a23-233b-9948-2fad-6c69379c4bfb@gmail.com>
 <332cfd22-ea11-0415-acdf-3c128d01b788@oracle.com>
Message-ID: <262038e3-6cdb-6708-5a62-30dcf4b04af2@oracle.com>

Hi,

I'm fine with newLength.? Thanks Peter for articulating what was missing 
from calcLength.

The method name needs to make a positive contribution to comprehension.
The three integer arguments don't contribute much, especially since they
are constants in some cases, and in other cases are named for the 
function they
perform in the callers context and are typically index related, not length.

Thanks, Roger

On 05/20/2019 06:45 AM, Ivan Gerasimov wrote:
> Hi Peter!
>
>
> On 5/20/19 3:14 AM, Peter Levart wrote:
>>
>>
>> On 5/20/19 11:11 AM, Ivan Gerasimov wrote:
>>> Hi Peter!
>>>
>>>
>>> On 5/19/19 11:17 PM, Peter Levart wrote:
>>>> Hi Ivan, Roger,
>>>>
>>>> What about "calcNewLength" ?
>>>>
>>>> The word "new" gives enough hint as to what the method does - it 
>>>> calculates the length of new array to be allocated instead of old one.
>>>>
>>> Yes, I think it was one of intermediate names.
>>> But then, it seemed that the New part is redundant, as it does not 
>>> add much:? "calculate length" and "calculate new length" sound very 
>>> similar, while the former is shorter.
>>
>> I feel it does add a tiny bit to clarity. This is internal API, so 
>> it's not that important, and from its use it is immediately obvious 
>> what's going on, but even you felt that saying:
>>
>> > calcLength(oldLength, minGrowth, prefGrowth) is meant to be read as 
>> "given old length and the amount(s) to grow, calculate the new length"
>>
>> is more clear than:
>>
>> > calcLength(oldLength, minGrowth, prefGrowth) is meant to be read as 
>> "given old length and the amount(s) to grow, calculate the length"
>>
>> If a word is redundant then it is "calc". It is obvious that any 
>> function calculates something. So what about "newLength()" ?
>>
> :-)
> I'm fine with newLength, as it's even shorter than calcLength.
>
> I agree with you that it's obvious from its usage what it's doing. And 
> the javadoc of this method and comments for the arguments make it 
> absolutely clear.
>
> I can rename it before pushing, if I hear no other objections.
>
> With kind regards,
> Ivan
>
>> Regards, Peter
>>
>>>
>>> With kind regards,
>>> Ivan
>>>
>>>> Regards, Peter
>>>>
>>>> On 5/17/19 8:45 PM, Ivan Gerasimov wrote:
>>>>> Hi Roger!
>>>>>
>>>>> I think that not only the name, but also the arguments compose the 
>>>>> signature.
>>>>> So, calcLength(oldLength, minGrowth, prefGrowth) is meant to be 
>>>>> read as "given old length and the amount(s) to grow, calculate the 
>>>>> new length".
>>>>> And since this method is placed into ArraysSupport, it should be 
>>>>> clear that it is an array's length.
>>>>>
>>>>> I understand that in certain contexts size may sound more natural 
>>>>> than length.
>>>>> Here, however, using 'length' should be a hint that we're dealing 
>>>>> with array.length.
>>>>>
>>>>> With kind regards,
>>>>> Ivan
>>>>>
>>>>> On 5/17/19 10:35 AM, Roger Riggs wrote:
>>>>>> Hi Ivan,
>>>>>>
>>>>>> The new calcLength method name is too generic, it does not say 
>>>>>> enough about its function.
>>>>>> There is no indication that the purpose is to resize an array.
>>>>>> As for size vs length, sometime size is more evocative of the 
>>>>>> function being performed
>>>>>> than 'length' and is more natural.? In most cases, size and 
>>>>>> length are understood to be synonyms
>>>>>> and capacity is a very apt term for how many elements can be held.
>>>>>>
>>>>>> Can I recommend resizedLength.
>>>>>>
>>>>>> Regards, Roger
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 05/15/2019 10:47 PM, Ivan Gerasimov wrote:
>>>>>>> Thank you Pavel and Roger for reviewing!
>>>>>>>
>>>>>>> I apologize for reiterating this.
>>>>>>> After off-line discussion with Stuart Marks, the fix was 
>>>>>>> modified once again.
>>>>>> !!
>>>>>>> The modifications were mostly stylistic:? The used terminology 
>>>>>>> now reflects that we work with arrays (thus 'length', not 'size' 
>>>>>>> or 'capacity').
>>>>>>> Functionally, the fix remains exactly the same.
>>>>>>>
>>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8223593/02/webrev/
>>>>>>>
>>>>>>> With kind regards,
>>>>>>> Ivan
>>>>>>>
>>>>>>> On 5/14/19 7:50 AM, Roger Riggs wrote:
>>>>>>>> Hi Ivan,
>>>>>>>>
>>>>>>>> The updated patch looks fine.
>>>>>>>>
>>>>>>>> Strictly speaking, the change to Files.readAllBytes is not 
>>>>>>>> indicated by the bug report
>>>>>>>> so please update or comment on the bug report to mention that 
>>>>>>>> change.
>>>>>>>>
>>>>>>>> Thanks, Roger
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/13/2019 10:44 AM, Pavel Rappo wrote:
>>>>>>>>> Thanks for updating your patch. The updated code seems fine.
>>>>>>>>>
>>>>>>>>> -Pavel
>>>>>>>>>
>>>>>>>>>> On 11 May 2019, at 05:01, Ivan 
>>>>>>>>>> Gerasimov<ivan.gerasimov at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello!
>>>>>>>>>>
>>>>>>>>>> Please help review the updated fix.
>>>>>>>>>>
>>>>>>>>>> This new webrev includes changes suggested by Pavel, Peter 
>>>>>>>>>> and Roger.
>>>>>>>>>>
>>>>>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/01/webrev/
>>>>>>>>>>
>>>>>>>>>> Please note that the behavior of j.n.f.Files.readAllBytes() 
>>>>>>>>>> has changed slightly, so now it *may* be possible to read a 
>>>>>>>>>> file larger than (Integer.MAX_VALUE - 8), if VM is able to 
>>>>>>>>>> allocate that large array.
>>>>>>>>>>
>>>>>>>>>> With kind regards,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>> On 5/8/19 6:50 PM, Ivan Gerasimov wrote:
>>>>>>>>>>> Hello!
>>>>>>>>>>>
>>>>>>>>>>> Jdk has several places with similar logic:? an array needs 
>>>>>>>>>>> to be reallocated (by at least some defined amount), taking 
>>>>>>>>>>> into account the maximum allowed size of arrays.
>>>>>>>>>>>
>>>>>>>>>>> There's clearly an opportunity for refactoring, so it is 
>>>>>>>>>>> proposed to introduce a dedicated utility method for 
>>>>>>>>>>> calculating the best new size of an array.
>>>>>>>>>>>
>>>>>>>>>>> Would you please help review this enhancement?
>>>>>>>>>>>
>>>>>>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8223593
>>>>>>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8223593/00/webrev/
>>>>>>>>>>>
>>>>>>>>>>> Mach5 job ran fine.
>>>>>>>>>>>
>>>>>>>>>>> Thanks in advance!
>>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> With kind regards,
>>>>>>>>>> Ivan Gerasimov
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> With kind regards,
>>>>>>> Ivan Gerasimov
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From vicente.romero at oracle.com  Mon May 20 17:00:35 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 20 May 2019 13:00:35 -0400
Subject: =?UTF-8?Q?Re=3a_RFR=3a_JDK-8223723=3a_j=2el=2ec=2eMethodTypeDesc=2e?=
 =?UTF-8?Q?dropParameterTypes=e2=80=8b_throws_the_undocumented_exception=3a_?=
 =?UTF-8?Q?IllegalArgumentException?=
In-Reply-To: <0364ef78-bff4-8b21-e169-20df27b9622b@oracle.com>
References: <b3a7137f-3c4f-d303-7508-9f8366820cb6@oracle.com>
 <23e6c6fa-d18a-bef0-3af2-23c785ce1d0d@oracle.com>
 <0c15f347-e6c7-9b60-0559-398cb6ac1b2f@oracle.com>
 <63c39e33-f58b-bc45-427c-813de2e484af@oracle.com>
 <0364ef78-bff4-8b21-e169-20df27b9622b@oracle.com>
Message-ID: <151aa758-192a-0474-65b7-d472448f8dba@oracle.com>

Hi Roger,


On 5/17/19 4:53 PM, Roger Riggs wrote:
> Hi Vicente,
>
> Looks fine.
>
> Please add a "." at the end of the summary 2nd sentence.

done

>
> BTW, are you aware of the range checking methods in 
> java.util.Objects.checkFromToIndex(from, to, length)?
> They make it easy avoid to check all the conditions on subranges.

I will take a look at them, thanks for the suggestion,
>
> Thanks, Roger

Thanks for all the reviews so far!
Vicente

>
>
> On 05/17/2019 04:14 PM, Vicente Romero wrote:
>> Hi Roger,
>>
>> Thanks again for the reviews, I have modified the CSR summary after 
>> your suggestion [1]. I have also fixed the issue with the webrev link 
>> [2],
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223918
>> [2] http://cr.openjdk.java.net/~vromero/8223723/webrev.01/
>>
>> On 5/17/19 2:18 PM, Roger Riggs wrote:
>>> Hi Vicente,
>>>
>>> Method j.l.c.MethodTypeDesc.dropParameterTypes? throws an exception 
>>> in a case
>>> I would change the CSR summary to "Method 
>>> j.l.c.MethodTypeDesc.dropParameterTypes? should specify 
>>> IndexOutOfBoundsException"
>>> to focus on the new behavior.
>>>
>>> The link to the webrev looks ok, but has the fix for 8223725 instead.
>>>
>>> Roger
>>>
>>>
>>> On 05/16/2019 06:52 PM, Vicente Romero wrote:
>>>> Hi,
>>>>
>>>> I still need a reviewer for this simple patch and CSR,
>>>>
>>>> TIA,
>>>> Vicente
>>>>
>>>> On 5/14/19 4:53 PM, Vicente Romero wrote:
>>>>> Please review fix for [1] at [2]. The implementation of method 
>>>>> java.lang.constant.MethodTypeDesc::dropParameterTypes was throwing 
>>>>> a non specified exception. The proposed fix is synchronizing the 
>>>>> implementation with the specification. Please also review the CSR 
>>>>> at [3]. Check the problem section in the CSR for more details,
>>>>>
>>>>> Thanks,
>>>>> Vicente
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8223723
>>>>> [2] http://cr.openjdk.java.net/~vromero/8223767/webrev.00/
>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8223918
>>>>
>>>
>>
>


From vicente.romero at oracle.com  Mon May 20 17:07:21 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 20 May 2019 13:07:21 -0400
Subject: RFR: JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented
 exception IllegalArgumentException
In-Reply-To: <397f5929-41dc-72ca-505c-c4532994481f@oracle.com>
References: <953e6ae5-365d-251a-901f-a58fc889d9f5@oracle.com>
 <6f066d47-cd8d-00d8-17ec-502e36088028@oracle.com>
 <397f5929-41dc-72ca-505c-c4532994481f@oracle.com>
Message-ID: <0b94fc1f-30b5-9abb-5504-96560b140ad3@oracle.com>

how does it look now?

Thanks,
Vicente

On 5/17/19 3:58 PM, Vicente Romero wrote:
> Hi Roger,
>
> Thanks for the review, my apologies, I made a mistake an applied the 
> change to the wrong method. I have corrected the patch [1] and the CSR 
> [2]. I have updated the language used as you suggested,
>
> Thanks,
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8223725/webrev.01/
> [2] https://bugs.openjdk.java.net/browse/JDK-8223920
>
> On 5/17/19 2:05 PM, Roger Riggs wrote:
>> Hi Vicente,
>>
>> What's the difference in the IAE exceptions describing IAE's as
>> being "incorrect formats' vs 'is invalid' or 'not valid'?
>>
>> Each requires a spec for valid and invalid strings or is undefined.
>>
>> Can the new IAE use the same language as is used for the ofDescriptor 
>> method?
>> Avoiding any question about differences.
>>
>> 69:? Also, is the word 'lookup' overloaded?? Is 'lookup' is 
>> significant in this context?
>>
>> Roger
>>
>>
>> On 05/14/2019 06:37 PM, Vicente Romero wrote:
>>> Please review fix [1] for [2] and the corresponding CSR at [3]. The 
>>> fix is just adding a missing @throws at method 
>>> j.l.c.MethodHandleDesc::of. It is a one liner fix,
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] http://cr.openjdk.java.net/~vromero/8223725/webrev.00/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8223725
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8223920
>>
>


From vicente.romero at oracle.com  Mon May 20 17:16:50 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 20 May 2019 13:16:50 -0400
Subject: RFR: JDK-8223914: specification of j.l.c.MethodTypeDesc::of
 should document better the exceptions thrown
In-Reply-To: <8991ce18-0b54-d0e8-3dcd-6581fde5141b@oracle.com>
References: <8991ce18-0b54-d0e8-3dcd-6581fde5141b@oracle.com>
Message-ID: <bdffedcb-a3bf-70f2-5900-bdeb0cccba59@oracle.com>

ping,

Thanks,
Vicente

On 5/17/19 12:55 PM, Vicente Romero wrote:
> Please review simple fix for [1] at [2] plus the CSR at [3]. This fix 
> is simply documenting all the missing cases in which method 
> java.lang.constant.MethodTypeDesc::of can throw exceptions. A test has 
> been added to cover the missing cases.
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223914
> [2] http://cr.openjdk.java.net/~vromero/8223914/webrev.00/
> [3] https://bugs.openjdk.java.net/browse/JDK-8224136


From thomas.stuefe at gmail.com  Mon May 20 17:17:10 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 20 May 2019 19:17:10 +0200
Subject: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to
 exec() jspawnhelper does not result in an error
In-Reply-To: <87ef4ti4ps.fsf@oldenburg2.str.redhat.com>
References: <CAA-vtUwEu7RSL7vdQuzGziopQvUXomSLEOsFaDjzSQvxL5uvZA@mail.gmail.com>
 <87ef4ti4ps.fsf@oldenburg2.str.redhat.com>
Message-ID: <CAA-vtUw8sevGaD9jxUxe=3DZ8jULF0B0ZMmOpE-642+6aQb18A@mail.gmail.com>

Hi Florian,

On Mon, May 20, 2019 at 4:24 PM Florian Weimer <fweimer at redhat.com> wrote:

> * Thomas St?fe:
>
> > Hi all,
> >
> > (old mail thread:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html
> )
> >
> > May I please have your reviews and opinions for the following bug fix:
> >
> > issue: https://bugs.openjdk.java.net/browse/JDK-8223777
> > cr:
> http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error-alternate-impl/webrev.00/webrev/
> >
> > ---
>
> I wonder if you should use 0 as the value for CHILD_IS_ALIVE.  All
> integers could be valid errno values.  But if you check for errors from
> the restartableWrite call (and call _exit), I don't think there is a
> risk of confusion, so the value does not have to be distinct.
>
>
I'd like to keep this value as it is (0x10000). I plan to extend this
scheme when implementing https://bugs.openjdk.java.net/browse/JDK-8224180 -
basically, have a return code which still fits into an int but is an errno
and some sort of context id and'ed together.

Cheers, Thomas

Thanks,
> Florian
>

From martinrb at google.com  Mon May 20 17:49:17 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 20 May 2019 10:49:17 -0700
Subject: RFR: jsr166 integration 2019-06
In-Reply-To: <CA+kOe09_4jniMDStZoBztpfF1bU2WDBP+hLo0eE-N6=LN9SdJg@mail.gmail.com>
References: <CA+kOe09_4jniMDStZoBztpfF1bU2WDBP+hLo0eE-N6=LN9SdJg@mail.gmail.com>
Message-ID: <CA+kOe0_WWFpcBAEQSPG=1wtsv2pL9T2sx59SEUygGyz89YzwLQ@mail.gmail.com>

Adding trivial fix to this integration:

8224176: Fix inconsistencies in @jls tags in java.util.concurrent
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/jls/index.html
https://bugs.openjdk.java.net/browse/JDK-8224176


On Thu, May 16, 2019 at 2:58 PM Martin Buchholz <martinrb at google.com> wrote:

>
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
>
> Just another test timeout tweak:
> 8224024: java/util/concurrent/BlockingQueue/DrainToFails.java testBounded
> fails intermittently
>
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/DrainToFails/index.html
> https://bugs.openjdk.java.net/browse/JDK-8224024
>
> 8220478: java/util/concurrent/ConcurrentHashMap/ToArray.java timed out
> intermittently
>
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/forkjoin/index.html
> 8223379: Clarify ForkJoinPool.getStealCount() javadoc
> https://bugs.openjdk.java.net/browse/JDK-8220478
>
> 8223245: Miscellaneous changes imported from jsr166 CVS 2019-06
>
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html
> https://bugs.openjdk.java.net/browse/JDK-8223245
>
>

From Roger.Riggs at oracle.com  Mon May 20 18:00:45 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 20 May 2019 14:00:45 -0400
Subject: RFR: JDK-8223914: specification of j.l.c.MethodTypeDesc::of
 should document better the exceptions thrown
In-Reply-To: <8991ce18-0b54-d0e8-3dcd-6581fde5141b@oracle.com>
References: <8991ce18-0b54-d0e8-3dcd-6581fde5141b@oracle.com>
Message-ID: <7520e768-3445-bfbb-5619-8f4d5b5da59a@oracle.com>

Hi Vicente,

In the CSR, the Summary should be about the change... 
"...MethodTypeDesc::of should document all exceptions.
Avoid duplication between Summary and Problem.

I would omit the part about "content of parameter" or "its contents" is 
null;
It cannot happen and if it does, its more of an internal error than a 
regular NPE
since it should not be possible to create a ClassDesc with a null 
descriptor string.

In the Code Review:

MethodTypeDesc.java: 68:? as above, "or its contents are" -> "is "? 
there's no need to mention the contents.

MethodTypeDescTest.java: 264 and 274.? The messages would be more useful 
(if they ever were to happen)
and for the person reading the code if they describe what should not happen.
For example,? "ClassDesc array should not be null"? or ClassDesc should 
not be null.

Thanks, Roger


On 05/17/2019 12:55 PM, Vicente Romero wrote:
> Please review simple fix for [1] at [2] plus the CSR at [3]. This fix 
> is simply documenting all the missing cases in which method 
> java.lang.constant.MethodTypeDesc::of can throw exceptions. A test has 
> been added to cover the missing cases.
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223914
> [2] http://cr.openjdk.java.net/~vromero/8223914/webrev.00/
> [3] https://bugs.openjdk.java.net/browse/JDK-8224136


From jonathan.gibbons at oracle.com  Mon May 20 18:03:24 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 20 May 2019 11:03:24 -0700
Subject: JDK 13 RFR of JDK-8224175: Fix inconsistencies in @jls and @jvms
 tags
In-Reply-To: <478b540e-35a0-b9df-8bf3-c03b0422af8f@oracle.com>
References: <478b540e-35a0-b9df-8bf3-c03b0422af8f@oracle.com>
Message-ID: <0d8a4182-49c4-154d-ab66-6dbb47bf8c69@oracle.com>

Looks good to me.

-- Jon


On 05/19/2019 12:36 PM, Joe Darcy wrote:
> Hello,
>
> Thanks to some tooling developed by Jon Gibbons, inconsistencies in 
> the section names and numbers in the @jls and @jvms javadoc tags in 
> the jdk and the names and numbers of the current specifications have 
> been identified. These inconsistencies should be fixed.
>
> The names and numbers of the section titles in JLS and JVMS are 
> *mostly* stable, but a few sections have changed most notably for the 
> usage of @jls tags:
>
> ??? * 8.9 "Enum" -> "Enum Type" in Java SE 8
> ??? * 5.1.2 "Widening Primitive Conversions" -> "Widening Primitive 
> *Conversion*" in Java SE 7
>
> Two uses of "@jvms 5.3 Run-time package" refer to the term "Run-time 
> package" defined in that section. The term was replaced by the section 
> name in both cases.
>
> In java.lang.SuppressWarnings, a reference to the section "5.5.2 
> Checked Casts and Unchecked Casts", which was removed in Java SE 9, 
> was replaced with a reference to the enclosing section "5.5. Casting 
> Contexts".
>
> The usage of @jls in jshell was less consistent and has been regularized.
>
> Full webrev at:
>
> ??? http://cr.openjdk.java.net/~darcy/8224175.0/
>
> Patch below.
>
> Thanks,
>
> -Joe
>
> --- old/src/java.base/share/classes/java/lang/Byte.java 2019-05-19 
> 12:16:26.705761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Byte.java 2019-05-19 
> 12:16:26.137761266 -0700
> @@ -356,7 +356,7 @@
> ???? /**
> ????? * Returns the value of this {@code Byte} as a {@code short} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public short shortValue() {
> ???????? return (short)value;
> @@ -365,7 +365,7 @@
> ???? /**
> ????? * Returns the value of this {@code Byte} as an {@code int} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public int intValue() {
> ???????? return (int)value;
> @@ -374,7 +374,7 @@
> ???? /**
> ????? * Returns the value of this {@code Byte} as a {@code long} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public long longValue() {
> ???????? return (long)value;
> @@ -383,7 +383,7 @@
> ???? /**
> ????? * Returns the value of this {@code Byte} as a {@code float} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public float floatValue() {
> ???????? return (float)value;
> @@ -392,7 +392,7 @@
> ???? /**
> ????? * Returns the value of this {@code Byte} as a {@code double}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public double doubleValue() {
> ???????? return (double)value;
> --- old/src/java.base/share/classes/java/lang/Class.java 2019-05-19 
> 12:16:27.597761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Class.java 2019-05-19 
> 12:16:27.161761266 -0700
> @@ -999,7 +999,7 @@
> ????? *
> ????? * @since 9
> ????? * @spec JPMS
> -???? * @jls 6.7? Fully Qualified Names
> +???? * @jls 6.7 Fully Qualified Names
> ????? */
> ???? public String getPackageName() {
> ???????? String pn = this.packageName;
> @@ -3910,7 +3910,8 @@
> ????? *???????? SecurityManager#checkPackageAccess 
> s.checkPackageAccess()}
> ????? *???????? denies access to the package of the returned class
> ????? * @since 11
> -???? * @jvms 4.7.28 and 4.7.29 NestHost and NestMembers attributes
> +???? * @jvms 4.7.28 The {@code NestHost} Attribute
> +???? * @jvms 4.7.29 The {@code NestMembers} Attribute
> ????? * @jvms 5.4.4 Access Control
> ????? */
> ???? @CallerSensitive
> --- old/src/java.base/share/classes/java/lang/ClassLoader.java 
> 2019-05-19 12:16:28.429761266 -0700
> +++ new/src/java.base/share/classes/java/lang/ClassLoader.java 
> 2019-05-19 12:16:28.041761266 -0700
> @@ -222,7 +222,7 @@
> ? * or a fully qualified name as defined by
> ? * <cite>The Java&trade; Language Specification</cite>.
> ? *
> - * @jls 6.7? Fully Qualified Names
> + * @jls 6.7 Fully Qualified Names
> ? * @jls 13.1 The Form of a Binary
> ? * @see????? #resolveClass(Class)
> ? * @since 1.0
> @@ -2194,7 +2194,7 @@
> ????? * @revised 9
> ????? * @spec JPMS
> ????? *
> -???? * @jvms 5.3 Run-time package
> +???? * @jvms 5.3 Creation and Loading
> ????? * @see <a href="{@docRoot}/../specs/jar/jar.html#package-sealing">
> ????? *????? The JAR File Specification: Package Sealing</a>
> ????? */
> @@ -2228,7 +2228,7 @@
> ????? * @throws? NullPointerException
> ????? *????????? if {@code name} is {@code null}.
> ????? *
> -???? * @jvms 5.3 Run-time package
> +???? * @jvms 5.3 Creation and Loading
> ????? *
> ????? * @since? 9
> ????? * @spec JPMS
> @@ -2255,7 +2255,7 @@
> ????? *???????? this class loader; or an zero length array if no 
> package has been
> ????? *???????? defined by this class loader.
> ????? *
> -???? * @jvms 5.3 Run-time package
> +???? * @jvms 5.3 Creation and Loading
> ????? *
> ????? * @since? 9
> ????? * @spec JPMS
> --- old/src/java.base/share/classes/java/lang/Double.java 2019-05-19 
> 12:16:29.205761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Double.java 2019-05-19 
> 12:16:28.809761266 -0700
> @@ -673,7 +673,7 @@
> ????? *
> ????? * @return? the {@code double} value represented by this object
> ????? *????????? converted to type {@code byte}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? * @since 1.1
> ????? */
> ???? public byte byteValue() {
> @@ -686,7 +686,7 @@
> ????? *
> ????? * @return? the {@code double} value represented by this object
> ????? *????????? converted to type {@code short}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? * @since 1.1
> ????? */
> ???? public short shortValue() {
> @@ -696,7 +696,7 @@
> ???? /**
> ????? * Returns the value of this {@code Double} as an {@code int}
> ????? * after a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? *
> ????? * @return? the {@code double} value represented by this object
> ????? *????????? converted to type {@code int}
> @@ -711,7 +711,7 @@
> ????? *
> ????? * @return? the {@code double} value represented by this object
> ????? *????????? converted to type {@code long}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public long longValue() {
> ???????? return (long)value;
> @@ -723,7 +723,7 @@
> ????? *
> ????? * @return? the {@code double} value represented by this object
> ????? *????????? converted to type {@code float}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? * @since 1.0
> ????? */
> ???? public float floatValue() {
> --- old/src/java.base/share/classes/java/lang/Float.java 2019-05-19 
> 12:16:30.133761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Float.java 2019-05-19 
> 12:16:29.637761266 -0700
> @@ -602,7 +602,7 @@
> ????? *
> ????? * @return? the {@code float} value represented by this object
> ????? *????????? converted to type {@code byte}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public byte byteValue() {
> ???????? return (byte)value;
> @@ -614,7 +614,7 @@
> ????? *
> ????? * @return? the {@code float} value represented by this object
> ????? *????????? converted to type {@code short}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? * @since 1.1
> ????? */
> ???? public short shortValue() {
> @@ -627,7 +627,7 @@
> ????? *
> ????? * @return? the {@code float} value represented by this object
> ????? *????????? converted to type {@code int}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public int intValue() {
> ???????? return (int)value;
> @@ -639,7 +639,7 @@
> ????? *
> ????? * @return? the {@code float} value represented by this object
> ????? *????????? converted to type {@code long}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public long longValue() {
> ???????? return (long)value;
> @@ -661,7 +661,7 @@
> ????? *
> ????? * @return the {@code float} value represented by this
> ????? *???????? object converted to type {@code double}
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public double doubleValue() {
> ???????? return (double)value;
> --- old/src/java.base/share/classes/java/lang/FunctionalInterface.java 
> 2019-05-19 12:16:31.105761266 -0700
> +++ new/src/java.base/share/classes/java/lang/FunctionalInterface.java 
> 2019-05-19 12:16:30.609761266 -0700
> @@ -57,7 +57,7 @@
> ? * regardless of whether or not a {@code FunctionalInterface}
> ? * annotation is present on the interface declaration.
> ? *
> - * @jls 4.3.2. The Class Object
> + * @jls 4.3.2 The Class Object
> ? * @jls 9.8 Functional Interfaces
> ? * @jls 9.4.3 Interface Method Body
> ? * @jls 9.6.4.9 @FunctionalInterface
> --- old/src/java.base/share/classes/java/lang/Integer.java 2019-05-19 
> 12:16:31.997761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Integer.java 2019-05-19 
> 12:16:31.529761266 -0700
> @@ -1120,7 +1120,7 @@
> ???? /**
> ????? * Returns the value of this {@code Integer} as a {@code byte}
> ????? * after a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public byte byteValue() {
> ???????? return (byte)value;
> @@ -1129,7 +1129,7 @@
> ???? /**
> ????? * Returns the value of this {@code Integer} as a {@code short}
> ????? * after a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public short shortValue() {
> ???????? return (short)value;
> @@ -1147,7 +1147,7 @@
> ???? /**
> ????? * Returns the value of this {@code Integer} as a {@code long}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? * @see Integer#toUnsignedLong(int)
> ????? */
> ???? public long longValue() {
> @@ -1157,7 +1157,7 @@
> ???? /**
> ????? * Returns the value of this {@code Integer} as a {@code float}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public float floatValue() {
> ???????? return (float)value;
> @@ -1166,7 +1166,7 @@
> ???? /**
> ????? * Returns the value of this {@code Integer} as a {@code double}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public double doubleValue() {
> ???????? return (double)value;
> --- old/src/java.base/share/classes/java/lang/Long.java 2019-05-19 
> 12:16:32.785761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Long.java 2019-05-19 
> 12:16:32.369761266 -0700
> @@ -1339,7 +1339,7 @@
> ???? /**
> ????? * Returns the value of this {@code Long} as a {@code byte} after
> ????? * a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public byte byteValue() {
> ???????? return (byte)value;
> @@ -1348,7 +1348,7 @@
> ???? /**
> ????? * Returns the value of this {@code Long} as a {@code short} after
> ????? * a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public short shortValue() {
> ???????? return (short)value;
> @@ -1357,7 +1357,7 @@
> ???? /**
> ????? * Returns the value of this {@code Long} as an {@code int} after
> ????? * a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public int intValue() {
> ???????? return (int)value;
> @@ -1375,7 +1375,7 @@
> ???? /**
> ????? * Returns the value of this {@code Long} as a {@code float} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public float floatValue() {
> ???????? return (float)value;
> @@ -1384,7 +1384,7 @@
> ???? /**
> ????? * Returns the value of this {@code Long} as a {@code double}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public double doubleValue() {
> ???????? return (double)value;
> --- old/src/java.base/share/classes/java/lang/Number.java 2019-05-19 
> 12:16:33.561761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Number.java 2019-05-19 
> 12:16:33.157761266 -0700
> @@ -48,8 +48,8 @@
> ? *
> ? * @author????? Lee Boynton
> ? * @author????? Arthur van Hoff
> - * @jls 5.1.2 Widening Primitive Conversions
> - * @jls 5.1.3 Narrowing Primitive Conversions
> + * @jls 5.1.2 Widening Primitive Conversion
> + * @jls 5.1.3 Narrowing Primitive Conversion
> ? * @since?? 1.0
> ? */
> ?public abstract class Number implements java.io.Serializable {
> --- old/src/java.base/share/classes/java/lang/Package.java 2019-05-19 
> 12:16:34.325761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Package.java 2019-05-19 
> 12:16:33.929761266 -0700
> @@ -108,7 +108,7 @@
> ? * <em>named modules</em>.? Instead those packages are automatically 
> defined
> ? * and have no specification and implementation versioning information.
> ? *
> - * @jvms 5.3 Run-time package
> + * @jvms 5.3 Creation and Loading
> ? * @see <a href="{@docRoot}/../specs/jar/jar.html#package-sealing">
> ? * The JAR File Specification: Package Sealing</a>
> ? * @see ClassLoader#definePackage(String, String, String, String, 
> String, String, String, URL)
> --- old/src/java.base/share/classes/java/lang/Short.java 2019-05-19 
> 12:16:35.109761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Short.java 2019-05-19 
> 12:16:34.701761266 -0700
> @@ -352,7 +352,7 @@
> ???? /**
> ????? * Returns the value of this {@code Short} as a {@code byte} after
> ????? * a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public byte byteValue() {
> ???????? return (byte)value;
> @@ -370,7 +370,7 @@
> ???? /**
> ????? * Returns the value of this {@code Short} as an {@code int} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public int intValue() {
> ???????? return (int)value;
> @@ -379,7 +379,7 @@
> ???? /**
> ????? * Returns the value of this {@code Short} as a {@code long} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public long longValue() {
> ???????? return (long)value;
> @@ -388,7 +388,7 @@
> ???? /**
> ????? * Returns the value of this {@code Short} as a {@code float}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public float floatValue() {
> ???????? return (float)value;
> @@ -397,7 +397,7 @@
> ???? /**
> ????? * Returns the value of this {@code Short} as a {@code double}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public double doubleValue() {
> ???????? return (double)value;
> --- old/src/java.base/share/classes/java/lang/SuppressWarnings.java 
> 2019-05-19 12:16:35.933761266 -0700
> +++ new/src/java.base/share/classes/java/lang/SuppressWarnings.java 
> 2019-05-19 12:16:35.485761266 -0700
> @@ -49,7 +49,7 @@
> ? * @jls 4.8 Raw Types
> ? * @jls 4.12.2 Variables of Reference Type
> ? * @jls 5.1.9 Unchecked Conversion
> - * @jls 5.5.2 Checked Casts and Unchecked Casts
> + * @jls 5.5 Casting Contexts
> ? * @jls 9.6.4.5 @SuppressWarnings
> ? */
> ?@Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, 
> MODULE})
> --- old/src/java.base/share/classes/java/lang/constant/Constable.java 
> 2019-05-19 12:16:36.717761266 -0700
> +++ new/src/java.base/share/classes/java/lang/constant/Constable.java 
> 2019-05-19 12:16:36.285761266 -0700
> @@ -59,7 +59,7 @@
> ? * method handles, but not necessarily those produced by method handle
> ? * combinators.)
> ? * @jvms 4.4 The Constant Pool
> - * @jvms 4.4.10 The CONSTANT_InvokeDynamic_info Structure
> + * @jvms 4.4.10 The {@code CONSTANT_Dynamic_info} and {@code 
> CONSTANT_InvokeDynamic_info} Structures
> ? *
> ? * @since 12
> ? */
> --- old/src/java.base/share/classes/java/lang/reflect/Method.java 
> 2019-05-19 12:16:37.521761266 -0700
> +++ new/src/java.base/share/classes/java/lang/reflect/Method.java 
> 2019-05-19 12:16:37.117761266 -0700
> @@ -403,7 +403,7 @@
> ????? * @return a string describing this {@code Method}
> ????? *
> ????? * @jls 8.4.3 Method Modifiers
> -???? * @jls 9.4?? Method Declarations
> +???? * @jls 9.4 Method Declarations
> ????? * @jls 9.6.1 Annotation Type Elements
> ????? */
> ???? public String toString() {
> @@ -474,7 +474,7 @@
> ????? * @since 1.5
> ????? *
> ????? * @jls 8.4.3 Method Modifiers
> -???? * @jls 9.4?? Method Declarations
> +???? * @jls 9.4 Method Declarations
> ????? * @jls 9.6.1 Annotation Type Elements
> ????? */
> ???? @Override
> --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java 
> 2019-05-19 12:16:38.353761266 -0700
> +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java 
> 2019-05-19 12:16:37.917761266 -0700
> @@ -394,7 +394,7 @@
>
> ???? /**
> ????? * The Java source modifiers that can be applied to a field.
> -???? * @jls 8.3.1? Field Modifiers
> +???? * @jls 8.3.1 Field Modifiers
> ????? */
> ???? private static final int FIELD_MODIFIERS =
> ???????? Modifier.PUBLIC???????? | Modifier.PROTECTED??? | 
> Modifier.PRIVATE |
> --- 
> old/src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java 
> 2019-05-19 12:16:39.161761266 -0700
> +++ 
> new/src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java 
> 2019-05-19 12:16:38.757761266 -0700
> @@ -114,7 +114,7 @@
> ? *
> ? * @since 1.8
> ? * @jls 9.6 Annotation Types
> - * @jls 9.6.3.3 @Inherited
> + * @jls 9.6.4.3 {@code @Inherited}
> ? */
> ?public interface AnnotatedConstruct {
> ???? /**
> --- 
> old/src/java.compiler/share/classes/javax/lang/model/element/Element.java 
> 2019-05-19 12:16:40.001761266 -0700
> +++ 
> new/src/java.compiler/share/classes/javax/lang/model/element/Element.java 
> 2019-05-19 12:16:39.525761266 -0700
> @@ -196,7 +196,7 @@
> ????? * @see ModuleElement#getEnclosedElements
> ????? * @see Elements#getAllMembers
> ????? * @jls 8.8.9 Default Constructor
> -???? * @jls 8.9 Enums
> +???? * @jls 8.9 Enum Types
> ????? * @revised 9
> ????? * @spec JPMS
> ????? */
> --- 
> old/src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java 
> 2019-05-19 12:16:40.801761266 -0700
> +++ 
> new/src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java 
> 2019-05-19 12:16:40.397761266 -0700
> @@ -111,7 +111,7 @@
> ????? * More specifically, an <i>inner</i> type element is any nested 
> type element that
> ????? * is not {@linkplain Modifier#STATIC static}.
> ????? * @return whether or not the constant is nested
> -???? * @jls 14.3 Inner Classes and Enclosing Instances
> +???? * @jls 14.3 Local Class Declarations
> ????? */
> ???? public boolean isNested() {
> ???????? return this != TOP_LEVEL;
> --- 
> old/src/java.compiler/share/classes/javax/lang/model/util/Types.java 
> 2019-05-19 12:16:41.557761266 -0700
> +++ 
> new/src/java.compiler/share/classes/javax/lang/model/util/Types.java 
> 2019-05-19 12:16:41.161761266 -0700
> @@ -104,7 +104,7 @@
> ????? * @return {@code true} if and only if the first type is assignable
> ????? *????????? to the second
> ????? * @throws IllegalArgumentException if given a type for an 
> executable, package, or module
> -???? * @jls 5.2 Assignment Conversion
> +???? * @jls 5.2 Assignment Contexts
> ????? */
> ???? boolean isAssignable(TypeMirror t1, TypeMirror t2);
>
> @@ -115,7 +115,7 @@
> ????? * @param t2? the second type
> ????? * @return {@code true} if and only if the first type contains 
> the second
> ????? * @throws IllegalArgumentException if given a type for an 
> executable, package, or module
> -???? * @jls 4.5.1.1 Type Argument Containment and Equivalence
> +???? * @jls 4.5.1 Type Arguments of Parameterized Types
> ????? */
> ???? boolean contains(TypeMirror t1, TypeMirror t2);
>
> --- 
> old/src/jdk.compiler/share/classes/com/sun/source/tree/BinaryTree.java 
> 2019-05-19 12:16:42.329761266 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/source/tree/BinaryTree.java 
> 2019-05-19 12:16:41.929761266 -0700
> @@ -40,8 +40,8 @@
> ? * @jls 15.20 Relational Operators
> ? * @jls 15.21 Equality Operators
> ? * @jls 15.22 Bitwise and Logical Operators
> - * @jls 15.23 Conditional-And Operator &&
> - * @jls 15.24 Conditional-Or Operator ||
> + * @jls 15.23 Conditional-And Operator {@code &&}
> + * @jls 15.24 Conditional-Or Operator {@code ||}
> ? *
> ? * @author Peter von der Ah&eacute;
> ? * @author Jonathan Gibbons
> --- 
> old/src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java 
> 2019-05-19 12:16:43.285761266 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java 
> 2019-05-19 12:16:42.797761266 -0700
> @@ -45,7 +45,7 @@
> ? * @jls 8.5.1 Static Member Type Declarations
> ? * @jls 8.8.3 Constructor Modifiers
> ? * @jls 9.1.1 Interface Modifiers
> - * @jls 9.7?? Annotations
> + * @jls 9.7 Annotations
> ? *
> ? * @author Peter von der Ah&eacute;
> ? * @author Jonathan Gibbons
> --- 
> old/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java 
> 2019-05-19 12:16:44.213761266 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java 
> 2019-05-19 12:16:43.721761266 -0700
> @@ -2733,7 +2733,7 @@
> ????? * signature</em> of the other.? This is <b>not</b> an equivalence
> ????? * relation.
> ????? *
> -???? * @jls section 8.4.2.
> +???? * @jls 8.4.2 Method Signature
> ????? * @see #overrideEquivalent(Type t, Type s)
> ????? * @param t first signature (possibly raw).
> ????? * @param s second signature (could be subjected to erasure).
> @@ -2752,7 +2752,7 @@
> ????? * equivalence</em>.? This is the natural extension of
> ????? * isSubSignature to an equivalence relation.
> ????? *
> -???? * @jls section 8.4.2.
> +???? * @jls 8.4.2 Method Signature
> ????? * @see #isSubSignature(Type t, Type s)
> ????? * @param t a signature (possible raw, could be subjected to
> ????? * erasure).
> @@ -4214,7 +4214,7 @@
>
> ???? /**
> ????? * Return-Type-Substitutable.
> -???? * @jls section 8.4.5
> +???? * @jls 8.4.5 Method Result
> ????? */
> ???? public boolean returnTypeSubstitutable(Type r1, Type r2) {
> ???????? if (hasSameArgs(r1, r2))
> --- 
> old/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java 
> 2019-05-19 12:16:45.077761266 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java 
> 2019-05-19 12:16:44.657761266 -0700
> @@ -4222,7 +4222,7 @@
> ????????? * @param tree??? The tree making up the variable reference.
> ????????? * @param env???? The current environment.
> ????????? * @param v?????? The variable's symbol.
> -???????? * @jls? section 8.9 Enums
> +???????? * @jls 8.9 Enum Types
> ????????? */
> ???????? private void checkEnumInitializer(JCTree tree, 
> Env<AttrContext> env, VarSymbol v) {
> ???????????? // JLS:
> --- old/src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java 
> 2019-05-19 12:16:45.941761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java 
> 2019-05-19 12:16:45.505761266 -0700
> @@ -36,7 +36,7 @@
> ? * and thus is thread-safe.
> ? *
> ? * @since 9
> - * @jls 15: Expression.
> + * @jls 15 Expressions
> ? */
> ?public class ExpressionSnippet extends Snippet {
>
> --- old/src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java 
> 2019-05-19 12:16:47.045761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java 
> 2019-05-19 12:16:46.629761266 -0700
> @@ -36,7 +36,7 @@
> ? * and thus is thread-safe.
> ? *
> ? * @since 9
> - * @jls 8.3: importDeclaration.
> + * @jls 7.5 Import Declarations
> ? */
> ?public class ImportSnippet extends PersistentSnippet {
>
> --- old/src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java 
> 2019-05-19 12:16:48.501761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java 
> 2019-05-19 12:16:48.093761266 -0700
> @@ -37,7 +37,7 @@
> ? * and thus is thread-safe.
> ? *
> ? * @since 9
> - * @jls 8.4: MethodDeclaration.
> + * @jls 8.4 Method Declarations
> ? */
> ?public class MethodSnippet extends DeclarationSnippet {
>
> --- old/src/jdk.jshell/share/classes/jdk/jshell/Snippet.java 
> 2019-05-19 12:16:49.593761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/Snippet.java 
> 2019-05-19 12:16:49.173761266 -0700
> @@ -73,7 +73,7 @@
> ????????? * ({@link 
> jdk.jshell.Snippet.SubKind#SINGLE_STATIC_IMPORT_SUBKIND}) --
> ????????? * use {@link jdk.jshell.Snippet#subKind()} to distinguish.
> ????????? *
> -???????? * @jls 8.3: importDeclaration.
> +???????? * @jls 7.5 Import Declarations
> ????????? * <P>
> ????????? * An import declaration is {@linkplain Kind#isPersistent() 
> persistent}.
> ????????? */
> @@ -91,7 +91,7 @@
> ????????? * annotation interfaces -- see {@link 
> jdk.jshell.Snippet.SubKind} to
> ????????? * differentiate.
> ????????? *
> -???????? * @jls 7.6: TypeDeclaration.
> +???????? * @jls 7.6 Top Level Type Declarations
> ????????? * <P>
> ????????? * A type declaration is {@linkplain Kind#isPersistent() 
> persistent}.
> ????????? */
> @@ -101,7 +101,7 @@
> ????????? * A method declaration.
> ????????? * The snippet is an instance of {@link 
> jdk.jshell.MethodSnippet}.
> ????????? *
> -???????? * @jls 8.4: MethodDeclaration.
> +???????? * @jls 8.4 Method Declarations
> ????????? * <P>
> ????????? * A method declaration is {@linkplain Kind#isPersistent() 
> persistent}.
> ????????? */
> @@ -116,7 +116,7 @@
> ????????? * variable representing an expression -- see
> ????????? * {@link jdk.jshell.Snippet.SubKind}to differentiate.
> ????????? *
> -???????? * @jls 8.3: FieldDeclaration.
> +???????? * @jls 8.3 Field Declarations
> ????????? * <P>
> ????????? * A variable declaration is {@linkplain Kind#isPersistent() 
> persistent}.
> ????????? */
> @@ -133,7 +133,7 @@
> ????????? * All other expression forms (operators, method calls, ...) 
> generate a
> ????????? * scratch variable and so are instead of the VAR Kind.
> ????????? *
> -???????? * @jls 15: Expression.
> +???????? * @jls 15 Expressions
> ????????? */
> ???????? EXPRESSION(false),
>
> @@ -141,7 +141,7 @@
> ????????? * A statement.
> ????????? * The snippet is an instance of {@link 
> jdk.jshell.StatementSnippet}.
> ????????? *
> -???????? * @jls 14.5: Statement.
> +???????? * @jls 14.5 Statements
> ????????? */
> ???????? STATEMENT(false),
>
> @@ -185,99 +185,97 @@
> ???????? /**
> ????????? * Single-Type-Import Declaration.
> ????????? * An import declaration of a single type.
> -???????? * @jls 7.5.1 SingleTypeImportDeclaration.
> +???????? * @jls 7.5.1 Single-Type-Import Declarations
> ????????? */
> ???????? SINGLE_TYPE_IMPORT_SUBKIND(Kind.IMPORT),
>
> ???????? /**
> ????????? * Type-Import-on-Demand Declaration.
> ????????? * A non-static "star" import.
> -???????? * @jls 7.5.2. TypeImportOnDemandDeclaration.
> +???????? * @jls 7.5.2 Type-Import-on-Demand Declarations
> ????????? */
> ???????? TYPE_IMPORT_ON_DEMAND_SUBKIND(Kind.IMPORT),
>
> ???????? /**
> ????????? * Single-Static-Import Declaration.
> ????????? * An import of a static member.
> -???????? * @jls 7.5.3 Single-Static-Import.
> +???????? * @jls 7.5.3 Single-Static-Import Declarations
> ????????? */
> ???????? SINGLE_STATIC_IMPORT_SUBKIND(Kind.IMPORT),
>
> ???????? /**
> ????????? * Static-Import-on-Demand Declaration.
> ????????? * A static "star" import of all static members of a named type.
> -???????? * @jls 7.5.4. Static-Import-on-Demand Static "star" import.
> +???????? * @jls 7.5.4 Static-Import-on-Demand Declarations
> ????????? */
> ???????? STATIC_IMPORT_ON_DEMAND_SUBKIND(Kind.IMPORT),
>
> ???????? /**
> ????????? * A class declaration.
> ????????? * A {@code SubKind} of {@link Kind#TYPE_DECL}.
> -???????? * @jls 8.1. NormalClassDeclaration.
> +???????? * @jls 8.1 Class Declarations
> ????????? */
> ???????? CLASS_SUBKIND(Kind.TYPE_DECL),
>
> ???????? /**
> ????????? * An interface declaration.
> ????????? * A {@code SubKind} of {@link Kind#TYPE_DECL}.
> -???????? * @jls 9.1. NormalInterfaceDeclaration.
> +???????? * @jls 9.1 Interface Declarations
> ????????? */
> ???????? INTERFACE_SUBKIND(Kind.TYPE_DECL),
>
> ???????? /**
> ????????? * An enum declaration.
> ????????? * A {@code SubKind} of {@link Kind#TYPE_DECL}.
> -???????? * @jls 8.9. EnumDeclaration.
> +???????? * @jls 8.9 Enum Types
> ????????? */
> ???????? ENUM_SUBKIND(Kind.TYPE_DECL),
>
> ???????? /**
> ????????? * An annotation interface declaration. A {@code SubKind} of
> ????????? * {@link Kind#TYPE_DECL}.
> -???????? * @jls 9.6. AnnotationTypeDeclaration.
> +???????? * @jls 9.6 Annotation Types
> ????????? */
> ???????? ANNOTATION_TYPE_SUBKIND(Kind.TYPE_DECL),
>
> ???????? /**
> ????????? * A method. The only {@code SubKind} for {@link Kind#METHOD}.
> -???????? * @jls 8.4. MethodDeclaration.
> +???????? * @jls 8.4 Method Declarations
> ????????? */
> ???????? METHOD_SUBKIND(Kind.METHOD),
>
> ???????? /**
> ????????? * A variable declaration without initializer.
> ????????? * A {@code SubKind} of {@link Kind#VAR}.
> -???????? * @jls 8.3. VariableDeclarator without VariableInitializer in
> -???????? * FieldDeclaration.
> +???????? * @jls 8.3 Field Declarations
> ????????? */
> ???????? VAR_DECLARATION_SUBKIND(Kind.VAR, true, true),
>
> ???????? /**
> ????????? * A variable declaration with an initializer expression. A
> ????????? * {@code SubKind} of {@link Kind#VAR}.
> -???????? * @jls 8.3. VariableDeclarator with VariableInitializer in
> -???????? * FieldDeclaration.
> +???????? * @jls 8.3 Field Declarations
> ????????? */
> ???????? VAR_DECLARATION_WITH_INITIALIZER_SUBKIND(Kind.VAR, true, true),
>
> ???????? /**
> ????????? * An expression whose value has been stored in a temporary 
> variable. A
> ????????? * {@code SubKind} of {@link Kind#VAR}.
> -???????? * @jls 15. Primary.
> +???????? * @jls 15 Expressions
> ????????? */
> ???????? TEMP_VAR_EXPRESSION_SUBKIND(Kind.VAR, true, true),
>
> ???????? /**
> ????????? * A simple variable reference expression. A {@code SubKind} of
> ????????? * {@link Kind#EXPRESSION}.
> -???????? * @jls 15.11. Field Access as 3.8. Identifier.
> +???????? * @jls 15.11 Field Access Expressions
> ????????? */
> ???????? VAR_VALUE_SUBKIND(Kind.EXPRESSION, true, true),
>
> ???????? /**
> ????????? * An assignment expression. A {@code SubKind} of
> ????????? * {@link Kind#EXPRESSION}.
> -???????? * @jls 15.26. Assignment.
> +???????? * @jls 15.26 Assignment Operators
> ????????? */
> ???????? ASSIGNMENT_SUBKIND(Kind.EXPRESSION, true, true),
>
> @@ -289,7 +287,7 @@
>
> ???????? /**
> ????????? * A statement. The only {@code SubKind} for {@link 
> Kind#STATEMENT}.
> -???????? * @jls 14.5. Statement.
> +???????? * @jls 14.5 Statements
> ????????? */
> ???????? STATEMENT_SUBKIND(Kind.STATEMENT, true, false),
>
> --- old/src/jdk.jshell/share/classes/jdk/jshell/StatementSnippet.java 
> 2019-05-19 12:16:50.421761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/StatementSnippet.java 
> 2019-05-19 12:16:49.985761266 -0700
> @@ -36,7 +36,7 @@
> ? * and thus is thread-safe.
> ? *
> ? * @since 9
> - * @jls 14.5: Statement.
> + * @jls 14.5 Statements
> ? */
> ?public class StatementSnippet extends Snippet {
>
> --- old/src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java 
> 2019-05-19 12:16:51.549761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java 
> 2019-05-19 12:16:51.117761266 -0700
> @@ -39,7 +39,7 @@
> ? * and thus is thread-safe.
> ? *
> ? * @since 9
> - * @jls 8.3: FieldDeclaration.
> + * @jls 8.3 Field Declarations
> ? */
> ?public class VarSnippet extends DeclarationSnippet {
>
>


From Roger.Riggs at oracle.com  Mon May 20 18:09:39 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 20 May 2019 14:09:39 -0400
Subject: RFR: JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented
 exception IllegalArgumentException
In-Reply-To: <0b94fc1f-30b5-9abb-5504-96560b140ad3@oracle.com>
References: <953e6ae5-365d-251a-901f-a58fc889d9f5@oracle.com>
 <6f066d47-cd8d-00d8-17ec-502e36088028@oracle.com>
 <397f5929-41dc-72ca-505c-c4532994481f@oracle.com>
 <0b94fc1f-30b5-9abb-5504-96560b140ad3@oracle.com>
Message-ID: <5e04f19f-12db-4ecd-692c-ea4529963044@oracle.com>

Hi Vicente,

Looks ok.

Can you ident the 2nd and subsequent lines of the javadoc tag,
as is done in the other tags of the method.
No need for another webrev.

Thanks, Roger

On 05/20/2019 01:07 PM, Vicente Romero wrote:
> how does it look now?
>
> Thanks,
> Vicente
>
> On 5/17/19 3:58 PM, Vicente Romero wrote:
>> Hi Roger,
>>
>> Thanks for the review, my apologies, I made a mistake an applied the 
>> change to the wrong method. I have corrected the patch [1] and the 
>> CSR [2]. I have updated the language used as you suggested,
>>
>> Thanks,
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8223725/webrev.01/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8223920
>>
>> On 5/17/19 2:05 PM, Roger Riggs wrote:
>>> Hi Vicente,
>>>
>>> What's the difference in the IAE exceptions describing IAE's as
>>> being "incorrect formats' vs 'is invalid' or 'not valid'?
>>>
>>> Each requires a spec for valid and invalid strings or is undefined.
>>>
>>> Can the new IAE use the same language as is used for the 
>>> ofDescriptor method?
>>> Avoiding any question about differences.
>>>
>>> 69:? Also, is the word 'lookup' overloaded?? Is 'lookup' is 
>>> significant in this context?
>>>
>>> Roger
>>>
>>>
>>> On 05/14/2019 06:37 PM, Vicente Romero wrote:
>>>> Please review fix [1] for [2] and the corresponding CSR at [3]. The 
>>>> fix is just adding a missing @throws at method 
>>>> j.l.c.MethodHandleDesc::of. It is a one liner fix,
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] http://cr.openjdk.java.net/~vromero/8223725/webrev.00/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8223725
>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8223920
>>>
>>
>


From jonathan.gibbons at oracle.com  Mon May 20 18:11:59 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 20 May 2019 11:11:59 -0700
Subject: RFR: jsr166 integration 2019-06
In-Reply-To: <CA+kOe0_WWFpcBAEQSPG=1wtsv2pL9T2sx59SEUygGyz89YzwLQ@mail.gmail.com>
References: <CA+kOe09_4jniMDStZoBztpfF1bU2WDBP+hLo0eE-N6=LN9SdJg@mail.gmail.com>
 <CA+kOe0_WWFpcBAEQSPG=1wtsv2pL9T2sx59SEUygGyz89YzwLQ@mail.gmail.com>
Message-ID: <df9510ac-4437-05cd-07a8-06a5ac9630cc@oracle.com>

Looks good to me

-- Jon

On 5/20/19 10:49 AM, Martin Buchholz wrote:
> Adding trivial fix to this integration:
>
> 8224176: Fix inconsistencies in @jls tags in java.util.concurrent
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/jls/index.html
> https://bugs.openjdk.java.net/browse/JDK-8224176
>
>
> On Thu, May 16, 2019 at 2:58 PM Martin Buchholz <martinrb at google.com> wrote:
>
>> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
>>
>> Just another test timeout tweak:
>> 8224024: java/util/concurrent/BlockingQueue/DrainToFails.java testBounded
>> fails intermittently
>>
>> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/DrainToFails/index.html
>> https://bugs.openjdk.java.net/browse/JDK-8224024
>>
>> 8220478: java/util/concurrent/ConcurrentHashMap/ToArray.java timed out
>> intermittently
>>
>> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/forkjoin/index.html
>> 8223379: Clarify ForkJoinPool.getStealCount() javadoc
>> https://bugs.openjdk.java.net/browse/JDK-8220478
>>
>> 8223245: Miscellaneous changes imported from jsr166 CVS 2019-06
>>
>> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html
>> https://bugs.openjdk.java.net/browse/JDK-8223245
>>
>>

From joe.darcy at oracle.com  Mon May 20 18:31:34 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 20 May 2019 11:31:34 -0700
Subject: RFR: jsr166 integration 2019-06
In-Reply-To: <df9510ac-4437-05cd-07a8-06a5ac9630cc@oracle.com>
References: <CA+kOe09_4jniMDStZoBztpfF1bU2WDBP+hLo0eE-N6=LN9SdJg@mail.gmail.com>
 <CA+kOe0_WWFpcBAEQSPG=1wtsv2pL9T2sx59SEUygGyz89YzwLQ@mail.gmail.com>
 <df9510ac-4437-05cd-07a8-06a5ac9630cc@oracle.com>
Message-ID: <6faddd8c-ac76-8850-7b08-622dcb94d9db@oracle.com>

Looks good to me as well; thanks Martin,

-Joe

On 5/20/2019 11:11 AM, Jonathan Gibbons wrote:
> Looks good to me
>
> -- Jon
>
> On 5/20/19 10:49 AM, Martin Buchholz wrote:
>> Adding trivial fix to this integration:
>>
>> 8224176: Fix inconsistencies in @jls tags in java.util.concurrent
>> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/jls/index.html 
>>
>> https://bugs.openjdk.java.net/browse/JDK-8224176
>>
>>
>> On Thu, May 16, 2019 at 2:58 PM Martin Buchholz <martinrb at google.com> 
>> wrote:
>>
>>> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 
>>>
>>>
>>> Just another test timeout tweak:
>>> 8224024: java/util/concurrent/BlockingQueue/DrainToFails.java 
>>> testBounded
>>> fails intermittently
>>>
>>> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/DrainToFails/index.html 
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8224024
>>>
>>> 8220478: java/util/concurrent/ConcurrentHashMap/ToArray.java timed out
>>> intermittently
>>>
>>> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/forkjoin/index.html 
>>>
>>> 8223379: Clarify ForkJoinPool.getStealCount() javadoc
>>> https://bugs.openjdk.java.net/browse/JDK-8220478
>>>
>>> 8223245: Miscellaneous changes imported from jsr166 CVS 2019-06
>>>
>>> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html 
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8223245
>>>
>>>

From ivan.gerasimov at oracle.com  Mon May 20 18:48:32 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 20 May 2019 11:48:32 -0700
Subject: RFR 7061590 : Javadoc issues in Charset and StandardCharsets
Message-ID: <42d93f0f-f725-5c72-bd0f-4e4b768e598f@oracle.com>

Hello!

A few small javadoc issues.

The most visible one is that the last dot in abbreviation a.k.a. is 
treated as a period, so the generated description appears broken (see 
[1] 
<https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/nio/charset/StandardCharsets.html>):

static Charset    ISO_8859_1    ISO Latin Alphabet No. 1, a.k.a.
static Charset    US_ASCII      Seven-bit ASCII, a.k.a.
...

Would you please help review the fix?

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

[1] 
https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/nio/charset/StandardCharsets.html

-- 
With kind regards,
Ivan Gerasimov


From jonathan.gibbons at oracle.com  Mon May 20 18:53:56 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 20 May 2019 11:53:56 -0700
Subject: RFR 7061590 : Javadoc issues in Charset and StandardCharsets
In-Reply-To: <42d93f0f-f725-5c72-bd0f-4e4b768e598f@oracle.com>
References: <42d93f0f-f725-5c72-bd0f-4e4b768e598f@oracle.com>
Message-ID: <1b55e0c2-536c-8caa-dcef-faaa4c615945@oracle.com>

Ivan,

You would do better to avoid the use of the shorthand "a.k.a." which may 
not be known to many readers.? In general, the style should be to avoid 
abbreviations like this, including e.g. i.e. etc. (sic)

I recommend replacing "a.k.a." with "also known as:.

-- Jon


On 05/20/2019 11:48 AM, Ivan Gerasimov wrote:
> Hello!
>
> A few small javadoc issues.
>
> The most visible one is that the last dot in abbreviation a.k.a. is 
> treated as a period, so the generated description appears broken (see 
> [1] 
> <https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/nio/charset/StandardCharsets.html>):
>
> static Charset??? ISO_8859_1??? ISO Latin Alphabet No. 1, a.k.a.
> static Charset??? US_ASCII????? Seven-bit ASCII, a.k.a.
> ...
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-7061590
> WEBREV: http://cr.openjdk.java.net/~igerasim/7061590/00/webrev/
>
> [1] 
> https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/nio/charset/StandardCharsets.html
>


From Alan.Bateman at oracle.com  Mon May 20 19:03:10 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 May 2019 20:03:10 +0100
Subject: RFR 7061590 : Javadoc issues in Charset and StandardCharsets
In-Reply-To: <42d93f0f-f725-5c72-bd0f-4e4b768e598f@oracle.com>
References: <42d93f0f-f725-5c72-bd0f-4e4b768e598f@oracle.com>
Message-ID: <cad46f3f-579d-8f1f-cfb4-3d01dae2317f@oracle.com>

On 20/05/2019 19:48, Ivan Gerasimov wrote:
> Hello!
>
> A few small javadoc issues.
>
> The most visible one is that the last dot in abbreviation a.k.a. is 
> treated as a period, so the generated description appears broken (see 
> [1] 
> <https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/nio/charset/StandardCharsets.html>):
>
> static Charset??? ISO_8859_1??? ISO Latin Alphabet No. 1, a.k.a.
> static Charset??? US_ASCII????? Seven-bit ASCII, a.k.a.
> ...
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-7061590
> WEBREV: http://cr.openjdk.java.net/~igerasim/7061590/00/webrev/
I agree with Jon on the a.k.a uages.

Also Charsets puts a space after <p> so should probably keep that 
consistent.

-Alan.

From ivan.gerasimov at oracle.com  Mon May 20 19:26:45 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 20 May 2019 12:26:45 -0700
Subject: RFR 7061590 : Javadoc issues in Charset and StandardCharsets
In-Reply-To: <cad46f3f-579d-8f1f-cfb4-3d01dae2317f@oracle.com>
References: <42d93f0f-f725-5c72-bd0f-4e4b768e598f@oracle.com>
 <cad46f3f-579d-8f1f-cfb4-3d01dae2317f@oracle.com>
Message-ID: <624bf0ee-9ef7-6854-dfe3-a4f5b097e73d@oracle.com>

Thank you Jon and Alan for your suggestions!

Here's the new webrev updated accordingly:

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

With kind regards,

Ivan


On 5/20/19 12:03 PM, Alan Bateman wrote:
> On 20/05/2019 19:48, Ivan Gerasimov wrote:
>> Hello!
>>
>> A few small javadoc issues.
>>
>> The most visible one is that the last dot in abbreviation a.k.a. is 
>> treated as a period, so the generated description appears broken (see 
>> [1] 
>> <https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/nio/charset/StandardCharsets.html>):
>>
>> static Charset    ISO_8859_1    ISO Latin Alphabet No. 1, a.k.a.
>> static Charset    US_ASCII      Seven-bit ASCII, a.k.a.
>> ...
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-7061590
>> WEBREV: http://cr.openjdk.java.net/~igerasim/7061590/00/webrev/
> I agree with Jon on the a.k.a uages.
>
> Also Charsets puts a space after <p> so should probably keep that 
> consistent.
>
> -Alan.
>

-- 
With kind regards,
Ivan Gerasimov


From georgemotes at gmail.com  Mon May 20 16:21:41 2019
From: georgemotes at gmail.com (George Motes)
Date: Mon, 20 May 2019 12:21:41 -0400
Subject: Jpackage and MacOs with gatekeeper
Message-ID: <DE313B01-A526-4292-A17D-41883F37B948@gmail.com>

I have created a dmg file with jpackage on MacOS High Sierra version using jpackage.

I would like to sign the dmg file but the signing parts do not seem work with this version of the OS.

There seem to be several problems.

1. The program is hardcoded to look for an application certificate and does not support an installer certificate.
2. The login cert file is  in db format and jpackage cannot find the specified cert.

I am no expert on Mac so I could be doing something wrong, it would be great if you could provide a working example of signing a dmg file.

If you need any more info let me know.

Here is my package script:
/Users/steve/jdk-13.jdk/Contents/Home/bin/jpackage create-installer --verbose --vendor "My Company,Inc." --icon /Users/steve/Java-Dev4/Icon/dta.icns --description "My Company Desktop Application" --installer-type dmg --input /Users/steve/Java-Dev4/MY_Desktop/dist/ --output DTA --name MY_Desktop --main-jar MY_Desktop.jar  --mac-bundle-identifier MY-Desktop   --mac-bundle-name MY-Desktop --mac-sign --mac-signing-key-user-name "My Company, Inc. (XXXXWJW)" --mac-signing-keychain /Users/steve/Library/Keychains/login.keychain-db


The error:
Running [security, find-certificate, -c, Developer ID Application: My Company, Inc. (XXXXWJW), -a, /Users/steve/Library/Keychains/login.keychain-db]
Did not find a key matching 'Developer ID Application: My Company, Inc. (XXXXWJW)'
jdk.jpackage.internal.PackagerException: Bundler DMG Installer skipped because of a configuration problem: Signature explicitly requested but no signing certificate specified.. 
Advice to fix: Either specify a valid cert in 'mac.signing-key-developer-id-app' or unset 'signBundle' or set 'signBundle' to false.


Thanks

From vicente.romero at oracle.com  Mon May 20 19:29:05 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 20 May 2019 15:29:05 -0400
Subject: RFR: JDK-8223914: specification of j.l.c.MethodTypeDesc::of
 should document better the exceptions thrown
In-Reply-To: <7520e768-3445-bfbb-5619-8f4d5b5da59a@oracle.com>
References: <8991ce18-0b54-d0e8-3dcd-6581fde5141b@oracle.com>
 <7520e768-3445-bfbb-5619-8f4d5b5da59a@oracle.com>
Message-ID: <fa299489-7444-c3ce-710c-600949d3f74a@oracle.com>

Hi Roger,

On 5/20/19 2:00 PM, Roger Riggs wrote:
> Hi Vicente,
>
> In the CSR, the Summary should be about the change... 
> "...MethodTypeDesc::of should document all exceptions.
> Avoid duplication between Summary and Problem.

thanks, I saw that you already modified the Summary
>
> I would omit the part about "content of parameter" or "its contents" 
> is null;
> It cannot happen and if it does, its more of an internal error than a 
> regular NPE
> since it should not be possible to create a ClassDesc with a null 
> descriptor string.

this spec comment was included in this one an other similar methods. It 
is probably a bit of an overkill but we have already changed the spec of 
several similar methods to this pattern, see for example [1]

>
> In the Code Review:
>
> MethodTypeDesc.java: 68:? as above, "or its contents are" -> "is "? 
> there's no need to mention the contents.
>
> MethodTypeDescTest.java: 264 and 274.? The messages would be more 
> useful (if they ever were to happen)
> and for the person reading the code if they describe what should not 
> happen.
> For example,? "ClassDesc array should not be null"? or ClassDesc 
> should not be null.

I made this change in the test comment [2]
>
> Thanks, Roger

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8223803
[2] http://cr.openjdk.java.net/~vromero/8223914/webrev.01/

>
>
> On 05/17/2019 12:55 PM, Vicente Romero wrote:
>> Please review simple fix for [1] at [2] plus the CSR at [3]. This fix 
>> is simply documenting all the missing cases in which method 
>> java.lang.constant.MethodTypeDesc::of can throw exceptions. A test 
>> has been added to cover the missing cases.
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223914
>> [2] http://cr.openjdk.java.net/~vromero/8223914/webrev.00/
>> [3] https://bugs.openjdk.java.net/browse/JDK-8224136
>


From cycraig33 at gmail.com  Mon May 20 19:36:16 2019
From: cycraig33 at gmail.com (Craig Bester)
Date: Mon, 20 May 2019 12:36:16 -0700 (MST)
Subject: jpackage multiple --add-exports
Message-ID: <1558380976823-0.post@n7.nabble.com>

Hi!

When using the JDK13-EA jpackage utility (https://jdk.java.net/jpackage)
specifying multiple ?--add-exports' arguments with ?--java-options' results
in the executable only passing the first ?--add-exports' to the JVM.

For example, if the .cfg file generated by jpackage holds the following
arguments:

[JavaOptions]
--module-path=.
--add-exports=java.base/sun.security.util=AppName,ALL-UNNAMED
--add-exports=javafx.controls/com.sun.javafx.scene.control.skin=AppName,ALL-UNNAMED
--add-modules=jdk.unsupported.desktop,javafx.controls,javafx.swing

The second ?--add-exports' will be ignored and an IllegalAccessError will be
thrown when attempting to access anything under
com.sun.javafx.scene.control.skin. The same issue occurs when using the
older javapackager too. Switching the order of the statements causes
sun.security.util calls to throw an IllegalAccessError instead.

Running the jar directly works fine: ?java --module-path=.
--add-exports=java.base/sun.security.util=AppName,ALL-UNNAMED
--add-exports=javafx.controls/com.sun.javafx.scene.control.skin=AppName,ALL-UNNAMED
--add-modules=jdk.unsupported.desktop,javafx.controls,javafx.swing -jar
AppName.jar?

Is there an alternative method to specify exports when packaging a jar?
Specifying ?Add-Exports? in the jar manifest does not work.



--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Core-Libraries-f45829.html

From vicente.romero at oracle.com  Mon May 20 19:58:55 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 20 May 2019 15:58:55 -0400
Subject: RFR: JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented
 exception IllegalArgumentException
In-Reply-To: <5e04f19f-12db-4ecd-692c-ea4529963044@oracle.com>
References: <953e6ae5-365d-251a-901f-a58fc889d9f5@oracle.com>
 <6f066d47-cd8d-00d8-17ec-502e36088028@oracle.com>
 <397f5929-41dc-72ca-505c-c4532994481f@oracle.com>
 <0b94fc1f-30b5-9abb-5504-96560b140ad3@oracle.com>
 <5e04f19f-12db-4ecd-692c-ea4529963044@oracle.com>
Message-ID: <3ca20364-9e77-e22e-b261-a1321bcb8ba5@oracle.com>

thanks for the review,
Vicente

On 5/20/19 2:09 PM, Roger Riggs wrote:
> Hi Vicente,
>
> Looks ok.
>
> Can you ident the 2nd and subsequent lines of the javadoc tag,
> as is done in the other tags of the method.
> No need for another webrev.
>
> Thanks, Roger
>
> On 05/20/2019 01:07 PM, Vicente Romero wrote:
>> how does it look now?
>>
>> Thanks,
>> Vicente
>>
>> On 5/17/19 3:58 PM, Vicente Romero wrote:
>>> Hi Roger,
>>>
>>> Thanks for the review, my apologies, I made a mistake an applied the 
>>> change to the wrong method. I have corrected the patch [1] and the 
>>> CSR [2]. I have updated the language used as you suggested,
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] http://cr.openjdk.java.net/~vromero/8223725/webrev.01/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8223920
>>>
>>> On 5/17/19 2:05 PM, Roger Riggs wrote:
>>>> Hi Vicente,
>>>>
>>>> What's the difference in the IAE exceptions describing IAE's as
>>>> being "incorrect formats' vs 'is invalid' or 'not valid'?
>>>>
>>>> Each requires a spec for valid and invalid strings or is undefined.
>>>>
>>>> Can the new IAE use the same language as is used for the 
>>>> ofDescriptor method?
>>>> Avoiding any question about differences.
>>>>
>>>> 69:? Also, is the word 'lookup' overloaded?? Is 'lookup' is 
>>>> significant in this context?
>>>>
>>>> Roger
>>>>
>>>>
>>>> On 05/14/2019 06:37 PM, Vicente Romero wrote:
>>>>> Please review fix [1] for [2] and the corresponding CSR at [3]. 
>>>>> The fix is just adding a missing @throws at method 
>>>>> j.l.c.MethodHandleDesc::of. It is a one liner fix,
>>>>>
>>>>> Thanks,
>>>>> Vicente
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~vromero/8223725/webrev.00/
>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8223725
>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8223920
>>>>
>>>
>>
>


From alexander.matveev at oracle.com  Mon May 20 22:07:17 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 20 May 2019 15:07:17 -0700
Subject: RFR: JDK-8224222: Inno setup 6 broke jpackage
In-Reply-To: <00d2aaa2-db60-cd20-f7a0-77f988632718@oracle.com>
References: <00d2aaa2-db60-cd20-f7a0-77f988632718@oracle.com>
Message-ID: <d3ca0c29-9dd5-6adc-0137-69a588123fdb@oracle.com>

Hi Alexey,

Is there better way to figure out InnoSetup version? Creating empty 
project file seems complicated.
If there no such way, then fix looks fine.

Thanks,
Alexander

On 5/20/2019 8:27 AM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox
> repository (jpackage).
>
> - Improve code detecting version of Inno Setup to make it work with 
> Inno Setup v6 updates.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8224222
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8224222/webrev.00/
>
> Thanks,
> Alexey


From stuart.marks at oracle.com  Mon May 20 22:57:58 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 20 May 2019 15:57:58 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <387E2F97-B1C6-4C94-973C-6D0CD8F0EE9A@cbfiddle.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>
 <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com>
 <C8F82E77-C1A6-4A7D-A984-8F2B32883620@cbfiddle.com>
 <ef9cde9c-909b-9387-3165-58e62a6bdbcc@gmail.com>
 <387E2F97-B1C6-4C94-973C-6D0CD8F0EE9A@cbfiddle.com>
Message-ID: <c891388f-3407-4eba-314a-7d8a1ac14d50@oracle.com>

On 5/16/19 10:06 PM, Alan Snyder wrote:
> Could you explain the inconsistency in the specification that affects removeAll()? I don?t see it.

It's the assumption that the operation can be reversed without changing its 
semantics. This isn't true, given the existence of SortedSet et. al. This is the 
point of this bug report. The inconsistency exists in the collections framework 
specifications taken as a whole, not removeAll() in isolation.

> I believe I already accepted the fact of ersatz Collections.

Of course I don't know your state of mind, but it it doesn't sound to me like 
you've accepted them. You're calling them "ersatz" collections, which sound to 
me like "fake" collections. You're carving them out of "real" collections and 
treating them like second-class citizens. I would have thought that was an 
overstatement, until I read this:

> Promoting ersatz Collections to first class citizens would be a significant incompatible change...

My goal here is to reconcile the various parts of the collections framework 
specifications so that they are more self-consistent as a whole. Treating 
certain pieces as second-class citizens makes the problem worse, not better.

> What I would most like to preserve is the performance advantages of using hash coding, which apparently was a goal of the original design:
> 
> "implementations of the various Collections Framework interfaces are free to take advantage of the specified behavior of underlying {@link Object} methods wherever the implementor deems it appropriate"
> 
> Promoting ersatz Collections to first class citizens would be a significant incompatible change to the specification because it invalidates this statement.

My changes don't affect the relationship of equals() and hashCode() in the 
slightest.

s'marks


From huizhe.wang at oracle.com  Mon May 20 23:06:45 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 20 May 2019 16:06:45 -0700
Subject: RFR (jdk13/java.xml) 8219692: DOM and SAX parser ignore namespace
Message-ID: <5CE33305.6040505@oracle.com>

Please review an enhancement to the DOM and SAX factories. By default, 
DOM/SAX factories created using the existing newInstance methods do not 
support XML Namespace. Parsers instantiated with such factories would 
therefore ignore namespaces. Users not realizing or unaware of the 
legacy setting may run into the issue as demonstrated in the bug 
description.

This patch addresses the issue by introducing new methods that must set 
NamespaceAware to true. Factories instantiated using these methods can 
therefore create parsers that support XML Namespace by default.

JBS: https://bugs.openjdk.java.net/browse/JDK-8219692
webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219692/webrev/

Thanks,
Joe

From lance.andersen at oracle.com  Mon May 20 23:09:53 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 20 May 2019 19:09:53 -0400
Subject: RFR (jdk13/java.xml) 8219692: DOM and SAX parser ignore namespace
In-Reply-To: <5CE33305.6040505@oracle.com>
References: <5CE33305.6040505@oracle.com>
Message-ID: <B376D076-5489-4164-B0D6-15763B53B2C3@oracle.com>

Hi Joe,

As we discussed off-line, these changes look  OK.  Please double check that the copyright is updated in the relevant files.

Best
Lance
> On May 20, 2019, at 7:06 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Please review an enhancement to the DOM and SAX factories. By default, DOM/SAX factories created using the existing newInstance methods do not support XML Namespace. Parsers instantiated with such factories would therefore ignore namespaces. Users not realizing or unaware of the legacy setting may run into the issue as demonstrated in the bug description.
> 
> This patch addresses the issue by introducing new methods that must set NamespaceAware to true. Factories instantiated using these methods can therefore create parsers that support XML Namespace by default.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8219692
> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219692/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 andy.herrick at oracle.com  Mon May 20 23:32:02 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 20 May 2019 19:32:02 -0400
Subject: jpackage multiple --add-exports
In-Reply-To: <1558380976823-0.post@n7.nabble.com>
References: <1558380976823-0.post@n7.nabble.com>
Message-ID: <81773c56-6eb2-62cc-158f-ec630310eac0@oracle.com>

I've been trying your example (or something I have created that is close 
to it) and thought I was seeing multiple --add-exports are passed to the 
VM in my case.

But on closer look I think when I have 3 "--java-options 
--add-exports=..." jpackager options, I get the three expected lines in 
[JavaOptions], but the VM starting the app seems to get the first 
--add-exports argument 3 times, instead of the three distinct ones.

This is clearly a bug I will file tomorrow.

It also shows the need for easier debuging of these cases.? We should 
have some mechanism to see the full set of args passed to the VM.

/Andy



On 5/20/2019 3:36 PM, Craig Bester wrote:
> Hi!
>
> When using the JDK13-EA jpackage utility (https://jdk.java.net/jpackage)
> specifying multiple ?--add-exports' arguments with ?--java-options' results
> in the executable only passing the first ?--add-exports' to the JVM.
>
> For example, if the .cfg file generated by jpackage holds the following
> arguments:
>
> [JavaOptions]
> --module-path=.
> --add-exports=java.base/sun.security.util=AppName,ALL-UNNAMED
> --add-exports=javafx.controls/com.sun.javafx.scene.control.skin=AppName,ALL-UNNAMED
> --add-modules=jdk.unsupported.desktop,javafx.controls,javafx.swing
>
> The second ?--add-exports' will be ignored and an IllegalAccessError will be
> thrown when attempting to access anything under
> com.sun.javafx.scene.control.skin. The same issue occurs when using the
> older javapackager too. Switching the order of the statements causes
> sun.security.util calls to throw an IllegalAccessError instead.
>
> Running the jar directly works fine: ?java --module-path=.
> --add-exports=java.base/sun.security.util=AppName,ALL-UNNAMED
> --add-exports=javafx.controls/com.sun.javafx.scene.control.skin=AppName,ALL-UNNAMED
> --add-modules=jdk.unsupported.desktop,javafx.controls,javafx.swing -jar
> AppName.jar?
>
> Is there an alternative method to specify exports when packaging a jar?
> Specifying ?Add-Exports? in the jar manifest does not work.
>
>
>
> --
> Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Core-Libraries-f45829.html


From stuart.marks at oracle.com  Mon May 20 23:53:48 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 20 May 2019 16:53:48 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <ef9cde9c-909b-9387-3165-58e62a6bdbcc@gmail.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>
 <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com>
 <C8F82E77-C1A6-4A7D-A984-8F2B32883620@cbfiddle.com>
 <ef9cde9c-909b-9387-3165-58e62a6bdbcc@gmail.com>
Message-ID: <32291cb3-a2e2-b3ba-5396-f6b8c8deb17f@oracle.com>

On 5/16/19 11:48 PM, Peter Levart wrote:
> As Stuart says, optimizations mustn't change semantics. So is there a possibly 
> narrower optimization, that doesn't change the semantics?
> 
> Here's a sketch of one:
> - create a marker interface (could be JDK-internal) and mark all conforming Set 
> implementations with it
> - use AbstractSet.removeAll optimization only when both collections implement 
> the marker interface

Hi Peter,

It's certainly reasonable for there to be some concern over the potential 
performance loss. I don't particularly like the fact that even as we're 
improving the semantics, that some programs will suffer a slowdown, even those 
that aren't actually affected by the semantic issues.

However, I'm not convinced that we really understand the performance issue. When 
this was brought up in January, [1] the claim was that this wasted thousands of 
CPU hours. I'm skeptical. To back this up, in a followup message [2] the 
original poster linked to a Stack Overflow question [3] that turns out to have 
been derived from an old article by Jon Skeet [4]. To be sure, this is an 
interesting technical discussion, but it doesn't count as evidence that this is 
an actual performance problem.

If you look at the example closely, it turns out that it calls removeAll() and 
passes an argument a List with 300,000 elements. If you're doing operations on 
large lists, maybe you shouldn't be surprised to see a slowdown. Maybe instead 
you should have been surprised (in the iteration-switched case) that it ran 
reasonably fast at all.

Nonetheless it remains a possibility that some code that worked properly and 
performed reasonably well will suffer a slowdown. One way -- and I stress that 
this is only one way -- that performance might be improved is to switch the 
collection upon which iteration is done. The linked bug reports have a bunch of 
suggestions for doing this, including checking to see whether the argument is a 
List. To these I'd add the stipulation that, the iteration can be switched if it 
can be determined that it is *safe* to do so; and the safety depends on whether 
the two collections use compatible membership semantics.

Collections that use equals() are compatible with each other; keysets of 
IdentityHashMap are compatible with each other; SortedSets that use identical 
comparison methods are compatible with each other. But note, SortedSets that use 
a comparisons methods that are consistent with equals are also compatible with 
collections that use equals(). And it seems likely to be undecidable whether two 
different (!=) comparison methods are in fact compatible.

In any case it would interesting to try to chew on this notion of compatible 
membership semantics for a while. It might be difficult to come up with a 
complete and correct test. It's probably easier to come up with an 
approximation, like ConcurrentSkipListMap's equals() method. [5] I'm not sure 
such a discussion would be fruitful, though, until we're sure we understand how 
much of a performance problem this actually is.

s'marks




[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html

[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html

[3] 
https://stackoverflow.com/questions/28671903/the-hashsett-removeall-method-is-surprisingly-slow

[4] 
https://codeblog.jonskeet.uk/2010/07/29/there-s-a-hole-in-my-abstraction-dear-liza-dear-liza/

[5] 
http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java#l1706

From robert.field at oracle.com  Mon May 20 23:56:01 2019
From: robert.field at oracle.com (Robert Field)
Date: Mon, 20 May 2019 16:56:01 -0700
Subject: JDK 13 RFR of JDK-8224175: Fix inconsistencies in @jls and @jvms
 tags
In-Reply-To: <478b540e-35a0-b9df-8bf3-c03b0422af8f@oracle.com>
References: <478b540e-35a0-b9df-8bf3-c03b0422af8f@oracle.com>
Message-ID: <655efe09-5314-3938-a88f-c11e39166de4@oracle.com>

Thumbs up on the JShell changes.

-Robert


On 5/19/19 12:36 PM, Joe Darcy wrote:
> Hello,
>
> Thanks to some tooling developed by Jon Gibbons, inconsistencies in 
> the section names and numbers in the @jls and @jvms javadoc tags in 
> the jdk and the names and numbers of the current specifications have 
> been identified. These inconsistencies should be fixed.
>
> The names and numbers of the section titles in JLS and JVMS are 
> *mostly* stable, but a few sections have changed most notably for the 
> usage of @jls tags:
>
> ??? * 8.9 "Enum" -> "Enum Type" in Java SE 8
> ??? * 5.1.2 "Widening Primitive Conversions" -> "Widening Primitive 
> *Conversion*" in Java SE 7
>
> Two uses of "@jvms 5.3 Run-time package" refer to the term "Run-time 
> package" defined in that section. The term was replaced by the section 
> name in both cases.
>
> In java.lang.SuppressWarnings, a reference to the section "5.5.2 
> Checked Casts and Unchecked Casts", which was removed in Java SE 9, 
> was replaced with a reference to the enclosing section "5.5. Casting 
> Contexts".
>
> The usage of @jls in jshell was less consistent and has been regularized.
>
> Full webrev at:
>
> ??? http://cr.openjdk.java.net/~darcy/8224175.0/
>
> Patch below.
>
> Thanks,
>
> -Joe
>
> --- old/src/java.base/share/classes/java/lang/Byte.java 2019-05-19 
> 12:16:26.705761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Byte.java 2019-05-19 
> 12:16:26.137761266 -0700
> @@ -356,7 +356,7 @@
> ???? /**
> ????? * Returns the value of this {@code Byte} as a {@code short} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public short shortValue() {
> ???????? return (short)value;
> @@ -365,7 +365,7 @@
> ???? /**
> ????? * Returns the value of this {@code Byte} as an {@code int} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public int intValue() {
> ???????? return (int)value;
> @@ -374,7 +374,7 @@
> ???? /**
> ????? * Returns the value of this {@code Byte} as a {@code long} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public long longValue() {
> ???????? return (long)value;
> @@ -383,7 +383,7 @@
> ???? /**
> ????? * Returns the value of this {@code Byte} as a {@code float} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public float floatValue() {
> ???????? return (float)value;
> @@ -392,7 +392,7 @@
> ???? /**
> ????? * Returns the value of this {@code Byte} as a {@code double}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public double doubleValue() {
> ???????? return (double)value;
> --- old/src/java.base/share/classes/java/lang/Class.java 2019-05-19 
> 12:16:27.597761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Class.java 2019-05-19 
> 12:16:27.161761266 -0700
> @@ -999,7 +999,7 @@
> ????? *
> ????? * @since 9
> ????? * @spec JPMS
> -???? * @jls 6.7? Fully Qualified Names
> +???? * @jls 6.7 Fully Qualified Names
> ????? */
> ???? public String getPackageName() {
> ???????? String pn = this.packageName;
> @@ -3910,7 +3910,8 @@
> ????? *???????? SecurityManager#checkPackageAccess 
> s.checkPackageAccess()}
> ????? *???????? denies access to the package of the returned class
> ????? * @since 11
> -???? * @jvms 4.7.28 and 4.7.29 NestHost and NestMembers attributes
> +???? * @jvms 4.7.28 The {@code NestHost} Attribute
> +???? * @jvms 4.7.29 The {@code NestMembers} Attribute
> ????? * @jvms 5.4.4 Access Control
> ????? */
> ???? @CallerSensitive
> --- old/src/java.base/share/classes/java/lang/ClassLoader.java 
> 2019-05-19 12:16:28.429761266 -0700
> +++ new/src/java.base/share/classes/java/lang/ClassLoader.java 
> 2019-05-19 12:16:28.041761266 -0700
> @@ -222,7 +222,7 @@
> ? * or a fully qualified name as defined by
> ? * <cite>The Java&trade; Language Specification</cite>.
> ? *
> - * @jls 6.7? Fully Qualified Names
> + * @jls 6.7 Fully Qualified Names
> ? * @jls 13.1 The Form of a Binary
> ? * @see????? #resolveClass(Class)
> ? * @since 1.0
> @@ -2194,7 +2194,7 @@
> ????? * @revised 9
> ????? * @spec JPMS
> ????? *
> -???? * @jvms 5.3 Run-time package
> +???? * @jvms 5.3 Creation and Loading
> ????? * @see <a href="{@docRoot}/../specs/jar/jar.html#package-sealing">
> ????? *????? The JAR File Specification: Package Sealing</a>
> ????? */
> @@ -2228,7 +2228,7 @@
> ????? * @throws? NullPointerException
> ????? *????????? if {@code name} is {@code null}.
> ????? *
> -???? * @jvms 5.3 Run-time package
> +???? * @jvms 5.3 Creation and Loading
> ????? *
> ????? * @since? 9
> ????? * @spec JPMS
> @@ -2255,7 +2255,7 @@
> ????? *???????? this class loader; or an zero length array if no 
> package has been
> ????? *???????? defined by this class loader.
> ????? *
> -???? * @jvms 5.3 Run-time package
> +???? * @jvms 5.3 Creation and Loading
> ????? *
> ????? * @since? 9
> ????? * @spec JPMS
> --- old/src/java.base/share/classes/java/lang/Double.java 2019-05-19 
> 12:16:29.205761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Double.java 2019-05-19 
> 12:16:28.809761266 -0700
> @@ -673,7 +673,7 @@
> ????? *
> ????? * @return? the {@code double} value represented by this object
> ????? *????????? converted to type {@code byte}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? * @since 1.1
> ????? */
> ???? public byte byteValue() {
> @@ -686,7 +686,7 @@
> ????? *
> ????? * @return? the {@code double} value represented by this object
> ????? *????????? converted to type {@code short}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? * @since 1.1
> ????? */
> ???? public short shortValue() {
> @@ -696,7 +696,7 @@
> ???? /**
> ????? * Returns the value of this {@code Double} as an {@code int}
> ????? * after a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? *
> ????? * @return? the {@code double} value represented by this object
> ????? *????????? converted to type {@code int}
> @@ -711,7 +711,7 @@
> ????? *
> ????? * @return? the {@code double} value represented by this object
> ????? *????????? converted to type {@code long}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public long longValue() {
> ???????? return (long)value;
> @@ -723,7 +723,7 @@
> ????? *
> ????? * @return? the {@code double} value represented by this object
> ????? *????????? converted to type {@code float}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? * @since 1.0
> ????? */
> ???? public float floatValue() {
> --- old/src/java.base/share/classes/java/lang/Float.java 2019-05-19 
> 12:16:30.133761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Float.java 2019-05-19 
> 12:16:29.637761266 -0700
> @@ -602,7 +602,7 @@
> ????? *
> ????? * @return? the {@code float} value represented by this object
> ????? *????????? converted to type {@code byte}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public byte byteValue() {
> ???????? return (byte)value;
> @@ -614,7 +614,7 @@
> ????? *
> ????? * @return? the {@code float} value represented by this object
> ????? *????????? converted to type {@code short}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? * @since 1.1
> ????? */
> ???? public short shortValue() {
> @@ -627,7 +627,7 @@
> ????? *
> ????? * @return? the {@code float} value represented by this object
> ????? *????????? converted to type {@code int}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public int intValue() {
> ???????? return (int)value;
> @@ -639,7 +639,7 @@
> ????? *
> ????? * @return? the {@code float} value represented by this object
> ????? *????????? converted to type {@code long}
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public long longValue() {
> ???????? return (long)value;
> @@ -661,7 +661,7 @@
> ????? *
> ????? * @return the {@code float} value represented by this
> ????? *???????? object converted to type {@code double}
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public double doubleValue() {
> ???????? return (double)value;
> --- old/src/java.base/share/classes/java/lang/FunctionalInterface.java 
> 2019-05-19 12:16:31.105761266 -0700
> +++ new/src/java.base/share/classes/java/lang/FunctionalInterface.java 
> 2019-05-19 12:16:30.609761266 -0700
> @@ -57,7 +57,7 @@
> ? * regardless of whether or not a {@code FunctionalInterface}
> ? * annotation is present on the interface declaration.
> ? *
> - * @jls 4.3.2. The Class Object
> + * @jls 4.3.2 The Class Object
> ? * @jls 9.8 Functional Interfaces
> ? * @jls 9.4.3 Interface Method Body
> ? * @jls 9.6.4.9 @FunctionalInterface
> --- old/src/java.base/share/classes/java/lang/Integer.java 2019-05-19 
> 12:16:31.997761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Integer.java 2019-05-19 
> 12:16:31.529761266 -0700
> @@ -1120,7 +1120,7 @@
> ???? /**
> ????? * Returns the value of this {@code Integer} as a {@code byte}
> ????? * after a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public byte byteValue() {
> ???????? return (byte)value;
> @@ -1129,7 +1129,7 @@
> ???? /**
> ????? * Returns the value of this {@code Integer} as a {@code short}
> ????? * after a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public short shortValue() {
> ???????? return (short)value;
> @@ -1147,7 +1147,7 @@
> ???? /**
> ????? * Returns the value of this {@code Integer} as a {@code long}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? * @see Integer#toUnsignedLong(int)
> ????? */
> ???? public long longValue() {
> @@ -1157,7 +1157,7 @@
> ???? /**
> ????? * Returns the value of this {@code Integer} as a {@code float}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public float floatValue() {
> ???????? return (float)value;
> @@ -1166,7 +1166,7 @@
> ???? /**
> ????? * Returns the value of this {@code Integer} as a {@code double}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public double doubleValue() {
> ???????? return (double)value;
> --- old/src/java.base/share/classes/java/lang/Long.java 2019-05-19 
> 12:16:32.785761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Long.java 2019-05-19 
> 12:16:32.369761266 -0700
> @@ -1339,7 +1339,7 @@
> ???? /**
> ????? * Returns the value of this {@code Long} as a {@code byte} after
> ????? * a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public byte byteValue() {
> ???????? return (byte)value;
> @@ -1348,7 +1348,7 @@
> ???? /**
> ????? * Returns the value of this {@code Long} as a {@code short} after
> ????? * a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public short shortValue() {
> ???????? return (short)value;
> @@ -1357,7 +1357,7 @@
> ???? /**
> ????? * Returns the value of this {@code Long} as an {@code int} after
> ????? * a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public int intValue() {
> ???????? return (int)value;
> @@ -1375,7 +1375,7 @@
> ???? /**
> ????? * Returns the value of this {@code Long} as a {@code float} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public float floatValue() {
> ???????? return (float)value;
> @@ -1384,7 +1384,7 @@
> ???? /**
> ????? * Returns the value of this {@code Long} as a {@code double}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public double doubleValue() {
> ???????? return (double)value;
> --- old/src/java.base/share/classes/java/lang/Number.java 2019-05-19 
> 12:16:33.561761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Number.java 2019-05-19 
> 12:16:33.157761266 -0700
> @@ -48,8 +48,8 @@
> ? *
> ? * @author????? Lee Boynton
> ? * @author????? Arthur van Hoff
> - * @jls 5.1.2 Widening Primitive Conversions
> - * @jls 5.1.3 Narrowing Primitive Conversions
> + * @jls 5.1.2 Widening Primitive Conversion
> + * @jls 5.1.3 Narrowing Primitive Conversion
> ? * @since?? 1.0
> ? */
> ?public abstract class Number implements java.io.Serializable {
> --- old/src/java.base/share/classes/java/lang/Package.java 2019-05-19 
> 12:16:34.325761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Package.java 2019-05-19 
> 12:16:33.929761266 -0700
> @@ -108,7 +108,7 @@
> ? * <em>named modules</em>.? Instead those packages are automatically 
> defined
> ? * and have no specification and implementation versioning information.
> ? *
> - * @jvms 5.3 Run-time package
> + * @jvms 5.3 Creation and Loading
> ? * @see <a href="{@docRoot}/../specs/jar/jar.html#package-sealing">
> ? * The JAR File Specification: Package Sealing</a>
> ? * @see ClassLoader#definePackage(String, String, String, String, 
> String, String, String, URL)
> --- old/src/java.base/share/classes/java/lang/Short.java 2019-05-19 
> 12:16:35.109761266 -0700
> +++ new/src/java.base/share/classes/java/lang/Short.java 2019-05-19 
> 12:16:34.701761266 -0700
> @@ -352,7 +352,7 @@
> ???? /**
> ????? * Returns the value of this {@code Short} as a {@code byte} after
> ????? * a narrowing primitive conversion.
> -???? * @jls 5.1.3 Narrowing Primitive Conversions
> +???? * @jls 5.1.3 Narrowing Primitive Conversion
> ????? */
> ???? public byte byteValue() {
> ???????? return (byte)value;
> @@ -370,7 +370,7 @@
> ???? /**
> ????? * Returns the value of this {@code Short} as an {@code int} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public int intValue() {
> ???????? return (int)value;
> @@ -379,7 +379,7 @@
> ???? /**
> ????? * Returns the value of this {@code Short} as a {@code long} after
> ????? * a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public long longValue() {
> ???????? return (long)value;
> @@ -388,7 +388,7 @@
> ???? /**
> ????? * Returns the value of this {@code Short} as a {@code float}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public float floatValue() {
> ???????? return (float)value;
> @@ -397,7 +397,7 @@
> ???? /**
> ????? * Returns the value of this {@code Short} as a {@code double}
> ????? * after a widening primitive conversion.
> -???? * @jls 5.1.2 Widening Primitive Conversions
> +???? * @jls 5.1.2 Widening Primitive Conversion
> ????? */
> ???? public double doubleValue() {
> ???????? return (double)value;
> --- old/src/java.base/share/classes/java/lang/SuppressWarnings.java 
> 2019-05-19 12:16:35.933761266 -0700
> +++ new/src/java.base/share/classes/java/lang/SuppressWarnings.java 
> 2019-05-19 12:16:35.485761266 -0700
> @@ -49,7 +49,7 @@
> ? * @jls 4.8 Raw Types
> ? * @jls 4.12.2 Variables of Reference Type
> ? * @jls 5.1.9 Unchecked Conversion
> - * @jls 5.5.2 Checked Casts and Unchecked Casts
> + * @jls 5.5 Casting Contexts
> ? * @jls 9.6.4.5 @SuppressWarnings
> ? */
> ?@Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, 
> MODULE})
> --- old/src/java.base/share/classes/java/lang/constant/Constable.java 
> 2019-05-19 12:16:36.717761266 -0700
> +++ new/src/java.base/share/classes/java/lang/constant/Constable.java 
> 2019-05-19 12:16:36.285761266 -0700
> @@ -59,7 +59,7 @@
> ? * method handles, but not necessarily those produced by method handle
> ? * combinators.)
> ? * @jvms 4.4 The Constant Pool
> - * @jvms 4.4.10 The CONSTANT_InvokeDynamic_info Structure
> + * @jvms 4.4.10 The {@code CONSTANT_Dynamic_info} and {@code 
> CONSTANT_InvokeDynamic_info} Structures
> ? *
> ? * @since 12
> ? */
> --- old/src/java.base/share/classes/java/lang/reflect/Method.java 
> 2019-05-19 12:16:37.521761266 -0700
> +++ new/src/java.base/share/classes/java/lang/reflect/Method.java 
> 2019-05-19 12:16:37.117761266 -0700
> @@ -403,7 +403,7 @@
> ????? * @return a string describing this {@code Method}
> ????? *
> ????? * @jls 8.4.3 Method Modifiers
> -???? * @jls 9.4?? Method Declarations
> +???? * @jls 9.4 Method Declarations
> ????? * @jls 9.6.1 Annotation Type Elements
> ????? */
> ???? public String toString() {
> @@ -474,7 +474,7 @@
> ????? * @since 1.5
> ????? *
> ????? * @jls 8.4.3 Method Modifiers
> -???? * @jls 9.4?? Method Declarations
> +???? * @jls 9.4 Method Declarations
> ????? * @jls 9.6.1 Annotation Type Elements
> ????? */
> ???? @Override
> --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java 
> 2019-05-19 12:16:38.353761266 -0700
> +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java 
> 2019-05-19 12:16:37.917761266 -0700
> @@ -394,7 +394,7 @@
>
> ???? /**
> ????? * The Java source modifiers that can be applied to a field.
> -???? * @jls 8.3.1? Field Modifiers
> +???? * @jls 8.3.1 Field Modifiers
> ????? */
> ???? private static final int FIELD_MODIFIERS =
> ???????? Modifier.PUBLIC???????? | Modifier.PROTECTED??? | 
> Modifier.PRIVATE |
> --- 
> old/src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java 
> 2019-05-19 12:16:39.161761266 -0700
> +++ 
> new/src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java 
> 2019-05-19 12:16:38.757761266 -0700
> @@ -114,7 +114,7 @@
> ? *
> ? * @since 1.8
> ? * @jls 9.6 Annotation Types
> - * @jls 9.6.3.3 @Inherited
> + * @jls 9.6.4.3 {@code @Inherited}
> ? */
> ?public interface AnnotatedConstruct {
> ???? /**
> --- 
> old/src/java.compiler/share/classes/javax/lang/model/element/Element.java 
> 2019-05-19 12:16:40.001761266 -0700
> +++ 
> new/src/java.compiler/share/classes/javax/lang/model/element/Element.java 
> 2019-05-19 12:16:39.525761266 -0700
> @@ -196,7 +196,7 @@
> ????? * @see ModuleElement#getEnclosedElements
> ????? * @see Elements#getAllMembers
> ????? * @jls 8.8.9 Default Constructor
> -???? * @jls 8.9 Enums
> +???? * @jls 8.9 Enum Types
> ????? * @revised 9
> ????? * @spec JPMS
> ????? */
> --- 
> old/src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java 
> 2019-05-19 12:16:40.801761266 -0700
> +++ 
> new/src/java.compiler/share/classes/javax/lang/model/element/NestingKind.java 
> 2019-05-19 12:16:40.397761266 -0700
> @@ -111,7 +111,7 @@
> ????? * More specifically, an <i>inner</i> type element is any nested 
> type element that
> ????? * is not {@linkplain Modifier#STATIC static}.
> ????? * @return whether or not the constant is nested
> -???? * @jls 14.3 Inner Classes and Enclosing Instances
> +???? * @jls 14.3 Local Class Declarations
> ????? */
> ???? public boolean isNested() {
> ???????? return this != TOP_LEVEL;
> --- 
> old/src/java.compiler/share/classes/javax/lang/model/util/Types.java 
> 2019-05-19 12:16:41.557761266 -0700
> +++ 
> new/src/java.compiler/share/classes/javax/lang/model/util/Types.java 
> 2019-05-19 12:16:41.161761266 -0700
> @@ -104,7 +104,7 @@
> ????? * @return {@code true} if and only if the first type is assignable
> ????? *????????? to the second
> ????? * @throws IllegalArgumentException if given a type for an 
> executable, package, or module
> -???? * @jls 5.2 Assignment Conversion
> +???? * @jls 5.2 Assignment Contexts
> ????? */
> ???? boolean isAssignable(TypeMirror t1, TypeMirror t2);
>
> @@ -115,7 +115,7 @@
> ????? * @param t2? the second type
> ????? * @return {@code true} if and only if the first type contains 
> the second
> ????? * @throws IllegalArgumentException if given a type for an 
> executable, package, or module
> -???? * @jls 4.5.1.1 Type Argument Containment and Equivalence
> +???? * @jls 4.5.1 Type Arguments of Parameterized Types
> ????? */
> ???? boolean contains(TypeMirror t1, TypeMirror t2);
>
> --- 
> old/src/jdk.compiler/share/classes/com/sun/source/tree/BinaryTree.java 
> 2019-05-19 12:16:42.329761266 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/source/tree/BinaryTree.java 
> 2019-05-19 12:16:41.929761266 -0700
> @@ -40,8 +40,8 @@
> ? * @jls 15.20 Relational Operators
> ? * @jls 15.21 Equality Operators
> ? * @jls 15.22 Bitwise and Logical Operators
> - * @jls 15.23 Conditional-And Operator &&
> - * @jls 15.24 Conditional-Or Operator ||
> + * @jls 15.23 Conditional-And Operator {@code &&}
> + * @jls 15.24 Conditional-Or Operator {@code ||}
> ? *
> ? * @author Peter von der Ah&eacute;
> ? * @author Jonathan Gibbons
> --- 
> old/src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java 
> 2019-05-19 12:16:43.285761266 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/source/tree/ModifiersTree.java 
> 2019-05-19 12:16:42.797761266 -0700
> @@ -45,7 +45,7 @@
> ? * @jls 8.5.1 Static Member Type Declarations
> ? * @jls 8.8.3 Constructor Modifiers
> ? * @jls 9.1.1 Interface Modifiers
> - * @jls 9.7?? Annotations
> + * @jls 9.7 Annotations
> ? *
> ? * @author Peter von der Ah&eacute;
> ? * @author Jonathan Gibbons
> --- 
> old/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java 
> 2019-05-19 12:16:44.213761266 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java 
> 2019-05-19 12:16:43.721761266 -0700
> @@ -2733,7 +2733,7 @@
> ????? * signature</em> of the other.? This is <b>not</b> an equivalence
> ????? * relation.
> ????? *
> -???? * @jls section 8.4.2.
> +???? * @jls 8.4.2 Method Signature
> ????? * @see #overrideEquivalent(Type t, Type s)
> ????? * @param t first signature (possibly raw).
> ????? * @param s second signature (could be subjected to erasure).
> @@ -2752,7 +2752,7 @@
> ????? * equivalence</em>.? This is the natural extension of
> ????? * isSubSignature to an equivalence relation.
> ????? *
> -???? * @jls section 8.4.2.
> +???? * @jls 8.4.2 Method Signature
> ????? * @see #isSubSignature(Type t, Type s)
> ????? * @param t a signature (possible raw, could be subjected to
> ????? * erasure).
> @@ -4214,7 +4214,7 @@
>
> ???? /**
> ????? * Return-Type-Substitutable.
> -???? * @jls section 8.4.5
> +???? * @jls 8.4.5 Method Result
> ????? */
> ???? public boolean returnTypeSubstitutable(Type r1, Type r2) {
> ???????? if (hasSameArgs(r1, r2))
> --- 
> old/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java 
> 2019-05-19 12:16:45.077761266 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java 
> 2019-05-19 12:16:44.657761266 -0700
> @@ -4222,7 +4222,7 @@
> ????????? * @param tree??? The tree making up the variable reference.
> ????????? * @param env???? The current environment.
> ????????? * @param v?????? The variable's symbol.
> -???????? * @jls? section 8.9 Enums
> +???????? * @jls 8.9 Enum Types
> ????????? */
> ???????? private void checkEnumInitializer(JCTree tree, 
> Env<AttrContext> env, VarSymbol v) {
> ???????????? // JLS:
> --- old/src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java 
> 2019-05-19 12:16:45.941761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java 
> 2019-05-19 12:16:45.505761266 -0700
> @@ -36,7 +36,7 @@
> ? * and thus is thread-safe.
> ? *
> ? * @since 9
> - * @jls 15: Expression.
> + * @jls 15 Expressions
> ? */
> ?public class ExpressionSnippet extends Snippet {
>
> --- old/src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java 
> 2019-05-19 12:16:47.045761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java 
> 2019-05-19 12:16:46.629761266 -0700
> @@ -36,7 +36,7 @@
> ? * and thus is thread-safe.
> ? *
> ? * @since 9
> - * @jls 8.3: importDeclaration.
> + * @jls 7.5 Import Declarations
> ? */
> ?public class ImportSnippet extends PersistentSnippet {
>
> --- old/src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java 
> 2019-05-19 12:16:48.501761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java 
> 2019-05-19 12:16:48.093761266 -0700
> @@ -37,7 +37,7 @@
> ? * and thus is thread-safe.
> ? *
> ? * @since 9
> - * @jls 8.4: MethodDeclaration.
> + * @jls 8.4 Method Declarations
> ? */
> ?public class MethodSnippet extends DeclarationSnippet {
>
> --- old/src/jdk.jshell/share/classes/jdk/jshell/Snippet.java 
> 2019-05-19 12:16:49.593761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/Snippet.java 
> 2019-05-19 12:16:49.173761266 -0700
> @@ -73,7 +73,7 @@
> ????????? * ({@link 
> jdk.jshell.Snippet.SubKind#SINGLE_STATIC_IMPORT_SUBKIND}) --
> ????????? * use {@link jdk.jshell.Snippet#subKind()} to distinguish.
> ????????? *
> -???????? * @jls 8.3: importDeclaration.
> +???????? * @jls 7.5 Import Declarations
> ????????? * <P>
> ????????? * An import declaration is {@linkplain Kind#isPersistent() 
> persistent}.
> ????????? */
> @@ -91,7 +91,7 @@
> ????????? * annotation interfaces -- see {@link 
> jdk.jshell.Snippet.SubKind} to
> ????????? * differentiate.
> ????????? *
> -???????? * @jls 7.6: TypeDeclaration.
> +???????? * @jls 7.6 Top Level Type Declarations
> ????????? * <P>
> ????????? * A type declaration is {@linkplain Kind#isPersistent() 
> persistent}.
> ????????? */
> @@ -101,7 +101,7 @@
> ????????? * A method declaration.
> ????????? * The snippet is an instance of {@link 
> jdk.jshell.MethodSnippet}.
> ????????? *
> -???????? * @jls 8.4: MethodDeclaration.
> +???????? * @jls 8.4 Method Declarations
> ????????? * <P>
> ????????? * A method declaration is {@linkplain Kind#isPersistent() 
> persistent}.
> ????????? */
> @@ -116,7 +116,7 @@
> ????????? * variable representing an expression -- see
> ????????? * {@link jdk.jshell.Snippet.SubKind}to differentiate.
> ????????? *
> -???????? * @jls 8.3: FieldDeclaration.
> +???????? * @jls 8.3 Field Declarations
> ????????? * <P>
> ????????? * A variable declaration is {@linkplain Kind#isPersistent() 
> persistent}.
> ????????? */
> @@ -133,7 +133,7 @@
> ????????? * All other expression forms (operators, method calls, ...) 
> generate a
> ????????? * scratch variable and so are instead of the VAR Kind.
> ????????? *
> -???????? * @jls 15: Expression.
> +???????? * @jls 15 Expressions
> ????????? */
> ???????? EXPRESSION(false),
>
> @@ -141,7 +141,7 @@
> ????????? * A statement.
> ????????? * The snippet is an instance of {@link 
> jdk.jshell.StatementSnippet}.
> ????????? *
> -???????? * @jls 14.5: Statement.
> +???????? * @jls 14.5 Statements
> ????????? */
> ???????? STATEMENT(false),
>
> @@ -185,99 +185,97 @@
> ???????? /**
> ????????? * Single-Type-Import Declaration.
> ????????? * An import declaration of a single type.
> -???????? * @jls 7.5.1 SingleTypeImportDeclaration.
> +???????? * @jls 7.5.1 Single-Type-Import Declarations
> ????????? */
> ???????? SINGLE_TYPE_IMPORT_SUBKIND(Kind.IMPORT),
>
> ???????? /**
> ????????? * Type-Import-on-Demand Declaration.
> ????????? * A non-static "star" import.
> -???????? * @jls 7.5.2. TypeImportOnDemandDeclaration.
> +???????? * @jls 7.5.2 Type-Import-on-Demand Declarations
> ????????? */
> ???????? TYPE_IMPORT_ON_DEMAND_SUBKIND(Kind.IMPORT),
>
> ???????? /**
> ????????? * Single-Static-Import Declaration.
> ????????? * An import of a static member.
> -???????? * @jls 7.5.3 Single-Static-Import.
> +???????? * @jls 7.5.3 Single-Static-Import Declarations
> ????????? */
> ???????? SINGLE_STATIC_IMPORT_SUBKIND(Kind.IMPORT),
>
> ???????? /**
> ????????? * Static-Import-on-Demand Declaration.
> ????????? * A static "star" import of all static members of a named type.
> -???????? * @jls 7.5.4. Static-Import-on-Demand Static "star" import.
> +???????? * @jls 7.5.4 Static-Import-on-Demand Declarations
> ????????? */
> ???????? STATIC_IMPORT_ON_DEMAND_SUBKIND(Kind.IMPORT),
>
> ???????? /**
> ????????? * A class declaration.
> ????????? * A {@code SubKind} of {@link Kind#TYPE_DECL}.
> -???????? * @jls 8.1. NormalClassDeclaration.
> +???????? * @jls 8.1 Class Declarations
> ????????? */
> ???????? CLASS_SUBKIND(Kind.TYPE_DECL),
>
> ???????? /**
> ????????? * An interface declaration.
> ????????? * A {@code SubKind} of {@link Kind#TYPE_DECL}.
> -???????? * @jls 9.1. NormalInterfaceDeclaration.
> +???????? * @jls 9.1 Interface Declarations
> ????????? */
> ???????? INTERFACE_SUBKIND(Kind.TYPE_DECL),
>
> ???????? /**
> ????????? * An enum declaration.
> ????????? * A {@code SubKind} of {@link Kind#TYPE_DECL}.
> -???????? * @jls 8.9. EnumDeclaration.
> +???????? * @jls 8.9 Enum Types
> ????????? */
> ???????? ENUM_SUBKIND(Kind.TYPE_DECL),
>
> ???????? /**
> ????????? * An annotation interface declaration. A {@code SubKind} of
> ????????? * {@link Kind#TYPE_DECL}.
> -???????? * @jls 9.6. AnnotationTypeDeclaration.
> +???????? * @jls 9.6 Annotation Types
> ????????? */
> ???????? ANNOTATION_TYPE_SUBKIND(Kind.TYPE_DECL),
>
> ???????? /**
> ????????? * A method. The only {@code SubKind} for {@link Kind#METHOD}.
> -???????? * @jls 8.4. MethodDeclaration.
> +???????? * @jls 8.4 Method Declarations
> ????????? */
> ???????? METHOD_SUBKIND(Kind.METHOD),
>
> ???????? /**
> ????????? * A variable declaration without initializer.
> ????????? * A {@code SubKind} of {@link Kind#VAR}.
> -???????? * @jls 8.3. VariableDeclarator without VariableInitializer in
> -???????? * FieldDeclaration.
> +???????? * @jls 8.3 Field Declarations
> ????????? */
> ???????? VAR_DECLARATION_SUBKIND(Kind.VAR, true, true),
>
> ???????? /**
> ????????? * A variable declaration with an initializer expression. A
> ????????? * {@code SubKind} of {@link Kind#VAR}.
> -???????? * @jls 8.3. VariableDeclarator with VariableInitializer in
> -???????? * FieldDeclaration.
> +???????? * @jls 8.3 Field Declarations
> ????????? */
> ???????? VAR_DECLARATION_WITH_INITIALIZER_SUBKIND(Kind.VAR, true, true),
>
> ???????? /**
> ????????? * An expression whose value has been stored in a temporary 
> variable. A
> ????????? * {@code SubKind} of {@link Kind#VAR}.
> -???????? * @jls 15. Primary.
> +???????? * @jls 15 Expressions
> ????????? */
> ???????? TEMP_VAR_EXPRESSION_SUBKIND(Kind.VAR, true, true),
>
> ???????? /**
> ????????? * A simple variable reference expression. A {@code SubKind} of
> ????????? * {@link Kind#EXPRESSION}.
> -???????? * @jls 15.11. Field Access as 3.8. Identifier.
> +???????? * @jls 15.11 Field Access Expressions
> ????????? */
> ???????? VAR_VALUE_SUBKIND(Kind.EXPRESSION, true, true),
>
> ???????? /**
> ????????? * An assignment expression. A {@code SubKind} of
> ????????? * {@link Kind#EXPRESSION}.
> -???????? * @jls 15.26. Assignment.
> +???????? * @jls 15.26 Assignment Operators
> ????????? */
> ???????? ASSIGNMENT_SUBKIND(Kind.EXPRESSION, true, true),
>
> @@ -289,7 +287,7 @@
>
> ???????? /**
> ????????? * A statement. The only {@code SubKind} for {@link 
> Kind#STATEMENT}.
> -???????? * @jls 14.5. Statement.
> +???????? * @jls 14.5 Statements
> ????????? */
> ???????? STATEMENT_SUBKIND(Kind.STATEMENT, true, false),
>
> --- old/src/jdk.jshell/share/classes/jdk/jshell/StatementSnippet.java 
> 2019-05-19 12:16:50.421761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/StatementSnippet.java 
> 2019-05-19 12:16:49.985761266 -0700
> @@ -36,7 +36,7 @@
> ? * and thus is thread-safe.
> ? *
> ? * @since 9
> - * @jls 14.5: Statement.
> + * @jls 14.5 Statements
> ? */
> ?public class StatementSnippet extends Snippet {
>
> --- old/src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java 
> 2019-05-19 12:16:51.549761266 -0700
> +++ new/src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java 
> 2019-05-19 12:16:51.117761266 -0700
> @@ -39,7 +39,7 @@
> ? * and thus is thread-safe.
> ? *
> ? * @since 9
> - * @jls 8.3: FieldDeclaration.
> + * @jls 8.3 Field Declarations
> ? */
> ?public class VarSnippet extends DeclarationSnippet {
>
>

From alexey.semenyuk at oracle.com  Tue May 21 00:13:11 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 20 May 2019 20:13:11 -0400
Subject: RFR: JDK-8224222: Inno setup 6 broke jpackage
In-Reply-To: <d3ca0c29-9dd5-6adc-0137-69a588123fdb@oracle.com>
References: <00d2aaa2-db60-cd20-f7a0-77f988632718@oracle.com>
 <d3ca0c29-9dd5-6adc-0137-69a588123fdb@oracle.com>
Message-ID: <0f25991c-8521-ea51-7ca1-f969c14aae68@oracle.com>

Alexander,

I tried running other .exe from ISS install dir. They don't output 
anything meaningful.
File version for all .exe files in ISS install dir is "0.0.0.0".
Running isscc.exe without arguments doesn't output version number.
Running isscc.exe with the empty project file was the only option that I 
found working.

- Alexey

On 5/20/2019 6:07 PM, Alexander Matveev wrote:
> Hi Alexey,
>
> Is there better way to figure out InnoSetup version? Creating empty 
> project file seems complicated.
> If there no such way, then fix looks fine.
>
> Thanks,
> Alexander
>
> On 5/20/2019 8:27 AM, Alexey Semenyuk wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox
>> repository (jpackage).
>>
>> - Improve code detecting version of Inno Setup to make it work with 
>> Inno Setup v6 updates.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8224222
>>
>> [2] http://cr.openjdk.java.net/~asemenyuk/8224222/webrev.00/
>>
>> Thanks,
>> Alexey
>


From naoto.sato at oracle.com  Tue May 21 00:20:19 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 20 May 2019 17:20:19 -0700
Subject: [13] RFR: 8224105: Cannot parse JapaneseDate string on some
 specified locales
In-Reply-To: <fc0763f3-6ce0-0a49-6b47-e3e7c2aba060@oracle.com>
References: <fc0763f3-6ce0-0a49-6b47-e3e7c2aba060@oracle.com>
Message-ID: <a5368a62-7314-9a43-005b-78c2c7a89b6f@oracle.com>

Ping?

Naoto

On 5/17/19 3:43 PM, naoto.sato at oracle.com wrote:
> Hi,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8224105
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8224105/webrev.00/
> 
> CLDR does not provide entire localized Japanese era names in locales 
> mentioned in the bug report. The parsing has been failing as they have 
> duplicate names, despite the duplicates are empty strings.
> 
> Naoto

From huizhe.wang at oracle.com  Tue May 21 00:25:08 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 20 May 2019 17:25:08 -0700
Subject: RFR (jdk13/java.xml) 8219692: DOM and SAX parser ignore namespace
In-Reply-To: <B376D076-5489-4164-B0D6-15763B53B2C3@oracle.com>
References: <5CE33305.6040505@oracle.com>
 <B376D076-5489-4164-B0D6-15763B53B2C3@oracle.com>
Message-ID: <5CE34564.1060603@oracle.com>

Thanks Lance!  Yikes, forgot the copyright header. The factory files are 
updated to 2019 now. The test file was okay as it was changed recently.

http://cr.openjdk.java.net/~joehw/jdk13/8219692/webrev/ 
<http://cr.openjdk.java.net/%7Ejoehw/jdk13/8219692/webrev/>

Best,
Joe

On 5/20/19, 4:09 PM, Lance Andersen wrote:
> Hi Joe,
>
> As we discussed off-line, these changes look  OK.  Please double check 
> that the copyright is updated in the relevant files.
>
> Best
> Lance
>> On May 20, 2019, at 7:06 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> Please review an enhancement to the DOM and SAX factories. By 
>> default, DOM/SAX factories created using the existing newInstance 
>> methods do not support XML Namespace. Parsers instantiated with such 
>> factories would therefore ignore namespaces. Users not realizing or 
>> unaware of the legacy setting may run into the issue as demonstrated 
>> in the bug description.
>>
>> This patch addresses the issue by introducing new methods that must 
>> set NamespaceAware to true. Factories instantiated using these 
>> methods can therefore create parsers that support XML Namespace by 
>> default.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219692
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk13/8219692/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk13/8219692/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 claes.redestad at oracle.com  Tue May 21 08:58:48 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 21 May 2019 10:58:48 +0200
Subject: RFR: 8224240: Properties.load fails to throw IAE on malformed unicode
 in certain circumstances
Message-ID: <7f55af15-c629-c2b6-c436-87de3a0eb586@oracle.com>

Hi,

found a bug in Properties.load that apparently has been around since
Java 5. This patch adds proper bounds checking when decoding unicode
sequences.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8224240
Webrev: http://cr.openjdk.java.net/~redestad/8224240/open.00

Since the fix means a behavior change in the error handling of certain
malformed property files, a CSR has been filed.

Thanks!

/Claes

From claes.redestad at oracle.com  Tue May 21 10:22:32 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 21 May 2019 12:22:32 +0200
Subject: RFR: 8224202: Speed up Properties.load
Message-ID: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>

Hi,

a few smaller optimizations for Properties.load:

- when parsing comment lines, we unnecessarily breaks the fast path loop
on backslashes, even though a backslash embedded in a comment line will 
never have any effect on subsequent logical lines

- inside that same loop, we always do two comparisons in the common 
case: testing c <= '\r' && c >= '\n' would mean only one comparison in 
the common case, since c is very likely to be > '\r' (also when reading 
from a byte stream)

- we currently store everything into temporary char[]'s which we then
instantiate Strings with. Since Compact String this means we often
use more temporary storage than necessary, and do unnecessary work
packing from char[] to byte[] representation internally; by using
StringBuilder encoding transitions is handled more gracefully and is a
speed-up in general (both interpreted and compiled) while simplifying
the code somewhat.

Result is ~5-20% faster depending on how comment-heavy the properties
file we're loading is.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8224202
Webrev: http://cr.openjdk.java.net/~redestad/8224202/open.00/

Testing: tier1-3

Patch is applied on top of JDK-8224240, patch for which is out for
review here: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060301.html

Thanks!

/Claes

From daniel.fuchs at oracle.com  Tue May 21 10:48:41 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 21 May 2019 11:48:41 +0100
Subject: RFR: 8224240: Properties.load fails to throw IAE on malformed
 unicode in certain circumstances
In-Reply-To: <7f55af15-c629-c2b6-c436-87de3a0eb586@oracle.com>
References: <7f55af15-c629-c2b6-c436-87de3a0eb586@oracle.com>
Message-ID: <2353bc6a-7dd3-0a4f-f10e-64749a2dc053@oracle.com>

Hi Claes,

Looks good to me. But can you add a test for when
the malformed sequence is not at the end of a line,
and one for when it's not the first character in the
value?

Something like:

         checkMalformedUnicodeEscape("b=\\u012xyz\n");
         checkMalformedUnicodeEscape("b=x\\u012yz\n");
         checkMalformedUnicodeEscape("b=xyz\\u012\n");

best regards,

-- daniel


On 21/05/2019 09:58, Claes Redestad wrote:
> Hi,
> 
> found a bug in Properties.load that apparently has been around since
> Java 5. This patch adds proper bounds checking when decoding unicode
> sequences.
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8224240
> Webrev: http://cr.openjdk.java.net/~redestad/8224240/open.00
> 
> Since the fix means a behavior change in the error handling of certain
> malformed property files, a CSR has been filed.
> 
> Thanks!
> 
> /Claes


From claes.redestad at oracle.com  Tue May 21 13:12:42 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 21 May 2019 15:12:42 +0200
Subject: RFR: 8224240: Properties.load fails to throw IAE on malformed
 unicode in certain circumstances
In-Reply-To: <2353bc6a-7dd3-0a4f-f10e-64749a2dc053@oracle.com>
References: <7f55af15-c629-c2b6-c436-87de3a0eb586@oracle.com>
 <2353bc6a-7dd3-0a4f-f10e-64749a2dc053@oracle.com>
Message-ID: <4e41f613-18e4-1016-d796-fa0f85841aaf@oracle.com>

Hi Daniel,

On 2019-05-21 12:48, Daniel Fuchs wrote:
> Hi Claes,
> 
> Looks good to me. 

Thanks!

> But can you add a test for when
> the malformed sequence is not at the end of a line,
> and one for when it's not the first character in the
> value?
> 
> Something like:
> 
>  ??????? checkMalformedUnicodeEscape("b=\\u012xyz\n");
>  ??????? checkMalformedUnicodeEscape("b=x\\u012yz\n");
>  ??????? checkMalformedUnicodeEscape("b=xyz\\u012\n");

seems reasonable, updated in-place.

/Claes

From Roger.Riggs at oracle.com  Tue May 21 14:27:34 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 21 May 2019 10:27:34 -0400
Subject: RFR: 8224240: Properties.load fails to throw IAE on malformed
 unicode in certain circumstances
In-Reply-To: <4e41f613-18e4-1016-d796-fa0f85841aaf@oracle.com>
References: <7f55af15-c629-c2b6-c436-87de3a0eb586@oracle.com>
 <2353bc6a-7dd3-0a4f-f10e-64749a2dc053@oracle.com>
 <4e41f613-18e4-1016-d796-fa0f85841aaf@oracle.com>
Message-ID: <0ed40adb-f668-b028-7db4-ca5de672caac@oracle.com>

Looks good.

Roger

On 05/21/2019 09:12 AM, Claes Redestad wrote:
> Hi Daniel,
>
> On 2019-05-21 12:48, Daniel Fuchs wrote:
>> Hi Claes,
>>
>> Looks good to me. 
>
> Thanks!
>
>> But can you add a test for when
>> the malformed sequence is not at the end of a line,
>> and one for when it's not the first character in the
>> value?
>>
>> Something like:
>>
>> ???????? checkMalformedUnicodeEscape("b=\\u012xyz\n");
>> ???????? checkMalformedUnicodeEscape("b=x\\u012yz\n");
>> ???????? checkMalformedUnicodeEscape("b=xyz\\u012\n");
>
> seems reasonable, updated in-place.
>
> /Claes


From james.laskey at oracle.com  Tue May 21 14:32:47 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 11:32:47 -0300
Subject: RFR - JDK-8203444 String::formatted (Preview)
Message-ID: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com>

Please do a code review of the new String::formatted instance method. This method was originally introduced under the name "format" in conjunction with Raw String Literals. The method is being reintroduced in conjunction with Text Blocks and renamed to avoid method resolution conflicts against the static method String::format.

Example of use:

    String name = "Smith, Pat";
    String address = "123 Maple St., Anytown, Anywhere";
    String phone = "999-555-1234";
    String client = """
                    Name: %s
		    Address: %s
		    Phone: %s
                    """.formatted(name, address, phone); 

Thank you.

-- Jim

webrev: http://cr.openjdk.java.net/~jlaskey/8203444/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8203444/webrev-01>
jbs: https://bugs.openjdk.java.net/browse/JDK-8203444 <https://bugs.openjdk.java.net/browse/JDK-8203444>
csr: https://bugs.openjdk.java.net/browse/JDK-8203630 <https://bugs.openjdk.java.net/browse/JDK-8203630>



From fweimer at redhat.com  Tue May 21 14:42:57 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 21 May 2019 16:42:57 +0200
Subject: RFR - JDK-8203444 String::formatted (Preview)
In-Reply-To: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com> (Jim Laskey's
 message of "Tue, 21 May 2019 11:32:47 -0300")
References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com>
Message-ID: <8736l798cu.fsf@oldenburg2.str.redhat.com>

* Jim Laskey:

> Please do a code review of the new String::formatted instance method. This method was originally introduced under the name "format"
> in conjunction with Raw String Literals. The method is being reintroduced in conjunction with Text Blocks and renamed to avoid method
> resolution conflicts against the static method String::format.
>
> Example of use:
>
>     String name = "Smith, Pat";
>     String address = "123 Maple St., Anytown, Anywhere";
>     String phone = "999-555-1234";
>     String client = """
>                     Name: %s
>     Address: %s
>     Phone: %s
>                     """.formatted(name, address, phone); 

I'm a bit concerned by the ambiguity between the version with and
without the Locale argument.  Not sure if this is the kind of feedback
you are looking for.

(String::format does not have this ambiguity and had been able to avoid
it easily, so it's not a good guide here.)

Thanks,
Florian

From james.laskey at oracle.com  Tue May 21 14:52:03 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 11:52:03 -0300
Subject: RFR - JDK-8203444 String::formatted (Preview)
In-Reply-To: <8736l798cu.fsf@oldenburg2.str.redhat.com>
References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com>
 <8736l798cu.fsf@oldenburg2.str.redhat.com>
Message-ID: <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com>

All discussion is valid. I agree the ambiguity is tricky, but can be resolved by using explicit locale.

Example:

	"%s".formatted(Locale.getDefault(), Locale.JAPAN);

This guarantees the "public String formatted(Locale l, Object... args)" form is chosen with the second Locale as an argument.

Cheers,

-- Jim






> On May 21, 2019, at 11:42 AM, Florian Weimer <fweimer at redhat.com> wrote:
> 
> * Jim Laskey:
> 
>> Please do a code review of the new String::formatted instance method. This method was originally introduced under the name "format"
>> in conjunction with Raw String Literals. The method is being reintroduced in conjunction with Text Blocks and renamed to avoid method
>> resolution conflicts against the static method String::format.
>> 
>> Example of use:
>> 
>>    String name = "Smith, Pat";
>>    String address = "123 Maple St., Anytown, Anywhere";
>>    String phone = "999-555-1234";
>>    String client = """
>>                    Name: %s
>>    Address: %s
>>    Phone: %s
>>                    """.formatted(name, address, phone); 
> 
> I'm a bit concerned by the ambiguity between the version with and
> without the Locale argument.  Not sure if this is the kind of feedback
> you are looking for.
> 
> (String::format does not have this ambiguity and had been able to avoid
> it easily, so it's not a good guide here.)
> 
> Thanks,
> Florian


From james.laskey at oracle.com  Tue May 21 14:56:45 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 11:56:45 -0300
Subject: RFR - JDK-8223780 String::translateEscapes (Preview)
Message-ID: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>

Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content.

Thank you.

-- Jim

webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01>
jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 <https://bugs.openjdk.java.net/browse/JDK-8223780>
csr: https://bugs.openjdk.java.net/browse/JDK-8223781 <https://bugs.openjdk.java.net/browse/JDK-8223781>
jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>


From james.laskey at oracle.com  Tue May 21 14:56:42 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 11:56:42 -0300
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
Message-ID: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>

Please do a code review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry.

Thank you.

-- Jim

webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01>
jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 <https://bugs.openjdk.java.net/browse/JDK-8223775>
csr: https://bugs.openjdk.java.net/browse/JDK-8223776 <https://bugs.openjdk.java.net/browse/JDK-8223776>
jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>



From christoph.langer at sap.com  Tue May 21 15:24:23 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 21 May 2019 15:24:23 +0000
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <fad24c8f-aa40-821e-fa15-9cbe32b0eb76@oracle.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <fd756aff51134b15a40fe55247d4a87e@sap.com>
 <CA+3eh13dP-tCdq4H4z3KWJZQzfMJYqDNkx9fMh3tNfL08RCtDg@mail.gmail.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <a3e64312-d902-b751-d55d-0af1c4c6e3c5@oracle.com>
 <953449f0913340f6a94ae3d83611fd92@sap.com>
 <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>
 <HE1PR0201MB2266326D98F5119796990BFC8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
 <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <fad24c8f-aa40-821e-fa15-9cbe32b0eb76@oracle.com>
Message-ID: <DB7PR02MB51937A87EECD7D1E01F71D098A070@DB7PR02MB5193.eurprd02.prod.outlook.com>

Hi Alan,

Thank you for your comments. Here comes the next update... increasing the turnaround time a little bit ??

http://cr.openjdk.java.net/~clanger/webrevs/8213031.10/


> Thanks. I think you've addressed most of my points. The only thing that
> isn't clear is the group owner as I thought we had converged on using
> the zip file's group owner.? If I read the code correctly then it uses
> the file owner (and makes the assumption that defaultOwner is
> initialized before initGroup is called).

Ok, makes sense. I've updated the coding such that the zip's file owner would be the default owner, in case it can be retrieved.

> In passing, the name of the PosixFileAttributeView implementation should
> probably be ZipPosixFileAttributeView rather than
> ZipFilePosixAttributeViewPosix. Also EntryPosix extends Entry, should
> probably be PosixEntry. Not important as these are internal but noticed
> them when scanning the changes.

I changed the class names, hopefully to your liking.

> Also in passing, there are several places using
> AccessController.doPrivileged that are bit ugly due to the casting. The
> doPrivileged methods are awkward to use with lambda expressions (not
> your doing) but one approach that I find readable is to separate the
> creation of the action, e.g. file the zip file owner it could be:
> 
> PrivilegedExceptionAction<UserPrincipal> pa = () -> Files.getOwner(zfpath);
> return AccessController.doPrivileged(pa).

I updated these places. Seems more readable indeed.

> In the same area, the code in initOwner catches UOE but that will always
> be wrapped in PAE.

Fixed.

> > I have updated module-info a little bit to reflect the latest changes. Is it
> now time to focus on the CSR?
> >
> The "For extended POSIX support ..." paragraph has the property name
> from a previous iteration so I assume you'll update that. I think it
> would be using to put quotes around the names too. It also specifies the
> fallback group owner to be the file owner but I think we converged on
> use the zip file's group owner where possible.
> 
> A small bit of word smiting required but I think this is really close to
> writing the CSR.

I have updated the doc in module-info.java quite a bit. Please check.

Is it time to work on the CSR now? How shall we proceed there?

Thanks
Christoph


From fweimer at redhat.com  Tue May 21 15:44:28 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 21 May 2019 17:44:28 +0200
Subject: RFR - JDK-8203444 String::formatted (Preview)
In-Reply-To: <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com> (Jim Laskey's
 message of "Tue, 21 May 2019 11:52:03 -0300")
References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com>
 <8736l798cu.fsf@oldenburg2.str.redhat.com>
 <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com>
Message-ID: <87h89n7qxv.fsf@oldenburg2.str.redhat.com>

* Jim Laskey:

> All discussion is valid. I agree the ambiguity is tricky, but can be
> resolved by using explicit locale.
>
> Example:
>
> 	"%s".formatted(Locale.getDefault(), Locale.JAPAN);
>
> This guarantees the "public String formatted(Locale l,
> Object... args)" form is chosen with the second Locale as an argument.

There is also the cognitive overhead.  I think the key question is
whether this is so bad:

  String.format(Locale.US, """
  %s
  """, Locale.JAPAN);

Then perhaps we wouldn't need the formatted method which takes a Locale
object.

Thanks,
Florian

From james.laskey at oracle.com  Tue May 21 15:56:11 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 12:56:11 -0300
Subject: RFR - JDK-8203444 String::formatted (Preview)
In-Reply-To: <87h89n7qxv.fsf@oldenburg2.str.redhat.com>
References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com>
 <8736l798cu.fsf@oldenburg2.str.redhat.com>
 <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com>
 <87h89n7qxv.fsf@oldenburg2.str.redhat.com>
Message-ID: <664BC60B-C09A-4F4F-8045-A70B1DF09401@oracle.com>

Good point. To make sure I fully understand what you are stating,

- The argument for having an instance method is reasonable to achieve "flowiness".
- However, only one version is necessary or desired, that is, "public String formatted(Object... args)".
- In cases where Locale needs to be overridden, then either use "String.format(Locale lc, String fmt, Object... args)" or globally set "Locale.setDefault(Locale lc)".

Correct?

-- Jim




> On May 21, 2019, at 12:44 PM, Florian Weimer <fweimer at redhat.com> wrote:
> 
> * Jim Laskey:
> 
>> All discussion is valid. I agree the ambiguity is tricky, but can be
>> resolved by using explicit locale.
>> 
>> Example:
>> 
>> 	"%s".formatted(Locale.getDefault(), Locale.JAPAN);
>> 
>> This guarantees the "public String formatted(Locale l,
>> Object... args)" form is chosen with the second Locale as an argument.
> 
> There is also the cognitive overhead.  I think the key question is
> whether this is so bad:
> 
>  String.format(Locale.US, """
>  %s
>  """, Locale.JAPAN);
> 
> Then perhaps we wouldn't need the formatted method which takes a Locale
> object.
> 
> Thanks,
> Florian


From james.laskey at oracle.com  Tue May 21 16:30:10 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 13:30:10 -0300
Subject: RFR - JDK-8203444 String::formatted (Preview)
In-Reply-To: <664BC60B-C09A-4F4F-8045-A70B1DF09401@oracle.com>
References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com>
 <8736l798cu.fsf@oldenburg2.str.redhat.com>
 <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com>
 <87h89n7qxv.fsf@oldenburg2.str.redhat.com>
 <664BC60B-C09A-4F4F-8045-A70B1DF09401@oracle.com>
Message-ID: <DE07B8B2-8D04-49DE-8166-98E92CAC5CE3@oracle.com>

I suppose String::formattedLocalized(Locale lc, Object... args) would also be reasonable.

> On May 21, 2019, at 12:56 PM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Good point. To make sure I fully understand what you are stating,
> 
> - The argument for having an instance method is reasonable to achieve "flowiness".
> - However, only one version is necessary or desired, that is, "public String formatted(Object... args)".
> - In cases where Locale needs to be overridden, then either use "String.format(Locale lc, String fmt, Object... args)" or globally set "Locale.setDefault(Locale lc)".
> 
> Correct?
> 
> -- Jim
> 
> 
> 
> 
>> On May 21, 2019, at 12:44 PM, Florian Weimer <fweimer at redhat.com> wrote:
>> 
>> * Jim Laskey:
>> 
>>> All discussion is valid. I agree the ambiguity is tricky, but can be
>>> resolved by using explicit locale.
>>> 
>>> Example:
>>> 
>>> 	"%s".formatted(Locale.getDefault(), Locale.JAPAN);
>>> 
>>> This guarantees the "public String formatted(Locale l,
>>> Object... args)" form is chosen with the second Locale as an argument.
>> 
>> There is also the cognitive overhead.  I think the key question is
>> whether this is so bad:
>> 
>> String.format(Locale.US, """
>> %s
>> """, Locale.JAPAN);
>> 
>> Then perhaps we wouldn't need the formatted method which takes a Locale
>> object.
>> 
>> Thanks,
>> Florian
> 


From daniel.fuchs at oracle.com  Tue May 21 16:40:45 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 21 May 2019 17:40:45 +0100
Subject: RFR: 8224240: Properties.load fails to throw IAE on malformed
 unicode in certain circumstances
In-Reply-To: <4e41f613-18e4-1016-d796-fa0f85841aaf@oracle.com>
References: <7f55af15-c629-c2b6-c436-87de3a0eb586@oracle.com>
 <2353bc6a-7dd3-0a4f-f10e-64749a2dc053@oracle.com>
 <4e41f613-18e4-1016-d796-fa0f85841aaf@oracle.com>
Message-ID: <5b3f2bd0-7f7d-b204-8c38-96a6a0d12917@oracle.com>

Thanks Claes!

Looks good.

best regards,

-- daniel

On 21/05/2019 14:12, Claes Redestad wrote:
> Hi Daniel,
> 
> On 2019-05-21 12:48, Daniel Fuchs wrote:
>> Hi Claes,
>>
>> Looks good to me. 
> 
> Thanks!
> 
>> But can you add a test for when
>> the malformed sequence is not at the end of a line,
>> and one for when it's not the first character in the
>> value?
>>
>> Something like:
>>
>> ???????? checkMalformedUnicodeEscape("b=\\u012xyz\n");
>> ???????? checkMalformedUnicodeEscape("b=x\\u012yz\n");
>> ???????? checkMalformedUnicodeEscape("b=xyz\\u012\n");
> 
> seems reasonable, updated in-place.
> 
> /Claes


From james.laskey at oracle.com  Tue May 21 17:34:04 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 14:34:04 -0300
Subject: RFR - JDK-8223780 String::translateEscapes (Preview)
In-Reply-To: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>
References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>
Message-ID: <7ED4E127-25C5-4E3C-A996-EE6324E5FA06@oracle.com>

Code has been updated to use IllegalArgumentException instead of new exception type.

http://cr.openjdk.java.net/~jlaskey/8223780/webrev-02

> On May 21, 2019, at 11:56 AM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content.
> 
> Thank you.
> 
> -- Jim
> 
> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 <https://bugs.openjdk.java.net/browse/JDK-8223780>
> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 <https://bugs.openjdk.java.net/browse/JDK-8223781>
> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>
> 


From ivan.gerasimov at oracle.com  Tue May 21 17:57:01 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 21 May 2019 10:57:01 -0700
Subject: RFR - JDK-8223780 String::translateEscapes (Preview)
In-Reply-To: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>
References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>
Message-ID: <abfcefd9-46f5-a49e-cf53-ed5930a04034@oracle.com>

Hi Jim!

A few comments:

1)
Probably, there's no need to update ch in these cases:
                 case '\'':
                     ch = '\'';
                     break;
                 case '\"':
                     ch = '\"';
                     break;

2)
Character.digit(ch, 8) will accept non-Latin1 digits.
So, a sequence \\3\uFF17\uFF17 will be parsed as \\377.
(Note, that the first digit still can only be from range '0'-'9').

3)
It's not obvious how this condition can be triggered:
                     if (0377 < code) {
                         throw new MalformedEscapeException(from);
                     }
I might be missing something, but I cannot see how 'code' can become > 0377.

4)
throw new MalformedEscapeException(from);
This will report the next index after the error.  Was it intentional?

With kind regards,
Ivan


On 5/21/19 7:56 AM, Jim Laskey wrote:
> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content.
>
> Thank you.
>
> -- Jim
>
> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 <https://bugs.openjdk.java.net/browse/JDK-8223780>
> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 <https://bugs.openjdk.java.net/browse/JDK-8223781>
> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>
>
>

-- 
With kind regards,
Ivan Gerasimov


From james.laskey at oracle.com  Tue May 21 17:59:47 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 14:59:47 -0300
Subject: Need code reviews for Text Block support
Message-ID: <AB4AF93B-951C-45EF-8C96-F2D58BCFDE0A@oracle.com>

Brent,

With Sherman gone, I don't have a Strings guy to review changes to java.lang.String. Would you be willing to take a look see? Nothing complicated.
RFR sent to core-libs-dev subjects


Subject: RFR - JDK-8223775 String::stripIndent (Preview)
Subject: RFR - JDK-8223780 String::translateEscapes (Preview)
Subject: RFR - JDK-8203444 String::formatted (Preview)


Thank you.

Cheers,

-- Jim


From brent.christian at oracle.com  Tue May 21 18:03:04 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 21 May 2019 11:03:04 -0700
Subject: [13] RFR: 8224105: Cannot parse JapaneseDate string on some
 specified locales
In-Reply-To: <a5368a62-7314-9a43-005b-78c2c7a89b6f@oracle.com>
References: <fc0763f3-6ce0-0a49-6b47-e3e7c2aba060@oracle.com>
 <a5368a62-7314-9a43-005b-78c2c7a89b6f@oracle.com>
Message-ID: <01e6d7f9-e7df-4458-518f-20d455b31263@oracle.com>

Hi, Naoto.  I have a couple comments.

src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java


String.isEmpty() could be used in place of equals("").


test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java


Maybe give the new constants names in all-caps.


-Brent

On 5/20/19 5:20 PM, naoto.sato at oracle.com wrote:
> Ping?
> 
> Naoto
> 
> On 5/17/19 3:43 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8224105
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8224105/webrev.00/
>>
>> CLDR does not provide entire localized Japanese era names in locales 
>> mentioned in the bug report. The parsing has been failing as they have 
>> duplicate names, despite the duplicates are empty strings.
>>
>> Naoto

From alex.buckley at oracle.com  Tue May 21 18:11:42 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 21 May 2019 11:11:42 -0700
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
Message-ID: <5CE43F5E.1050102@oracle.com>

On 5/21/2019 7:56 AM, Jim Laskey wrote:
> Please do a code review of the new String::stripIndent instance method.

My interest is in the API spec because the JLS will make normative 
reference to it.


"Removes horizontal white space margins from the essential body of a
Text Block originated string, while preserving relative indentation."

Lots of concepts here: margins, "essential body", a "Text Block 
originated string" (not just any string?). Looks like the removal 
happens in-place. While "essential" is a concept from the JEP, I think 
the sibling concept, "incidental", is the one to lead with. Alluding to 
multiple lines is also good. Recommend:

"Returns a string whose value is this string, with incidental white 
space removed from the beginning and end of every line."

That is, 'stripIndent' isn't quite as generic as its name suggests. It 
implements a particular policy about "incidental" white space that we 
will now explain...


New paragraph: "Incidental white space is often present in a text block 
to align the content with the opening delimiter. For example, in the 
following code, dots represent incidental white space:

String html = """
..............<html>
..............    <body>
..............        <p>Hello, world</p>
..............    </body>
..............</html>
..............""";


Another new para, to link this high-falutin' incidental concept to the 
workmanlike name of this method:  "This method treats the incidental 
white space as indentation to be stripped, producing a string that 
preserves the relative indentation of the content. Using | to visualize 
the start of each line of the string:

|<html>
|    <body>
|        <p>Hello, world</p>
|    </body>
|</html>


Now, the algo. "This string is first conceptually separated into lines 
as if by {@link String#lines()}." -- phrasing: "First, this string is 
conceptually ..."


"Then, the <i>minimum indentation</i> (min) is determined as follows. 
For each non-blank line (as defined by {@link String#isBlank()}), the
leading {@link Character#isWhitespace(int) white space} characters are
counted. The leading {@link Character#isWhitespace(int) white space} 
characters on the last line are are also counted even if blank.
The <i>min</i> value is the smallest of these counts."

No more "common white space prefix" like in the JEP? OK, fair enough, 
we're now fully rotated to "indentation" rather than "white space".


"For each non-blank line, <i>min</i> leading white space characters are
removed. Each white space character is treated as a single character. In
particular, the tab character {@code "\t"} (U+0009) is considered a
single character; it is not expanded.

The trailing white space of each line is also removed."

The trailing white space characters are just as "treated as a single 
character" as the leading white space characters. Recommend:  "For each 
non-blank line, <i>min</i> leading white space characters are removed, 
and any trailing white space characters are removed."


Recommend handling escape sequences in a separate para. Showing "\t", a 
two character sequence, and then alluding to \u0009, a single character, 
is confusing.


"Each line is suffixed with a line feed character {@code "\n"} (U+000A),
except for the last line. The last line is suffixed with a line feed
character {@code "\n"} (U+000A) only if the original last line was blank."

The phrasing "except for the last line" is odd because it suggests the 
last line never gets a suffix. Except, oh, it might. And "suffixed" is 
an unusual word. If you're going to allude to the original string's last 
line, then isn't there a way to lean on it more? e.g. "A line feed 
character is appended to every line if the corresponding line in the 
original string was terminated with a line feed character."  (Not saying 
that is correct or desirable, but is easier to visualize.)


"Finally, the lines are concatenated into a single string and returned."

Recommend: "Finally, the lines are concatenated into a string, which is 
the result."

Alex

From james.laskey at oracle.com  Tue May 21 18:23:06 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 15:23:06 -0300
Subject: RFR - JDK-8223780 String::translateEscapes (Preview)
In-Reply-To: <abfcefd9-46f5-a49e-cf53-ed5930a04034@oracle.com>
References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>
 <abfcefd9-46f5-a49e-cf53-ed5930a04034@oracle.com>
Message-ID: <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com>



> On May 21, 2019, at 2:57 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> Hi Jim!
> 
> A few comments:
> 
> 1)
> Probably, there's no need to update ch in these cases:
>                case '\'':
>                    ch = '\'';
>                    break;
>                case '\"':
>                    ch = '\"';
>                    break;

True

> 
> 2)
> Character.digit(ch, 8) will accept non-Latin1 digits.
> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377.
> (Note, that the first digit still can only be from range '0'-'9').

Also true. Subtlety in UnicodeReader.

> 
> 3)
> It's not obvious how this condition can be triggered:
>                    if (0377 < code) {
>                        throw new MalformedEscapeException(from);
>                    }
> I might be missing something, but I cannot see how 'code' can become > 0377.

I removed this check in round 2.

> 
> 4)
> throw new MalformedEscapeException(from);
> This will report the next index after the error.  Was it intentional?
> 

I switched to using an IllegalArgumentError and displaying the actual character.


> With kind regards,
> Ivan

Much thanks.


> 
> 
> On 5/21/19 7:56 AM, Jim Laskey wrote:
>> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content.
>> 
>> Thank you.
>> 
>> -- Jim
>> 
>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01>
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 <https://bugs.openjdk.java.net/browse/JDK-8223780>
>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 <https://bugs.openjdk.java.net/browse/JDK-8223781>
>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>
>> 
>> 
> 
> -- 
> With kind regards,
> Ivan Gerasimov
> 


From vicente.romero at oracle.com  Tue May 21 18:27:21 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 21 May 2019 14:27:21 -0400
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
Message-ID: <a1b52a84-2d67-f69f-65cb-72e32901060f@oracle.com>

Hi Jim,

Some minor comments:

- the javadoc for String::stripIndent needs some formating. There is a 
solitary "counted. The"
- at method String::stripIndent, you can bail out and do nothing if 
outdent==0
- suggestion: method String::outdent could return a Map<Integer, 
Integer> to indicate the first index of a non-whitespace per line. I 
concede that you probably won't be able to use a lambda at the end but 
you will avoid invoking String::indexOfNonWhitespace per line again at 
String::stripIndent

Thanks,
Vicente

On 5/21/19 10:56 AM, Jim Laskey wrote:
> Please do a code review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry.
>
> Thank you.
>
> -- Jim
>
> webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 <https://bugs.openjdk.java.net/browse/JDK-8223775>
> csr: https://bugs.openjdk.java.net/browse/JDK-8223776 <https://bugs.openjdk.java.net/browse/JDK-8223776>
> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>
>
>


From james.laskey at oracle.com  Tue May 21 18:30:58 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 15:30:58 -0300
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <5CE43F5E.1050102@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
 <5CE43F5E.1050102@oracle.com>
Message-ID: <2AF761BB-8323-46AA-8392-55E80A7E15DD@oracle.com>

Thank you. I haven't really put the API out for CSR review as yet. This is current state remnant from Stuart's Raw String Literals CSR review. He and I hope to reform this very soon. Your comments will provide a good starting point.

Cheers,

-- Jim


> On May 21, 2019, at 3:11 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 5/21/2019 7:56 AM, Jim Laskey wrote:
>> Please do a code review of the new String::stripIndent instance method.
> 
> My interest is in the API spec because the JLS will make normative reference to it.
> 
> 
> "Removes horizontal white space margins from the essential body of a
> Text Block originated string, while preserving relative indentation."
> 
> Lots of concepts here: margins, "essential body", a "Text Block originated string" (not just any string?). Looks like the removal happens in-place. While "essential" is a concept from the JEP, I think the sibling concept, "incidental", is the one to lead with. Alluding to multiple lines is also good. Recommend:
> 
> "Returns a string whose value is this string, with incidental white space removed from the beginning and end of every line."
> 
> That is, 'stripIndent' isn't quite as generic as its name suggests. It implements a particular policy about "incidental" white space that we will now explain...
> 
> 
> New paragraph: "Incidental white space is often present in a text block to align the content with the opening delimiter. For example, in the following code, dots represent incidental white space:
> 
> String html = """
> ..............<html>
> ..............    <body>
> ..............        <p>Hello, world</p>
> ..............    </body>
> ..............</html>
> ..............""";
> 
> 
> Another new para, to link this high-falutin' incidental concept to the workmanlike name of this method:  "This method treats the incidental white space as indentation to be stripped, producing a string that preserves the relative indentation of the content. Using | to visualize the start of each line of the string:
> 
> |<html>
> |    <body>
> |        <p>Hello, world</p>
> |    </body>
> |</html>
> 
> 
> Now, the algo. "This string is first conceptually separated into lines as if by {@link String#lines()}." -- phrasing: "First, this string is conceptually ..."
> 
> 
> "Then, the <i>minimum indentation</i> (min) is determined as follows. For each non-blank line (as defined by {@link String#isBlank()}), the
> leading {@link Character#isWhitespace(int) white space} characters are
> counted. The leading {@link Character#isWhitespace(int) white space} characters on the last line are are also counted even if blank.
> The <i>min</i> value is the smallest of these counts."
> 
> No more "common white space prefix" like in the JEP? OK, fair enough, we're now fully rotated to "indentation" rather than "white space".
> 
> 
> "For each non-blank line, <i>min</i> leading white space characters are
> removed. Each white space character is treated as a single character. In
> particular, the tab character {@code "\t"} (U+0009) is considered a
> single character; it is not expanded.
> 
> The trailing white space of each line is also removed."
> 
> The trailing white space characters are just as "treated as a single character" as the leading white space characters. Recommend:  "For each non-blank line, <i>min</i> leading white space characters are removed, and any trailing white space characters are removed."
> 
> 
> Recommend handling escape sequences in a separate para. Showing "\t", a two character sequence, and then alluding to \u0009, a single character, is confusing.
> 
> 
> "Each line is suffixed with a line feed character {@code "\n"} (U+000A),
> except for the last line. The last line is suffixed with a line feed
> character {@code "\n"} (U+000A) only if the original last line was blank."
> 
> The phrasing "except for the last line" is odd because it suggests the last line never gets a suffix. Except, oh, it might. And "suffixed" is an unusual word. If you're going to allude to the original string's last line, then isn't there a way to lean on it more? e.g. "A line feed character is appended to every line if the corresponding line in the original string was terminated with a line feed character."  (Not saying that is correct or desirable, but is easier to visualize.)
> 
> 
> "Finally, the lines are concatenated into a single string and returned."
> 
> Recommend: "Finally, the lines are concatenated into a string, which is the result."
> 
> Alex


From naoto.sato at oracle.com  Tue May 21 18:33:20 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 21 May 2019 11:33:20 -0700
Subject: [13] RFR: 8224105: Cannot parse JapaneseDate string on some
 specified locales
In-Reply-To: <01e6d7f9-e7df-4458-518f-20d455b31263@oracle.com>
References: <fc0763f3-6ce0-0a49-6b47-e3e7c2aba060@oracle.com>
 <a5368a62-7314-9a43-005b-78c2c7a89b6f@oracle.com>
 <01e6d7f9-e7df-4458-518f-20d455b31263@oracle.com>
Message-ID: <36c05c5c-e08a-bd65-1b1e-daa8400d106c@oracle.com>

Thanks, Brent. Modified the webrev accordingly:

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

Naoto

On 5/21/19 11:03 AM, Brent Christian wrote:
> Hi, Naoto.? I have a couple comments.
> 
> src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java 
> 
> 
> 
> String.isEmpty() could be used in place of equals("").
> 
> 
> test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java
> 
> 
> Maybe give the new constants names in all-caps.
> 
> 
> -Brent
> 
> On 5/20/19 5:20 PM, naoto.sato at oracle.com wrote:
>> Ping?
>>
>> Naoto
>>
>> On 5/17/19 3:43 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8224105
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8224105/webrev.00/
>>>
>>> CLDR does not provide entire localized Japanese era names in locales 
>>> mentioned in the bug report. The parsing has been failing as they 
>>> have duplicate names, despite the duplicates are empty strings.
>>>
>>> Naoto

From james.laskey at oracle.com  Tue May 21 18:37:48 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 15:37:48 -0300
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <a1b52a84-2d67-f69f-65cb-72e32901060f@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
 <a1b52a84-2d67-f69f-65cb-72e32901060f@oracle.com>
Message-ID: <FF5F81A2-D3DC-41BE-829E-13B0CDFE1A5A@oracle.com>



> On May 21, 2019, at 3:27 PM, Vicente Romero <vicente.romero at oracle.com> wrote:
> 
> Hi Jim,
> 
> Some minor comments:
> 
> - the javadoc for String::stripIndent needs some formating. There is a solitary "counted. The"

Looking for a code review at this point. Will get to API soon.

> - at method String::stripIndent, you can bail out and do nothing if outdent==0

Not really, we still need to stripTrailing, but I could optimize that case.

> - suggestion: method String::outdent could return a Map<Integer, Integer> to indicate the first index of a non-whitespace per line. I concede that you probably won't be able to use a lambda at the end but you will avoid invoking String::indexOfNonWhitespace per line again at String::stripIndent

Considered  using an int array but it's a time vs memory situation. Cost of managing the map would outweigh the cost of recomputation. The scan is pretty quick.

> 
> Thanks,
> Vicente

Thank you.


> 
> On 5/21/19 10:56 AM, Jim Laskey wrote:
>> Please do a code review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry.
>> 
>> Thank you.
>> 
>> -- Jim
>> 
>> webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01>
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 <https://bugs.openjdk.java.net/browse/JDK-8223775>
>> csr: https://bugs.openjdk.java.net/browse/JDK-8223776 <https://bugs.openjdk.java.net/browse/JDK-8223776>
>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>
>> 
>> 
> 


From james.laskey at oracle.com  Tue May 21 19:24:36 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 16:24:36 -0300
Subject: RFR - JDK-8223780 String::translateEscapes (Preview)
In-Reply-To: <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com>
References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>
 <abfcefd9-46f5-a49e-cf53-ed5930a04034@oracle.com>
 <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com>
Message-ID: <FFE10AB9-B2FB-402A-B24E-62D7E6B3C2FF@oracle.com>

Revised at http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html>



> On May 21, 2019, at 3:23 PM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> 
> 
>> On May 21, 2019, at 2:57 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>> 
>> Hi Jim!
>> 
>> A few comments:
>> 
>> 1)
>> Probably, there's no need to update ch in these cases:
>>               case '\'':
>>                   ch = '\'';
>>                   break;
>>               case '\"':
>>                   ch = '\"';
>>                   break;
> 
> True
> 
>> 
>> 2)
>> Character.digit(ch, 8) will accept non-Latin1 digits.
>> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377.
>> (Note, that the first digit still can only be from range '0'-'9').
> 
> Also true. Subtlety in UnicodeReader.
> 
>> 
>> 3)
>> It's not obvious how this condition can be triggered:
>>                   if (0377 < code) {
>>                       throw new MalformedEscapeException(from);
>>                   }
>> I might be missing something, but I cannot see how 'code' can become > 0377.
> 
> I removed this check in round 2.
> 
>> 
>> 4)
>> throw new MalformedEscapeException(from);
>> This will report the next index after the error.  Was it intentional?
>> 
> 
> I switched to using an IllegalArgumentError and displaying the actual character.
> 
> 
>> With kind regards,
>> Ivan
> 
> Much thanks.
> 
> 
>> 
>> 
>> On 5/21/19 7:56 AM, Jim Laskey wrote:
>>> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content.
>>> 
>>> Thank you.
>>> 
>>> -- Jim
>>> 
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01>
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 <https://bugs.openjdk.java.net/browse/JDK-8223780>
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 <https://bugs.openjdk.java.net/browse/JDK-8223781>
>>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>
>>> 
>>> 
>> 
>> -- 
>> With kind regards,
>> Ivan Gerasimov
>> 
> 


From vicente.romero at oracle.com  Tue May 21 19:41:22 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 21 May 2019 15:41:22 -0400
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <FF5F81A2-D3DC-41BE-829E-13B0CDFE1A5A@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
 <a1b52a84-2d67-f69f-65cb-72e32901060f@oracle.com>
 <FF5F81A2-D3DC-41BE-829E-13B0CDFE1A5A@oracle.com>
Message-ID: <65795019-4e7a-8d72-958c-196b35e36cf1@oracle.com>

Hi,

On 5/21/19 2:37 PM, Jim Laskey wrote:
>
>> On May 21, 2019, at 3:27 PM, Vicente Romero <vicente.romero at oracle.com> wrote:
>>
>> Hi Jim,
>>
>> Some minor comments:
>>
>> - the javadoc for String::stripIndent needs some formating. There is a solitary "counted. The"
> Looking for a code review at this point. Will get to API soon.
>
>> - at method String::stripIndent, you can bail out and do nothing if outdent==0
> Not really, we still need to stripTrailing, but I could optimize that case.

rigth

>
>> - suggestion: method String::outdent could return a Map<Integer, Integer> to indicate the first index of a non-whitespace per line. I concede that you probably won't be able to use a lambda at the end but you will avoid invoking String::indexOfNonWhitespace per line again at String::stripIndent
> Considered  using an int array but it's a time vs memory situation. Cost of managing the map would outweigh the cost of recomputation. The scan is pretty quick.

ok, no more comments,

Vicente

>
>> Thanks,
>> Vicente
> Thank you.
>
>
>> On 5/21/19 10:56 AM, Jim Laskey wrote:
>>> Please do a code review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry.
>>>
>>> Thank you.
>>>
>>> -- Jim
>>>
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01>
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 <https://bugs.openjdk.java.net/browse/JDK-8223775>
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8223776 <https://bugs.openjdk.java.net/browse/JDK-8223776>
>>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>
>>>
>>>


From dmitry.chuyko at bell-sw.com  Tue May 21 20:24:33 2019
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Tue, 21 May 2019 23:24:33 +0300
Subject: RFR(XS): 8220072: GCC 8.3 reports errors in java.base
Message-ID: <62C11EC0-AE63-47F1-9379-38F2E133E385@bell-sw.com>

Hello,

Please review a small fix for compilation error reported by recent compiler in canonicalize() from canonicalize_md.c. PATH_MAX may be passed as num argument to strncpy() and ?\0? is added to resulting string. The case of too long name is processed at the beginning of canonicalize() so duplicate check is removed.

bug: https://bugs.openjdk.java.net/browse/JDK-8220072 <https://bugs.openjdk.java.net/browse/JDK-8220072>
webrev: http://cr.openjdk.java.net/~dchuyko/8220072/webrev.01/ <http://cr.openjdk.java.net/~dchuyko/8220072/webrev.01/>
testing: dev-submit mach5-one-dchuyko-JDK-8220072-1-20190521-1536-2605973: PASSED

-Dmitry

From brent.christian at oracle.com  Tue May 21 20:36:41 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 21 May 2019 13:36:41 -0700
Subject: [13] RFR: 8224105: Cannot parse JapaneseDate string on some
 specified locales
In-Reply-To: <36c05c5c-e08a-bd65-1b1e-daa8400d106c@oracle.com>
References: <fc0763f3-6ce0-0a49-6b47-e3e7c2aba060@oracle.com>
 <a5368a62-7314-9a43-005b-78c2c7a89b6f@oracle.com>
 <01e6d7f9-e7df-4458-518f-20d455b31263@oracle.com>
 <36c05c5c-e08a-bd65-1b1e-daa8400d106c@oracle.com>
Message-ID: <db68107b-d67c-9418-3ccf-169e6974caf4@oracle.com>

Thanks.  Looks good to me.
-Brent

On 5/21/19 11:33 AM, naoto.sato at oracle.com wrote:
> Thanks, Brent. Modified the webrev accordingly:
> 
> http://cr.openjdk.java.net/~naoto/8224105/webrev.01/
> 
> Naoto
> 
> On 5/21/19 11:03 AM, Brent Christian wrote:
>> Hi, Naoto.? I have a couple comments.
>>
>> src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java 
>>
>>
>>
>> String.isEmpty() could be used in place of equals("").
>>
>>
>> test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java
>>
>>
>> Maybe give the new constants names in all-caps.
>>
>>
>> -Brent
>>
>> On 5/20/19 5:20 PM, naoto.sato at oracle.com wrote:
>>> Ping?
>>>
>>> Naoto
>>>
>>> On 5/17/19 3:43 PM, naoto.sato at oracle.com wrote:
>>>> Hi,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8224105
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8224105/webrev.00/
>>>>
>>>> CLDR does not provide entire localized Japanese era names in locales 
>>>> mentioned in the bug report. The parsing has been failing as they 
>>>> have duplicate names, despite the duplicates are empty strings.
>>>>
>>>> Naoto

From james.laskey at oracle.com  Tue May 21 21:10:31 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 21 May 2019 18:10:31 -0300
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <5CE43F5E.1050102@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
 <5CE43F5E.1050102@oracle.com>
Message-ID: <008FA8AC-7CC8-4352-A90F-7B459288F364@oracle.com>

Updated version http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 <http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02>



> On May 21, 2019, at 3:11 PM, Alex Buckley <Alex.Buckley at oracle.com> wrote:
> 
> On 5/21/2019 7:56 AM, Jim Laskey wrote:
>> Please do a code review of the new String::stripIndent instance method.
> 
> My interest is in the API spec because the JLS will make normative reference to it.
> 
> 
> "Removes horizontal white space margins from the essential body of a
> Text Block originated string, while preserving relative indentation."
> 
> Lots of concepts here: margins, "essential body", a "Text Block originated string" (not just any string?). Looks like the removal happens in-place. While "essential" is a concept from the JEP, I think the sibling concept, "incidental", is the one to lead with. Alluding to multiple lines is also good. Recommend:
> 
> "Returns a string whose value is this string, with incidental white space removed from the beginning and end of every line."
> 
> That is, 'stripIndent' isn't quite as generic as its name suggests. It implements a particular policy about "incidental" white space that we will now explain...
> 
> 
> New paragraph: "Incidental white space is often present in a text block to align the content with the opening delimiter. For example, in the following code, dots represent incidental white space:
> 
> String html = """
> ..............<html>
> ..............    <body>
> ..............        <p>Hello, world</p>
> ..............    </body>
> ..............</html>
> ..............""";
> 
> 
> Another new para, to link this high-falutin' incidental concept to the workmanlike name of this method:  "This method treats the incidental white space as indentation to be stripped, producing a string that preserves the relative indentation of the content. Using | to visualize the start of each line of the string:
> 
> |<html>
> |    <body>
> |        <p>Hello, world</p>
> |    </body>
> |</html>
> 
> 
> Now, the algo. "This string is first conceptually separated into lines as if by {@link String#lines()}." -- phrasing: "First, this string is conceptually ..."
> 
> 
> "Then, the <i>minimum indentation</i> (min) is determined as follows. For each non-blank line (as defined by {@link String#isBlank()}), the
> leading {@link Character#isWhitespace(int) white space} characters are
> counted. The leading {@link Character#isWhitespace(int) white space} characters on the last line are are also counted even if blank.
> The <i>min</i> value is the smallest of these counts."
> 
> No more "common white space prefix" like in the JEP? OK, fair enough, we're now fully rotated to "indentation" rather than "white space".
> 
> 
> "For each non-blank line, <i>min</i> leading white space characters are
> removed. Each white space character is treated as a single character. In
> particular, the tab character {@code "\t"} (U+0009) is considered a
> single character; it is not expanded.
> 
> The trailing white space of each line is also removed."
> 
> The trailing white space characters are just as "treated as a single character" as the leading white space characters. Recommend:  "For each non-blank line, <i>min</i> leading white space characters are removed, and any trailing white space characters are removed."
> 
> 
> Recommend handling escape sequences in a separate para. Showing "\t", a two character sequence, and then alluding to \u0009, a single character, is confusing.
> 
> 
> "Each line is suffixed with a line feed character {@code "\n"} (U+000A),
> except for the last line. The last line is suffixed with a line feed
> character {@code "\n"} (U+000A) only if the original last line was blank."
> 
> The phrasing "except for the last line" is odd because it suggests the last line never gets a suffix. Except, oh, it might. And "suffixed" is an unusual word. If you're going to allude to the original string's last line, then isn't there a way to lean on it more? e.g. "A line feed character is appended to every line if the corresponding line in the original string was terminated with a line feed character."  (Not saying that is correct or desirable, but is easier to visualize.)
> 
> 
> "Finally, the lines are concatenated into a single string and returned."
> 
> Recommend: "Finally, the lines are concatenated into a string, which is the result."
> 
> Alex


From henry.jen at oracle.com  Tue May 21 22:41:11 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 21 May 2019 15:41:11 -0700
Subject: RFR: 8218997: Xusage text, man help, etc doesn't mention -Xlog option.
Message-ID: <5B51128B-5A83-4B45-BAEC-B690F105878C@oracle.com>

Hi,

Please review a trivial patch that add some hints about how to use -Xlog in java help and man page.

diff -r cd3eeeec74c0 src/java.base/share/classes/sun/launcher/resources/launcher.properties
--- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:08:50 2019 -0700
+++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:31:52 2019 -0700
@@ -138,6 +138,7 @@
 \    -Xinternalversion\n\
 \                      displays more detailed JVM version information than the\n\
 \                      -version option\n\
+\    -Xlog:<opts>      control JVM logging, use -Xlog:help for details
 \    -Xloggc:<file>    log GC status to a file with time stamps\n\
 \    -Xmixed           mixed mode execution (default)\n\
 \    -Xmn<size>        sets the initial and maximum size (in bytes) of the heap\n\
diff -r cd3eeeec74c0 src/java.base/share/man/java.1
--- a/src/java.base/share/man/java.1    Tue May 21 15:08:50 2019 -0700
+++ b/src/java.base/share/man/java.1    Tue May 21 15:31:52 2019 -0700
@@ -732,6 +732,11 @@
 option, and then exits\&.
 .RE
 .PP
+\-Xlog:\fIopts\fR
+.RS 4
+Control JVM logging, use \fB\-Xlog:help\fR for details.
+.RE
+.PP
 \-Xloggc:\fIfilename\fR
 .RS 4
 Sets the file to which verbose GC events information should be redirected for logging\&. The information written to this file is similar to the output of

Cheers,
Henry


From david.holmes at oracle.com  Tue May 21 23:11:25 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 May 2019 09:11:25 +1000
Subject: RFR: 8218997: Xusage text, man help, etc doesn't mention -Xlog
 option.
In-Reply-To: <5B51128B-5A83-4B45-BAEC-B690F105878C@oracle.com>
References: <5B51128B-5A83-4B45-BAEC-B690F105878C@oracle.com>
Message-ID: <ad47e0fb-f018-68b7-f32d-048ec5df1c66@oracle.com>

Hi Henry,

On 22/05/2019 8:41 am, Henry Jen wrote:
> Hi,
> 
> Please review a trivial patch that add some hints about how to use -Xlog in java help and man page.
> 
> diff -r cd3eeeec74c0 src/java.base/share/classes/sun/launcher/resources/launcher.properties
> --- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:08:50 2019 -0700
> +++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:31:52 2019 -0700
> @@ -138,6 +138,7 @@
>   \    -Xinternalversion\n\
>   \                      displays more detailed JVM version information than the\n\
>   \                      -version option\n\
> +\    -Xlog:<opts>      control JVM logging, use -Xlog:help for details

I would suggest using the same words as used in the online tool 
reference page [1]:

Configure or enable logging with the Java Virtual Machine (JVM) unified 
logging framework. Use -Xlog:help for details.

Ditto for the man page.

Cheers,
David

[1] 
https://docs.oracle.com/en/java/javase/12/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE

>   \    -Xloggc:<file>    log GC status to a file with time stamps\n\
>   \    -Xmixed           mixed mode execution (default)\n\
>   \    -Xmn<size>        sets the initial and maximum size (in bytes) of the heap\n\
> diff -r cd3eeeec74c0 src/java.base/share/man/java.1
> --- a/src/java.base/share/man/java.1    Tue May 21 15:08:50 2019 -0700
> +++ b/src/java.base/share/man/java.1    Tue May 21 15:31:52 2019 -0700
> @@ -732,6 +732,11 @@
>   option, and then exits\&.
>   .RE
>   .PP
> +\-Xlog:\fIopts\fR
> +.RS 4
> +Control JVM logging, use \fB\-Xlog:help\fR for details.
> +.RE
> +.PP
>   \-Xloggc:\fIfilename\fR
>   .RS 4
>   Sets the file to which verbose GC events information should be redirected for logging\&. The information written to this file is similar to the output of
> 
> Cheers,
> Henry
> 

From brent.christian at oracle.com  Tue May 21 23:15:22 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 21 May 2019 16:15:22 -0700
Subject: RFR - JDK-8223780 String::translateEscapes (Preview)
In-Reply-To: <FFE10AB9-B2FB-402A-B24E-62D7E6B3C2FF@oracle.com>
References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>
 <abfcefd9-46f5-a49e-cf53-ed5930a04034@oracle.com>
 <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com>
 <FFE10AB9-B2FB-402A-B24E-62D7E6B3C2FF@oracle.com>
Message-ID: <59ddca70-013e-07d7-ede4-09f1a9c15456@oracle.com>

Hi, Jim

I have some comments on the CSR and the Webrev.


CSR:
====

"This method takes the receiver String a replaces escape sequences with 
character equivalents."

a -> and

--

In the specification, I like emphasizing that nothing happens to 'this', 
but rather to the returned string, so maybe something like:

"Returns a string with all escape sequences translated into characters 
represented by..."


Webrev:
=======

src/java.base/share/classes/java/lang/String.java

3006                 case '\'': case '\"': case '\\':

I would find this easier to read with one case per line, so:

     case '\'':
     case '\"':
     case '\\':
         break;


test/jdk/java/lang/String/TranslateEscapes.java


The test should cover octal escapes, and cases that throw 
IllegalArgumentException.

Why does the test need to run in othervm ?

Thanks,
-Brent


On 5/21/19 12:24 PM, Jim Laskey wrote:
> Revised at http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html>
> 
> 
> 
>> On May 21, 2019, at 3:23 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>>
>>
>>
>>> On May 21, 2019, at 2:57 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>>
>>> Hi Jim!
>>>
>>> A few comments:
>>>
>>> 1)
>>> Probably, there's no need to update ch in these cases:
>>>                case '\'':
>>>                    ch = '\'';
>>>                    break;
>>>                case '\"':
>>>                    ch = '\"';
>>>                    break;
>>
>> True
>>
>>>
>>> 2)
>>> Character.digit(ch, 8) will accept non-Latin1 digits.
>>> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377.
>>> (Note, that the first digit still can only be from range '0'-'9').
>>
>> Also true. Subtlety in UnicodeReader.
>>
>>>
>>> 3)
>>> It's not obvious how this condition can be triggered:
>>>                    if (0377 < code) {
>>>                        throw new MalformedEscapeException(from);
>>>                    }
>>> I might be missing something, but I cannot see how 'code' can become > 0377.
>>
>> I removed this check in round 2.
>>
>>>
>>> 4)
>>> throw new MalformedEscapeException(from);
>>> This will report the next index after the error.  Was it intentional?
>>>
>>
>> I switched to using an IllegalArgumentError and displaying the actual character.
>>
>>
>>> With kind regards,
>>> Ivan
>>
>> Much thanks.
>>
>>
>>>
>>>
>>> On 5/21/19 7:56 AM, Jim Laskey wrote:
>>>> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content.
>>>>
>>>> Thank you.
>>>>
>>>> -- Jim
>>>>
>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01>
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 <https://bugs.openjdk.java.net/browse/JDK-8223780>
>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 <https://bugs.openjdk.java.net/browse/JDK-8223781>
>>>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>
>>>>
>>>>
>>>
>>> -- 
>>> With kind regards,
>>> Ivan Gerasimov
>>>
>>
> 

From alex.buckley at oracle.com  Tue May 21 23:19:13 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 21 May 2019 16:19:13 -0700
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <008FA8AC-7CC8-4352-A90F-7B459288F364@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
 <5CE43F5E.1050102@oracle.com>
 <008FA8AC-7CC8-4352-A90F-7B459288F364@oracle.com>
Message-ID: <5CE48771.6030509@oracle.com>

On 5/21/2019 2:10 PM, Jim Laskey wrote:
> Updated version http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02

This webrev substantially updates the API spec, which is really a topic 
for amber-spec-experts (keep reading to see why). Cross-posting between 
-dev and -spec-experts lists is not good, so maybe we can wrap this up 
here without prolonged discussion.

API spec looks good, but it was a surprise to learn that stripIndent 
performs normalization of line terminators:

"@return string with margins removed and line terminators normalized"

The processing steps in the JEP (and the JLS) are clear that 
normalization happens before incidental white space removal. I realize 
that stripIndent performs separation and joining in such a way as to 
produce a string that looks like it was normalized prior to stripIndent, 
so the @return isn't wrong, but it's still confusing to make a big deal 
of normalization-first only for stripIndent to suggest normalization-last.

I think we should leave the JEP alone, since it interleaves behavior 
with motivation and examples in order to aid the reader, but we should 
align the JLS with the API:

-----
The string represented by a text block is not the literal sequence of 
characters in the content. Instead, the string represented by a text 
block is the result of applying the following transformations to the 
content, in order:

1. _Incidental white space_ is removed and line terminators are 
_normalized_, as if by execution of String::stripIndent on the 
characters in the content. [The emphasized terms are a hint to the API 
spec to define the term, which is not currently the case for the second 
term.]

2. Escape sequences are interpreted, as in a string literal.
-----

String::indent also says "normalizes line termination characters" 
without defining it. Separately, String::stripIndent is not at all like 
the strip, stripLeading, and stripTrailing methods which sound related 
to it -- they would pointlessly strip the first row of white space dots 
from a multi-line string and leave the other rows.

Taking all this together, I think it's time to upgrade the class-level 
spec of String: to advertise the new methods added in 11+, and to show 
text blocks, and to get some terms defined for the benefit of multiple 
methods. I realize this wasn't on your radar, but it's inevitable -- the 
same thing happened for the class-level spec of Class when nestmates 
were introduced. So, here goes:

-----
The String class represents character strings. ~~All~~ String literals 
**and text blocks** in Java programs ~~, such as "abc",~~ are 
implemented as instances of this class.

The strings represented this class are constant; their values cannot be 
changed after they are created. (For mutable strings, see StringBuffer 
and StringBuilder.) Because instances of `String` are immutable, they 
can be shared. For example: ...

[The example with a char[] is quite subtle for a beginner, but I'm 
skipping over it right now.]

The class String includes methods for examining individual characters of 
the sequence, for comparing strings, for searching strings, for 
extracting substrings, and for creating a copy of a string with all 
characters translated to uppercase or to lowercase. Case mapping is 
based on the Unicode Standard version specified by the Character class.

Here are some examples of how strings can be used:

          System.out.println("abc");
          String cde = "cde";
          String c = "abc".substring(2,3);
          String d = cde.substring(1, 2);

Unless otherwise noted, methods for comparing Strings do not take locale 
into account. The Collator class provides methods for finer-grain, 
locale-sensitive String comparison.

Unless otherwise noted, passing a null argument to a constructor or 
method in this class will cause a NullPointerException to be thrown. 
[This doesn't fit anywhere. j.l.Character doesn't bother with it, even 
though its methods throw NPEs too. Maybe time to drop. We have lots more 
important stuff to say.]

### String concatenation

The Java language provides special support for the string concatenation 
operator (`+`), and for conversion of other objects to strings. For 
additional information on string concatenation and conversion, see The 
Java? Language Specification.  [Somehow this manages to skip the valueOf 
methods, which in conjunction with things like Integer::parseInt are 
worthy of a paragraph by themselves. Future work.]

Here are some examples of string concatenation:

      String cde = "cde";
      System.out.println("abc" + cde);

[These examples are dull, and don't describe their output, and need to 
show text blocks. Future work.]

### String processing

The strings represented by this class may span multiple lines by 
including _line terminators_ among their characters. A line terminator 
is one of the following: a line feed character LF (U+000A), a carriage 
return character CR (U+000D), or a carriage return followed immediately 
by a line feed CRLF (U+000D U+000A).  [Don't want to show escape 
sequences like \n yet.]

A string has _normalized_ line terminators if LF is the only line 
terminator which appears in the string. Many methods of this class 
_normalize_ the strings they return by ensuring that CR and CRLF are 
translated to LF.

The class String also includes methods for manipulating non-alphanumeric 
characters in strings, such as converting escape sequences into 
non-graphic characters, and stripping white space.  [This paragraph is a 
jumping off point for describing stripIndent's special relationship with 
text blocks.]

### Unicode

A String represents a string in the UTF-16 format in which supplementary 
characters are represented by surrogate pairs (see the section Unicode 
Character Representations in the Character class for more information). 
Index values refer to char code units, so a supplementary character uses 
two positions in a String.

The String class provides methods for dealing with Unicode code points 
(i.e., characters), in addition to those for dealing with Unicode code 
units (i.e., char values).
-----

Alex

From henry.jen at oracle.com  Tue May 21 23:40:24 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 21 May 2019 16:40:24 -0700
Subject: RFR: 8218997: Xusage text, man help, etc doesn't mention -Xlog
 option.
In-Reply-To: <ad47e0fb-f018-68b7-f32d-048ec5df1c66@oracle.com>
References: <5B51128B-5A83-4B45-BAEC-B690F105878C@oracle.com>
 <ad47e0fb-f018-68b7-f32d-048ec5df1c66@oracle.com>
Message-ID: <03019265-2CDC-4B57-864A-7FDE68C8529A@oracle.com>

Good suggestion, didn?t know about that page. I took what?s in Xusage.txt. Updated as following,

diff -r cd3eeeec74c0 src/java.base/share/classes/sun/launcher/resources/launcher.properties
--- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:08:50 2019 -0700
+++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 16:38:42 2019 -0700
@@ -138,6 +138,9 @@
 \    -Xinternalversion\n\
 \                      displays more detailed JVM version information than the\n\
 \                      -version option\n\
+\    -Xlog:<opts>      Configure or enable logging with the Java Virtual\n\
+\                      Machine (JVM) unified logging framework. Use -Xlog:help\n\
+\                      for details.\n\
 \    -Xloggc:<file>    log GC status to a file with time stamps\n\
 \    -Xmixed           mixed mode execution (default)\n\
 \    -Xmn<size>        sets the initial and maximum size (in bytes) of the heap\n\
diff -r cd3eeeec74c0 src/java.base/share/man/java.1
--- a/src/java.base/share/man/java.1    Tue May 21 15:08:50 2019 -0700
+++ b/src/java.base/share/man/java.1    Tue May 21 16:38:42 2019 -0700
@@ -732,6 +732,11 @@
 option, and then exits\&.
 .RE
 .PP
+\-Xlog:\fIopts\fR
+.RS 4
+Configure or enable logging with the Java Virtual Machine (JVM) unified logging framework. Use \fB\-Xlog:help\fR for details.
+.RE
+.PP
 \-Xloggc:\fIfilename\fR
 .RS 4
 Sets the file to which verbose GC events information should be redirected for logging\&. The information written to this file is similar to the output of


Cheers,
Henry


> On May 21, 2019, at 4:11 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Henry,
> 
> On 22/05/2019 8:41 am, Henry Jen wrote:
>> Hi,
>> Please review a trivial patch that add some hints about how to use -Xlog in java help and man page.
>> diff -r cd3eeeec74c0 src/java.base/share/classes/sun/launcher/resources/launcher.properties
>> --- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:08:50 2019 -0700
>> +++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:31:52 2019 -0700
>> @@ -138,6 +138,7 @@
>>  \    -Xinternalversion\n\
>>  \                      displays more detailed JVM version information than the\n\
>>  \                      -version option\n\
>> +\    -Xlog:<opts>      control JVM logging, use -Xlog:help for details
> 
> I would suggest using the same words as used in the online tool reference page [1]:
> 
> Configure or enable logging with the Java Virtual Machine (JVM) unified logging framework. Use -Xlog:help for details.
> 
> Ditto for the man page.
> 
> Cheers,
> David
> 
> [1] https://docs.oracle.com/en/java/javase/12/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE
> 
>>  \    -Xloggc:<file>    log GC status to a file with time stamps\n\
>>  \    -Xmixed           mixed mode execution (default)\n\
>>  \    -Xmn<size>        sets the initial and maximum size (in bytes) of the heap\n\
>> diff -r cd3eeeec74c0 src/java.base/share/man/java.1
>> --- a/src/java.base/share/man/java.1    Tue May 21 15:08:50 2019 -0700
>> +++ b/src/java.base/share/man/java.1    Tue May 21 15:31:52 2019 -0700
>> @@ -732,6 +732,11 @@
>>  option, and then exits\&.
>>  .RE
>>  .PP
>> +\-Xlog:\fIopts\fR
>> +.RS 4
>> +Control JVM logging, use \fB\-Xlog:help\fR for details.
>> +.RE
>> +.PP
>>  \-Xloggc:\fIfilename\fR
>>  .RS 4
>>  Sets the file to which verbose GC events information should be redirected for logging\&. The information written to this file is similar to the output of
>> Cheers,
>> Henry


From david.holmes at oracle.com  Wed May 22 00:26:15 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 May 2019 10:26:15 +1000
Subject: RFR: 8218997: Xusage text, man help, etc doesn't mention -Xlog
 option.
In-Reply-To: <03019265-2CDC-4B57-864A-7FDE68C8529A@oracle.com>
References: <5B51128B-5A83-4B45-BAEC-B690F105878C@oracle.com>
 <ad47e0fb-f018-68b7-f32d-048ec5df1c66@oracle.com>
 <03019265-2CDC-4B57-864A-7FDE68C8529A@oracle.com>
Message-ID: <844bc10b-ab97-b7e0-92d3-6c4c00e08bfb@oracle.com>

That works for me. :)

Thanks,
David

On 22/05/2019 9:40 am, Henry Jen wrote:
> Good suggestion, didn?t know about that page. I took what?s in Xusage.txt. Updated as following,
> 
> diff -r cd3eeeec74c0 src/java.base/share/classes/sun/launcher/resources/launcher.properties
> --- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:08:50 2019 -0700
> +++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 16:38:42 2019 -0700
> @@ -138,6 +138,9 @@
>   \    -Xinternalversion\n\
>   \                      displays more detailed JVM version information than the\n\
>   \                      -version option\n\
> +\    -Xlog:<opts>      Configure or enable logging with the Java Virtual\n\
> +\                      Machine (JVM) unified logging framework. Use -Xlog:help\n\
> +\                      for details.\n\
>   \    -Xloggc:<file>    log GC status to a file with time stamps\n\
>   \    -Xmixed           mixed mode execution (default)\n\
>   \    -Xmn<size>        sets the initial and maximum size (in bytes) of the heap\n\
> diff -r cd3eeeec74c0 src/java.base/share/man/java.1
> --- a/src/java.base/share/man/java.1    Tue May 21 15:08:50 2019 -0700
> +++ b/src/java.base/share/man/java.1    Tue May 21 16:38:42 2019 -0700
> @@ -732,6 +732,11 @@
>   option, and then exits\&.
>   .RE
>   .PP
> +\-Xlog:\fIopts\fR
> +.RS 4
> +Configure or enable logging with the Java Virtual Machine (JVM) unified logging framework. Use \fB\-Xlog:help\fR for details.
> +.RE
> +.PP
>   \-Xloggc:\fIfilename\fR
>   .RS 4
>   Sets the file to which verbose GC events information should be redirected for logging\&. The information written to this file is similar to the output of
> 
> 
> Cheers,
> Henry
> 
> 
>> On May 21, 2019, at 4:11 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Henry,
>>
>> On 22/05/2019 8:41 am, Henry Jen wrote:
>>> Hi,
>>> Please review a trivial patch that add some hints about how to use -Xlog in java help and man page.
>>> diff -r cd3eeeec74c0 src/java.base/share/classes/sun/launcher/resources/launcher.properties
>>> --- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:08:50 2019 -0700
>>> +++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:31:52 2019 -0700
>>> @@ -138,6 +138,7 @@
>>>   \    -Xinternalversion\n\
>>>   \                      displays more detailed JVM version information than the\n\
>>>   \                      -version option\n\
>>> +\    -Xlog:<opts>      control JVM logging, use -Xlog:help for details
>>
>> I would suggest using the same words as used in the online tool reference page [1]:
>>
>> Configure or enable logging with the Java Virtual Machine (JVM) unified logging framework. Use -Xlog:help for details.
>>
>> Ditto for the man page.
>>
>> Cheers,
>> David
>>
>> [1] https://docs.oracle.com/en/java/javase/12/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE
>>
>>>   \    -Xloggc:<file>    log GC status to a file with time stamps\n\
>>>   \    -Xmixed           mixed mode execution (default)\n\
>>>   \    -Xmn<size>        sets the initial and maximum size (in bytes) of the heap\n\
>>> diff -r cd3eeeec74c0 src/java.base/share/man/java.1
>>> --- a/src/java.base/share/man/java.1    Tue May 21 15:08:50 2019 -0700
>>> +++ b/src/java.base/share/man/java.1    Tue May 21 15:31:52 2019 -0700
>>> @@ -732,6 +732,11 @@
>>>   option, and then exits\&.
>>>   .RE
>>>   .PP
>>> +\-Xlog:\fIopts\fR
>>> +.RS 4
>>> +Control JVM logging, use \fB\-Xlog:help\fR for details.
>>> +.RE
>>> +.PP
>>>   \-Xloggc:\fIfilename\fR
>>>   .RS 4
>>>   Sets the file to which verbose GC events information should be redirected for logging\&. The information written to this file is similar to the output of
>>> Cheers,
>>> Henry
> 

From henry.jen at oracle.com  Wed May 22 01:51:45 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 21 May 2019 18:51:45 -0700
Subject: RFR: 8218997: Xusage text, man help, etc doesn't mention -Xlog
 option.
In-Reply-To: <844bc10b-ab97-b7e0-92d3-6c4c00e08bfb@oracle.com>
References: <5B51128B-5A83-4B45-BAEC-B690F105878C@oracle.com>
 <ad47e0fb-f018-68b7-f32d-048ec5df1c66@oracle.com>
 <03019265-2CDC-4B57-864A-7FDE68C8529A@oracle.com>
 <844bc10b-ab97-b7e0-92d3-6c4c00e08bfb@oracle.com>
Message-ID: <689D3F9B-BD46-40D9-9F7D-3E398810CAC6@oracle.com>

It was brought to my attention that the java.1 page is out of date and labeled for jdk 8, thus I will withdraw the change for java.1. Only keep the change to launcher.properties.

Thanks for the review.

Cheers,
Henry

> On May 21, 2019, at 5:26 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> That works for me. :)
> 
> Thanks,
> David
> 
> On 22/05/2019 9:40 am, Henry Jen wrote:
>> Good suggestion, didn?t know about that page. I took what?s in Xusage.txt. Updated as following,
>> diff -r cd3eeeec74c0 src/java.base/share/classes/sun/launcher/resources/launcher.properties
>> --- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:08:50 2019 -0700
>> +++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 16:38:42 2019 -0700
>> @@ -138,6 +138,9 @@
>>  \    -Xinternalversion\n\
>>  \                      displays more detailed JVM version information than the\n\
>>  \                      -version option\n\
>> +\    -Xlog:<opts>      Configure or enable logging with the Java Virtual\n\
>> +\                      Machine (JVM) unified logging framework. Use -Xlog:help\n\
>> +\                      for details.\n\
>>  \    -Xloggc:<file>    log GC status to a file with time stamps\n\
>>  \    -Xmixed           mixed mode execution (default)\n\
>>  \    -Xmn<size>        sets the initial and maximum size (in bytes) of the heap\n\
>> diff -r cd3eeeec74c0 src/java.base/share/man/java.1
>> --- a/src/java.base/share/man/java.1    Tue May 21 15:08:50 2019 -0700
>> +++ b/src/java.base/share/man/java.1    Tue May 21 16:38:42 2019 -0700
>> @@ -732,6 +732,11 @@
>>  option, and then exits\&.
>>  .RE
>>  .PP
>> +\-Xlog:\fIopts\fR
>> +.RS 4
>> +Configure or enable logging with the Java Virtual Machine (JVM) unified logging framework. Use \fB\-Xlog:help\fR for details.
>> +.RE
>> +.PP
>>  \-Xloggc:\fIfilename\fR
>>  .RS 4
>>  Sets the file to which verbose GC events information should be redirected for logging\&. The information written to this file is similar to the output of
>> Cheers,
>> Henry
>>> On May 21, 2019, at 4:11 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Henry,
>>> 
>>> On 22/05/2019 8:41 am, Henry Jen wrote:
>>>> Hi,
>>>> Please review a trivial patch that add some hints about how to use -Xlog in java help and man page.
>>>> diff -r cd3eeeec74c0 src/java.base/share/classes/sun/launcher/resources/launcher.properties
>>>> --- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:08:50 2019 -0700
>>>> +++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties    Tue May 21 15:31:52 2019 -0700
>>>> @@ -138,6 +138,7 @@
>>>>  \    -Xinternalversion\n\
>>>>  \                      displays more detailed JVM version information than the\n\
>>>>  \                      -version option\n\
>>>> +\    -Xlog:<opts>      control JVM logging, use -Xlog:help for details
>>> 
>>> I would suggest using the same words as used in the online tool reference page [1]:
>>> 
>>> Configure or enable logging with the Java Virtual Machine (JVM) unified logging framework. Use -Xlog:help for details.
>>> 
>>> Ditto for the man page.
>>> 
>>> Cheers,
>>> David
>>> 
>>> [1] https://docs.oracle.com/en/java/javase/12/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE
>>> 
>>>>  \    -Xloggc:<file>    log GC status to a file with time stamps\n\
>>>>  \    -Xmixed           mixed mode execution (default)\n\
>>>>  \    -Xmn<size>        sets the initial and maximum size (in bytes) of the heap\n\
>>>> diff -r cd3eeeec74c0 src/java.base/share/man/java.1
>>>> --- a/src/java.base/share/man/java.1    Tue May 21 15:08:50 2019 -0700
>>>> +++ b/src/java.base/share/man/java.1    Tue May 21 15:31:52 2019 -0700
>>>> @@ -732,6 +732,11 @@
>>>>  option, and then exits\&.
>>>>  .RE
>>>>  .PP
>>>> +\-Xlog:\fIopts\fR
>>>> +.RS 4
>>>> +Control JVM logging, use \fB\-Xlog:help\fR for details.
>>>> +.RE
>>>> +.PP
>>>>  \-Xloggc:\fIfilename\fR
>>>>  .RS 4
>>>>  Sets the file to which verbose GC events information should be redirected for logging\&. The information written to this file is similar to the output of
>>>> Cheers,
>>>> Henry


From thomas.stuefe at gmail.com  Wed May 22 06:16:21 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 22 May 2019 08:16:21 +0200
Subject: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to
 exec() jspawnhelper does not result in an error
In-Reply-To: <CAA-vtUwEu7RSL7vdQuzGziopQvUXomSLEOsFaDjzSQvxL5uvZA@mail.gmail.com>
References: <CAA-vtUwEu7RSL7vdQuzGziopQvUXomSLEOsFaDjzSQvxL5uvZA@mail.gmail.com>
Message-ID: <CAA-vtUwA5P5OAj2fEEgsE7rGfefsbY4Ea_2qoyZD1SQAFuYLsA@mail.gmail.com>

Ping...

Guys, I need some feedback on this. If we do not fix this issue, we may
want to roll back the use of posix_spawn() as a default and return to vfork
for JDK13.

The fix has been tested in our nightlies for two nights in a row and did
not show any errors.

Cheers, Thomas


On Mon, May 20, 2019 at 4:15 PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi all,
>
> (old mail thread:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html
> )
>
> May I please have your reviews and opinions for the following bug fix:
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8223777
> cr:
> http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error-alternate-impl/webrev.00/webrev/
>
> ---
>
> The fix implements Florians proposal: the jspawnhelper will signal its
> aliveness to the parent process the moment it gains control. If the parent
> process does not get the signal, it assumes exec'ing the jspawnhelper never
> worked.
>
> I only do this for posix_spawn mode, out of cautiousness.
>
> (Note that I kept the fix as minimal as possible. I found a minor bug and
> some improvement possibilities and opened follow up issues to track them:
> JDK-8224180 and JDK-8224181).
>
> Thanks, Thomas
>
>
>

From deepak.kejriwal at oracle.com  Wed May 22 07:18:48 2019
From: deepak.kejriwal at oracle.com (Deepak Kejriwal)
Date: Wed, 22 May 2019 07:18:48 +0000 (UTC)
Subject: [13] RFR: 8214565 and 8214563: Use {@systemProperty} for
 definitions of system properties
In-Reply-To: <e7572c44-ccab-b85f-6e2b-2b36a2837a69@oracle.com>
References: <a247ca74-b991-4b6a-8c8a-fb9885cd6502@default>
 <7537dd9f-6392-1936-3e55-41cf8936bf48@oracle.com>
 <e7572c44-ccab-b85f-6e2b-2b36a2837a69@oracle.com>
Message-ID: <46aae025-f5f7-4752-baa1-f5b2b983518f@default>

Hi Roger,

Thanks for review. Please find below updated version of webrev:-

http://cr.openjdk.java.net/~dkejriwal/8214565_8214563/webrev.01/

Regards,
Deepak

-----Original Message-----
From: Roger Riggs 
Sent: Friday, May 17, 2019 8:35 PM
To: core-libs-dev at openjdk.java.net
Subject: Re: [13] RFR: 8214565 and 8214563: Use {@systemProperty} for definitions of system properties

Hi,
AsynchronousChannelProvider.java: line 144:? needs a space in "anunspecified"
 ? That sentence isn't very well worded, but is outside the scope of this change to add the tag.

Otherwise, looks fine.

Roger




On 05/17/2019 06:49 AM, Alan Bateman wrote:
> On 17/05/2019 10:49, Deepak Kejriwal wrote:
>> Hi all,
>>
>>
>> Please review the fix for following issues:-
>>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8214565
>>
>> https://bugs.openjdk.java.net/browse/JDK-8214563
>>
>>
>> Below is the webrev for above issues:
>>
>>
>> http://cr.openjdk.java.net/~dkejriwal/8214565_8214563/webrev.00/
>>
> This looks okay to me.
>
> -Alan


From fweimer at redhat.com  Wed May 22 08:21:54 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 22 May 2019 10:21:54 +0200
Subject: RFR - JDK-8203444 String::formatted (Preview)
In-Reply-To: <664BC60B-C09A-4F4F-8045-A70B1DF09401@oracle.com> (Jim Laskey's
 message of "Tue, 21 May 2019 12:56:11 -0300")
References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com>
 <8736l798cu.fsf@oldenburg2.str.redhat.com>
 <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com>
 <87h89n7qxv.fsf@oldenburg2.str.redhat.com>
 <664BC60B-C09A-4F4F-8045-A70B1DF09401@oracle.com>
Message-ID: <87imu26grh.fsf@oldenburg2.str.redhat.com>

* Jim Laskey:

> Good point. To make sure I fully understand what you are stating,
>
> - The argument for having an instance method is reasonable to achieve
> "flowiness".

Right.

> - However, only one version is necessary or desired, that is, "public
> String formatted(Object... args)".

Yes, this appears to be the common use case to me.  I doubt the overload
with its ambiguity is sufficiently widely used to be worth the potential
confusion it can create.  Adding the method with the Locale parameter
under a different name would be okay (except that I'm not sure how
widely it is going to be used).

My totally random set of Java classes (mostly from Fedora and
downstream) shows this:


SELECT jr.descriptor, COUNT(*)  descriptor
  FROM symboldb.java_reference jr
  WHERE jr.class_name = 'java/lang/String' AND jr.name = 'format'
  GROUP BY jr.descriptor;
  
                                 descriptor                                  | descriptor 
-----------------------------------------------------------------------------+------------
 (Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/String;                   |       9220
 (Ljava/util/Locale;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/String; |        436
(2 rows)

So for the existing String::format method, the version without the
explicit Locale argument is much more commonly used.

> - In cases where Locale needs to be overridden, then either use
> "String.format(Locale lc, String fmt, Object... args)" or globally set
> "Locale.setDefault(Locale lc)".

I wouldn't recommend changing global state in this way.

Thanks,
Florian

From james.laskey at oracle.com  Wed May 22 13:23:18 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 22 May 2019 10:23:18 -0300
Subject: RFR - JDK-8223780 String::translateEscapes (Preview)
In-Reply-To: <59ddca70-013e-07d7-ede4-09f1a9c15456@oracle.com>
References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>
 <abfcefd9-46f5-a49e-cf53-ed5930a04034@oracle.com>
 <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com>
 <FFE10AB9-B2FB-402A-B24E-62D7E6B3C2FF@oracle.com>
 <59ddca70-013e-07d7-ede4-09f1a9c15456@oracle.com>
Message-ID: <A5D2C286-4536-4070-9E3C-3FE31227BF82@oracle.com>

Thank you. Will integrate your suggested changes.

> On May 21, 2019, at 8:15 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Hi, Jim
> 
> I have some comments on the CSR and the Webrev.
> 
> 
> CSR:
> ====
> 
> "This method takes the receiver String a replaces escape sequences with character equivalents."
> 
> a -> and
> 
> --
> 
> In the specification, I like emphasizing that nothing happens to 'this', but rather to the returned string, so maybe something like:
> 
> "Returns a string with all escape sequences translated into characters represented by..."
> 
> 
> Webrev:
> =======
> 
> src/java.base/share/classes/java/lang/String.java
> 
> 3006                 case '\'': case '\"': case '\\':
> 
> I would find this easier to read with one case per line, so:
> 
>    case '\'':
>    case '\"':
>    case '\\':
>        break;
> 
> 
> test/jdk/java/lang/String/TranslateEscapes.java
> 
> 
> The test should cover octal escapes, and cases that throw IllegalArgumentException.
> 
> Why does the test need to run in othervm ?
> 
> Thanks,
> -Brent
> 
> 
> On 5/21/19 12:24 PM, Jim Laskey wrote:
>> Revised at http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html>
>>> On May 21, 2019, at 3:23 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>>> 
>>> 
>>> 
>>>> On May 21, 2019, at 2:57 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>>> 
>>>> Hi Jim!
>>>> 
>>>> A few comments:
>>>> 
>>>> 1)
>>>> Probably, there's no need to update ch in these cases:
>>>>               case '\'':
>>>>                   ch = '\'';
>>>>                   break;
>>>>               case '\"':
>>>>                   ch = '\"';
>>>>                   break;
>>> 
>>> True
>>> 
>>>> 
>>>> 2)
>>>> Character.digit(ch, 8) will accept non-Latin1 digits.
>>>> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377.
>>>> (Note, that the first digit still can only be from range '0'-'9').
>>> 
>>> Also true. Subtlety in UnicodeReader.
>>> 
>>>> 
>>>> 3)
>>>> It's not obvious how this condition can be triggered:
>>>>                   if (0377 < code) {
>>>>                       throw new MalformedEscapeException(from);
>>>>                   }
>>>> I might be missing something, but I cannot see how 'code' can become > 0377.
>>> 
>>> I removed this check in round 2.
>>> 
>>>> 
>>>> 4)
>>>> throw new MalformedEscapeException(from);
>>>> This will report the next index after the error.  Was it intentional?
>>>> 
>>> 
>>> I switched to using an IllegalArgumentError and displaying the actual character.
>>> 
>>> 
>>>> With kind regards,
>>>> Ivan
>>> 
>>> Much thanks.
>>> 
>>> 
>>>> 
>>>> 
>>>> On 5/21/19 7:56 AM, Jim Laskey wrote:
>>>>> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content.
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> -- Jim
>>>>> 
>>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01>
>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 <https://bugs.openjdk.java.net/browse/JDK-8223780>
>>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 <https://bugs.openjdk.java.net/browse/JDK-8223781>
>>>>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>
>>>>> 
>>>>> 
>>>> 
>>>> -- 
>>>> With kind regards,
>>>> Ivan Gerasimov
>>>> 
>>> 


From Roger.Riggs at oracle.com  Wed May 22 13:30:56 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 May 2019 09:30:56 -0400
Subject: [13] RFR: 8214565 and 8214563: Use {@systemProperty} for
 definitions of system properties
In-Reply-To: <46aae025-f5f7-4752-baa1-f5b2b983518f@default>
References: <a247ca74-b991-4b6a-8c8a-fb9885cd6502@default>
 <7537dd9f-6392-1936-3e55-41cf8936bf48@oracle.com>
 <e7572c44-ccab-b85f-6e2b-2b36a2837a69@oracle.com>
 <46aae025-f5f7-4752-baa1-f5b2b983518f@default>
Message-ID: <3ffce17b-c458-2cee-9a96-da647b1091e3@oracle.com>

Looks good.

On 05/22/2019 03:18 AM, Deepak Kejriwal wrote:
> Hi Roger,
>
> Thanks for review. Please find below updated version of webrev:-
>
> http://cr.openjdk.java.net/~dkejriwal/8214565_8214563/webrev.01/
>
> Regards,
> Deepak
>
> -----Original Message-----
> From: Roger Riggs
> Sent: Friday, May 17, 2019 8:35 PM
> To: core-libs-dev at openjdk.java.net
> Subject: Re: [13] RFR: 8214565 and 8214563: Use {@systemProperty} for definitions of system properties
>
> Hi,
> AsynchronousChannelProvider.java: line 144:? needs a space in "anunspecified"
>   ? That sentence isn't very well worded, but is outside the scope of this change to add the tag.
>
> Otherwise, looks fine.
>
> Roger
>
>
>
>
> On 05/17/2019 06:49 AM, Alan Bateman wrote:
>> On 17/05/2019 10:49, Deepak Kejriwal wrote:
>>> Hi all,
>>>
>>>
>>> Please review the fix for following issues:-
>>>
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8214565
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8214563
>>>
>>>
>>> Below is the webrev for above issues:
>>>
>>>
>>> http://cr.openjdk.java.net/~dkejriwal/8214565_8214563/webrev.00/
>>>
>> This looks okay to me.
>>
>> -Alan


From thomas.stuefe at gmail.com  Wed May 22 14:39:01 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 22 May 2019 16:39:01 +0200
Subject: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to
 exec() jspawnhelper does not result in an error
In-Reply-To: <CAA-vtUwA5P5OAj2fEEgsE7rGfefsbY4Ea_2qoyZD1SQAFuYLsA@mail.gmail.com>
References: <CAA-vtUwEu7RSL7vdQuzGziopQvUXomSLEOsFaDjzSQvxL5uvZA@mail.gmail.com>
 <CAA-vtUwA5P5OAj2fEEgsE7rGfefsbY4Ea_2qoyZD1SQAFuYLsA@mail.gmail.com>
Message-ID: <CAA-vtUwvteeytHyFEMsHjEPZof4+VZcVnT9-ujSmRAKcn4Ss8w@mail.gmail.com>

No problems in tier 1 tests (jdk-submit).

..Thomas

On Wed, May 22, 2019 at 8:16 AM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Ping...
>
> Guys, I need some feedback on this. If we do not fix this issue, we may
> want to roll back the use of posix_spawn() as a default and return to vfork
> for JDK13.
>
> The fix has been tested in our nightlies for two nights in a row and did
> not show any errors.
>
> Cheers, Thomas
>
>
> On Mon, May 20, 2019 at 4:15 PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi all,
>>
>> (old mail thread:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html
>> )
>>
>> May I please have your reviews and opinions for the following bug fix:
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8223777
>> cr:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error-alternate-impl/webrev.00/webrev/
>>
>> ---
>>
>> The fix implements Florians proposal: the jspawnhelper will signal its
>> aliveness to the parent process the moment it gains control. If the parent
>> process does not get the signal, it assumes exec'ing the jspawnhelper never
>> worked.
>>
>> I only do this for posix_spawn mode, out of cautiousness.
>>
>> (Note that I kept the fix as minimal as possible. I found a minor bug and
>> some improvement possibilities and opened follow up issues to track them:
>> JDK-8224180 and JDK-8224181).
>>
>> Thanks, Thomas
>>
>>
>>

From david.lloyd at redhat.com  Wed May 22 14:41:09 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 22 May 2019 09:41:09 -0500
Subject: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to
 exec() jspawnhelper does not result in an error
In-Reply-To: <CAA-vtUwA5P5OAj2fEEgsE7rGfefsbY4Ea_2qoyZD1SQAFuYLsA@mail.gmail.com>
References: <CAA-vtUwEu7RSL7vdQuzGziopQvUXomSLEOsFaDjzSQvxL5uvZA@mail.gmail.com>
 <CAA-vtUwA5P5OAj2fEEgsE7rGfefsbY4Ea_2qoyZD1SQAFuYLsA@mail.gmail.com>
Message-ID: <CANghgrR8DSJ1zuCd9-sdsNsE8d_EKywM5SWcy1qMTMo8BGFqfQ@mail.gmail.com>

I'm in favor of what the change is meant to accomplish.  I haven't had
time to analyze the change in detail, and I may not get time to do so.
But I'm not a reviewer in any case, so maybe that doesn't matter too
much.

On Wed, May 22, 2019 at 1:16 AM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> Ping...
>
> Guys, I need some feedback on this. If we do not fix this issue, we may want to roll back the use of posix_spawn() as a default and return to vfork for JDK13.
>
> The fix has been tested in our nightlies for two nights in a row and did not show any errors.
>
> Cheers, Thomas
>
>
> On Mon, May 20, 2019 at 4:15 PM Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>>
>> Hi all,
>>
>> (old mail thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html)
>>
>> May I please have your reviews and opinions for the following bug fix:
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8223777
>> cr: http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error-alternate-impl/webrev.00/webrev/
>>
>> ---
>>
>> The fix implements Florians proposal: the jspawnhelper will signal its aliveness to the parent process the moment it gains control. If the parent process does not get the signal, it assumes exec'ing the jspawnhelper never worked.
>>
>> I only do this for posix_spawn mode, out of cautiousness.
>>
>> (Note that I kept the fix as minimal as possible. I found a minor bug and some improvement possibilities and opened follow up issues to track them: JDK-8224180 and JDK-8224181).
>>
>> Thanks, Thomas
>>
>>


-- 
- DML

From thomas.stuefe at gmail.com  Wed May 22 14:44:38 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 22 May 2019 16:44:38 +0200
Subject: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to
 exec() jspawnhelper does not result in an error
In-Reply-To: <CANghgrR8DSJ1zuCd9-sdsNsE8d_EKywM5SWcy1qMTMo8BGFqfQ@mail.gmail.com>
References: <CAA-vtUwEu7RSL7vdQuzGziopQvUXomSLEOsFaDjzSQvxL5uvZA@mail.gmail.com>
 <CAA-vtUwA5P5OAj2fEEgsE7rGfefsbY4Ea_2qoyZD1SQAFuYLsA@mail.gmail.com>
 <CANghgrR8DSJ1zuCd9-sdsNsE8d_EKywM5SWcy1qMTMo8BGFqfQ@mail.gmail.com>
Message-ID: <CAA-vtUySP9_f2n-tm=aq5VpBwkTZAsvFY-YO8PTOfunYvPW-DA@mail.gmail.com>

Any technical input is welcome, Reviewer or not. If a non-Reviewer sees
valid reasons for or against a patch, that is good to know.

Cheers, Thomas

On Wed, May 22, 2019 at 4:41 PM David Lloyd <david.lloyd at redhat.com> wrote:

> I'm in favor of what the change is meant to accomplish.  I haven't had
> time to analyze the change in detail, and I may not get time to do so.
> But I'm not a reviewer in any case, so maybe that doesn't matter too
> much.
>
> On Wed, May 22, 2019 at 1:16 AM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >
> > Ping...
> >
> > Guys, I need some feedback on this. If we do not fix this issue, we may
> want to roll back the use of posix_spawn() as a default and return to vfork
> for JDK13.
> >
> > The fix has been tested in our nightlies for two nights in a row and did
> not show any errors.
> >
> > Cheers, Thomas
> >
> >
> > On Mon, May 20, 2019 at 4:15 PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >>
> >> Hi all,
> >>
> >> (old mail thread:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html
> )
> >>
> >> May I please have your reviews and opinions for the following bug fix:
> >>
> >> issue: https://bugs.openjdk.java.net/browse/JDK-8223777
> >> cr:
> http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error-alternate-impl/webrev.00/webrev/
> >>
> >> ---
> >>
> >> The fix implements Florians proposal: the jspawnhelper will signal its
> aliveness to the parent process the moment it gains control. If the parent
> process does not get the signal, it assumes exec'ing the jspawnhelper never
> worked.
> >>
> >> I only do this for posix_spawn mode, out of cautiousness.
> >>
> >> (Note that I kept the fix as minimal as possible. I found a minor bug
> and some improvement possibilities and opened follow up issues to track
> them: JDK-8224180 and JDK-8224181).
> >>
> >> Thanks, Thomas
> >>
> >>
>
>
> --
> - DML
>

From javalists at cbfiddle.com  Wed May 22 15:32:52 2019
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 22 May 2019 08:32:52 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <c891388f-3407-4eba-314a-7d8a1ac14d50@oracle.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>
 <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com>
 <C8F82E77-C1A6-4A7D-A984-8F2B32883620@cbfiddle.com>
 <ef9cde9c-909b-9387-3165-58e62a6bdbcc@gmail.com>
 <387E2F97-B1C6-4C94-973C-6D0CD8F0EE9A@cbfiddle.com>
 <c891388f-3407-4eba-314a-7d8a1ac14d50@oracle.com>
Message-ID: <7FE3BE04-31A2-4790-B488-4B84CDC873EB@cbfiddle.com>

Hi Stuart,

It seems we have one major disagreement. You believe the collections framework specification is inconsistent. I believe it is consistent. (We agree that there is room for improvement.) That disagreement is making communication more difficult.

Based on your reply, I assume the disagreement revolves around this fact:

Using public classes provided by the framework, it is possible to:

* Create an object that is an instance of Set but does not support the general contract of Set.

* Create an object that is an instance of Map but does not support the general contract of Map.

I quoted the relevant paragraphs from the specifications of these classes in my previous message. These paragraphs make it clear that the area where these objects fail to support the general contract of their interfaces is that they define membership in a way that is inconsistent with equals() and hashCode(). The specification goes to some length to explain that membership is based on equals() and hashCode() and that optimizations based on that dependence are permitted.

Obviously, there is a conflict here, but I would not say that the specification itself is inconsistent (which would imply that the specification needs to be ?fixed?).

Instead, I see this as a pragmatic decision (one might say ?kludge?, but that is not the point) by the designers of the framework to allow these concrete classes to be used both to create objects that conform (semantically) to their interfaces and to create objects that do not (fully) conform to their interfaces. The designers could have instead said that the non-conforming uses are erroneous and not supported, which would have been a cleaner solution. Instead, they documented the potential non-conforming cases.

I presume that the non-conforming cases are blessed (not rejected) because they are useful (the classes are described as being well defined either way) and possibly also because conformance is not generally testable.

Having an object that does not conform (semantically) to its interface is an anomaly. It introduces the possibility of unexpected behavior if one does not fully understand the divergence between the object?s behavior and the interface specification and the potential impact of that divergence. This is the sense in which these objects are ?second class? or ?ersatz?. It is not an overstatement or a new idea, it is the plain reading of the current specification.

If you pass one of these objects as a parameter to a method that declares the parameter to be of the interface type, then that method is free to assume that object satisfies the (general contract of the) interface. If the object does not, the method may not behave as expected. If there is a bug, it is in the caller, not the method.

removeAll() is an example of such a method. As its parameter is of type Collection, the framework specification implies that it is a correct implementation to iterate over the parameter, call hashCode() on the elements returned by the iterator, and call equals() only on the target elements with a matching hash, which is what removeAll() currently may do when the target is a HashSet. (The fact that removeAll() uses the sizes of the collections to choose an implementation may be troubling, but that does not imply that either of the two implementations are incorrect. I believe they are both correct. Using your terms, I believe that removeAll(), viewed as a binary operation, is symmetric or reversible in the current specification.)

Does this disagreement over consistency of the specification matter? Perhaps not in practical terms. Even if the current specification is consistent, it is too easy to make mistakes using the above classes. A developer must read the specification carefully and make logical deductions to understand why removeAll() might behave in an unexpected way. That is not a good thing. In addition, whether or not the disputed implementation of removalAll() is strictly a bug, your proposed change to removeAll() is still an incompatible change, both in specification and performance, and needs to be evaluated relative to the benefits of the change. (I assume a CSR is forthcoming to initiate this evaluation formally.)

By the way, I would describe the benefit of your change in practical terms as reducing the probability of programming errors. Improving consistency is vague; it is also problematic if one does not believe that the specification is currently inconsistent.

 Alan



> On May 20, 2019, at 3:57 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> On 5/16/19 10:06 PM, Alan Snyder wrote:
>> Could you explain the inconsistency in the specification that affects removeAll()? I don?t see it.
> 
> It's the assumption that the operation can be reversed without changing its semantics. This isn't true, given the existence of SortedSet et. al. This is the point of this bug report. The inconsistency exists in the collections framework specifications taken as a whole, not removeAll() in isolation.
> 
>> I believe I already accepted the fact of ersatz Collections.
> 
> Of course I don't know your state of mind, but it it doesn't sound to me like you've accepted them. You're calling them "ersatz" collections, which sound to me like "fake" collections. You're carving them out of "real" collections and treating them like second-class citizens. I would have thought that was an overstatement, until I read this:
> 
>> Promoting ersatz Collections to first class citizens would be a significant incompatible change...
> 
> My goal here is to reconcile the various parts of the collections framework specifications so that they are more self-consistent as a whole. Treating certain pieces as second-class citizens makes the problem worse, not better.
> 
>> What I would most like to preserve is the performance advantages of using hash coding, which apparently was a goal of the original design:
>> "implementations of the various Collections Framework interfaces are free to take advantage of the specified behavior of underlying {@link Object} methods wherever the implementor deems it appropriate"
>> Promoting ersatz Collections to first class citizens would be a significant incompatible change to the specification because it invalidates this statement.
> 
> My changes don't affect the relationship of equals() and hashCode() in the slightest.
> 
> s'marks
> 


From javalists at cbfiddle.com  Wed May 22 16:02:58 2019
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 22 May 2019 09:02:58 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <32291cb3-a2e2-b3ba-5396-f6b8c8deb17f@oracle.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>
 <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com>
 <C8F82E77-C1A6-4A7D-A984-8F2B32883620@cbfiddle.com>
 <ef9cde9c-909b-9387-3165-58e62a6bdbcc@gmail.com>
 <32291cb3-a2e2-b3ba-5396-f6b8c8deb17f@oracle.com>
Message-ID: <3BAF7EFF-8229-402E-B8F5-09EA80434313@cbfiddle.com>

For the record, the performance change that concerns me involves the removal of a small number of elements from a large HashSet.

Let?s say I want to remove three elements from a large HashSet.

I could write

target.remove(e1);
target.remove(e2);
target.remove(e3);

or, if the elements were in a collection

target.removeAll(c);

The first case takes advantage of hashing. The parameter elements are hashed and only the elements in the matching bucket are compared (using equals). That makes this an O(1) operation in terms of the size of the target set, assuming it is properly loaded.

One might naively think that the second case performs similarly. In the current implementation it does. In the changed implementation, *all* of the elements of the target set must be examined and tested for being members of the parameter collection. The operation is now O(n), where n is the size of the target set.

This is a huge difference. I?m not sure it makes sense to say that we need to gather data to see how much of a problem this is. Anyone who uses large sets in this manner has had no reason to complain. They will complain only after they start using the new implementation.

  Alan



> On May 20, 2019, at 4:53 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> On 5/16/19 11:48 PM, Peter Levart wrote:
>> As Stuart says, optimizations mustn't change semantics. So is there a possibly narrower optimization, that doesn't change the semantics?
>> Here's a sketch of one:
>> - create a marker interface (could be JDK-internal) and mark all conforming Set implementations with it
>> - use AbstractSet.removeAll optimization only when both collections implement the marker interface
> 
> Hi Peter,
> 
> It's certainly reasonable for there to be some concern over the potential performance loss. I don't particularly like the fact that even as we're improving the semantics, that some programs will suffer a slowdown, even those that aren't actually affected by the semantic issues.
> 
> However, I'm not convinced that we really understand the performance issue. When this was brought up in January, [1] the claim was that this wasted thousands of CPU hours. I'm skeptical. To back this up, in a followup message [2] the original poster linked to a Stack Overflow question [3] that turns out to have been derived from an old article by Jon Skeet [4]. To be sure, this is an interesting technical discussion, but it doesn't count as evidence that this is an actual performance problem.
> 
> If you look at the example closely, it turns out that it calls removeAll() and passes an argument a List with 300,000 elements. If you're doing operations on large lists, maybe you shouldn't be surprised to see a slowdown. Maybe instead you should have been surprised (in the iteration-switched case) that it ran reasonably fast at all.
> 
> Nonetheless it remains a possibility that some code that worked properly and performed reasonably well will suffer a slowdown. One way -- and I stress that this is only one way -- that performance might be improved is to switch the collection upon which iteration is done. The linked bug reports have a bunch of suggestions for doing this, including checking to see whether the argument is a List. To these I'd add the stipulation that, the iteration can be switched if it can be determined that it is *safe* to do so; and the safety depends on whether the two collections use compatible membership semantics.
> 
> Collections that use equals() are compatible with each other; keysets of IdentityHashMap are compatible with each other; SortedSets that use identical comparison methods are compatible with each other. But note, SortedSets that use a comparisons methods that are consistent with equals are also compatible with collections that use equals(). And it seems likely to be undecidable whether two different (!=) comparison methods are in fact compatible.
> 
> In any case it would interesting to try to chew on this notion of compatible membership semantics for a while. It might be difficult to come up with a complete and correct test. It's probably easier to come up with an approximation, like ConcurrentSkipListMap's equals() method. [5] I'm not sure such a discussion would be fruitful, though, until we're sure we understand how much of a performance problem this actually is.
> 
> s'marks
> 
> 
> 
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html
> 
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html
> 
> [3] https://stackoverflow.com/questions/28671903/the-hashsett-removeall-method-is-surprisingly-slow
> 
> [4] https://codeblog.jonskeet.uk/2010/07/29/there-s-a-hole-in-my-abstraction-dear-liza-dear-liza/
> 
> [5] http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java#l1706
> 


From claes.redestad at oracle.com  Wed May 22 17:15:07 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 22 May 2019 19:15:07 +0200
Subject: RFR: 8224202: Speed up Properties.load
In-Reply-To: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>
References: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>
Message-ID: <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com>

Reworked after further analysis:

- swapping out char[] for StringBuilder was only a win for the outgoing
   buffer
- using locals for oft-accessed variables in readLine is a substantial
   interpreter-only optimization[1]
- the skipLF logic can safely be folded into the end-of-line logic,
   thus removing a test from every non-comment character read
- splitting apart the InputStream / Reader removes numerous branches
   and allows some improvements for the common InputStream case - at the
   price of some code duplication

In total, this patch now means we need to execute almost half as much
bytecode to load java.security. In my local tests this means we load
java.security ~1.5-2ms faster.

New webrev: http://cr.openjdk.java.net/~redestad/8224202/open.01/

/Claes

[1] this optimization effort is motivated by startup regressions caused
by loading java.security earlier during bootstrap in some
configurations; the number of property files we load is typically small
and happen early, so optimization focus is thus on making it faster
during bootstrap, i.e., interpreted performance - if we were optimizing
for parsing many property files we'd probably need to restructure the
logic, e.g., splitting out duplicate code into smaller methods etc..


On 2019-05-21 12:22, Claes Redestad wrote:
> Hi,
> 
> a few smaller optimizations for Properties.load:
> 
> - when parsing comment lines, we unnecessarily breaks the fast path loop
> on backslashes, even though a backslash embedded in a comment line will 
> never have any effect on subsequent logical lines
> 
> - inside that same loop, we always do two comparisons in the common 
> case: testing c <= '\r' && c >= '\n' would mean only one comparison in 
> the common case, since c is very likely to be > '\r' (also when reading 
> from a byte stream)
> 
> - we currently store everything into temporary char[]'s which we then
> instantiate Strings with. Since Compact String this means we often
> use more temporary storage than necessary, and do unnecessary work
> packing from char[] to byte[] representation internally; by using
> StringBuilder encoding transitions is handled more gracefully and is a
> speed-up in general (both interpreted and compiled) while simplifying
> the code somewhat.
> 
> Result is ~5-20% faster depending on how comment-heavy the properties
> file we're loading is.
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8224202
> Webrev: http://cr.openjdk.java.net/~redestad/8224202/open.00/
> 
> Testing: tier1-3
> 
> Patch is applied on top of JDK-8224240, patch for which is out for
> review here: 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060301.html
> 
> Thanks!
> 
> /Claes

From Roger.Riggs at oracle.com  Wed May 22 17:36:50 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 May 2019 13:36:50 -0400
Subject: RFR(XS): 8220072: GCC 8.3 reports errors in java.base
In-Reply-To: <62C11EC0-AE63-47F1-9379-38F2E133E385@bell-sw.com>
References: <62C11EC0-AE63-47F1-9379-38F2E133E385@bell-sw.com>
Message-ID: <d0fb2b96-629a-72d1-a441-6ead3a6868e2@oracle.com>

Hi Dmitry,

Looks ok.

Roger


On 05/21/2019 04:24 PM, Dmitry Chuyko wrote:
> Hello,
>
> Please review a small fix for compilation error reported by recent compiler in canonicalize() from canonicalize_md.c. PATH_MAX may be passed as num argument to strncpy() and ?\0? is added to resulting string. The case of too long name is processed at the beginning of canonicalize() so duplicate check is removed.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8220072 <https://bugs.openjdk.java.net/browse/JDK-8220072>
> webrev: http://cr.openjdk.java.net/~dchuyko/8220072/webrev.01/ <http://cr.openjdk.java.net/~dchuyko/8220072/webrev.01/>
> testing: dev-submit mach5-one-dchuyko-JDK-8220072-1-20190521-1536-2605973: PASSED
>
> -Dmitry


From Roger.Riggs at oracle.com  Wed May 22 17:42:40 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 May 2019 13:42:40 -0400
Subject: RFR: JDK-8223914: specification of j.l.c.MethodTypeDesc::of
 should document better the exceptions thrown
In-Reply-To: <fa299489-7444-c3ce-710c-600949d3f74a@oracle.com>
References: <8991ce18-0b54-d0e8-3dcd-6581fde5141b@oracle.com>
 <7520e768-3445-bfbb-5619-8f4d5b5da59a@oracle.com>
 <fa299489-7444-c3ce-710c-600949d3f74a@oracle.com>
Message-ID: <11b805ba-e845-1620-6227-bea189d848f4@oracle.com>

Hi Vicente,

Looks ok.

Roger


On 05/20/2019 03:29 PM, Vicente Romero wrote:
> Hi Roger,
>
> On 5/20/19 2:00 PM, Roger Riggs wrote:
>> Hi Vicente,
>>
>> In the CSR, the Summary should be about the change... 
>> "...MethodTypeDesc::of should document all exceptions.
>> Avoid duplication between Summary and Problem.
>
> thanks, I saw that you already modified the Summary
>>
>> I would omit the part about "content of parameter" or "its contents" 
>> is null;
>> It cannot happen and if it does, its more of an internal error than a 
>> regular NPE
>> since it should not be possible to create a ClassDesc with a null 
>> descriptor string.
>
> this spec comment was included in this one an other similar methods. 
> It is probably a bit of an overkill but we have already changed the 
> spec of several similar methods to this pattern, see for example [1]
Its just a bad to propagate a poor spec as it is to write new bad spec.

>
>>
>> In the Code Review:
>>
>> MethodTypeDesc.java: 68:? as above, "or its contents are" -> "is "? 
>> there's no need to mention the contents.
>>
>> MethodTypeDescTest.java: 264 and 274.? The messages would be more 
>> useful (if they ever were to happen)
>> and for the person reading the code if they describe what should not 
>> happen.
>> For example,? "ClassDesc array should not be null"? or ClassDesc 
>> should not be null.
>
> I made this change in the test comment [2]
>>
>> Thanks, Roger
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223803
> [2] http://cr.openjdk.java.net/~vromero/8223914/webrev.01/
>
>>
>>
>> On 05/17/2019 12:55 PM, Vicente Romero wrote:
>>> Please review simple fix for [1] at [2] plus the CSR at [3]. This 
>>> fix is simply documenting all the missing cases in which method 
>>> java.lang.constant.MethodTypeDesc::of can throw exceptions. A test 
>>> has been added to cover the missing cases.
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8223914
>>> [2] http://cr.openjdk.java.net/~vromero/8223914/webrev.00/
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8224136
>>
>


From alex.buckley at oracle.com  Wed May 22 17:49:29 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 22 May 2019 10:49:29 -0700
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <5CE48771.6030509@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
 <5CE43F5E.1050102@oracle.com>
 <008FA8AC-7CC8-4352-A90F-7B459288F364@oracle.com>
 <5CE48771.6030509@oracle.com>
Message-ID: <5CE58BA9.2090706@oracle.com>

On 5/21/2019 4:19 PM, Alex Buckley wrote:
> On 5/21/2019 2:10 PM, Jim Laskey wrote:
>> Updated version http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02
>
> API spec looks good, but it was a surprise to learn that stripIndent
> performs normalization of line terminators:
>
> "@return string with margins removed and line terminators normalized"
>
> The processing steps in the JEP (and the JLS) are clear that
> normalization happens before incidental white space removal. I realize
> that stripIndent performs separation and joining in such a way as to
> produce a string that looks like it was normalized prior to stripIndent,
> so the @return isn't wrong, but it's still confusing to make a big deal
> of normalization-first only for stripIndent to suggest normalization-last.

Stepping back, normalization is a nice thing for the multi-line-aware 
methods to do, but it's fundamentally just a "finishing touch". By 
mentioning it in the class-level spec as a general policy, we can dial 
back its appearance in stripIndent and indent.

The rest of this mail will appear disjointed, but put it all together in 
the javadoc (and imagine the class-level spec explains the goals of 
normalization) and it'll look nice. There are some tone changes below to 
make the method descriptions stop talking about what's "returned" and 
instead flow into the @return.


For stripIndent, bearing in mind that "margins" is no longer in the 
method summary:

@return a string with no incidental white space and with line 
terminators normalized

Description:

First, the individual lines of this string are extracted as if by using 
lines().  [If we're going to lean on lines(), then take its concept of 
extraction, rather than "conceptually separating" things. In the JLS I 
would say "as if by the execution of lines()" but the informal "using" 
phrase is fine for popular javadoc.]
...
Finally, the lines are joined into a new string, using the LF character 
(U+000A) to separate lines.  [The last clause is carefully chosen. We 
don't want to speak of a "line separator" because we already have "line 
terminator". We don't want to say "using the LF character to terminate 
lines" because joining embodies separation, not termination; see the 
@param of `join`.]


For indent, greater readability and consistency:

-----
public String indent?(int n)

Adjusts the indentation of each line of this string based on the value of n.

The individual lines of this string are extracted as if by using 
lines(). Each line is adjusted as described below, then all the adjusted 
lines are joined into a new string, using the LF character (U+000A) to 
separate lines.

If n > 0 ...
If n < 0 ...
If n == 0 ...

Returns:
     a string with indentation adjusted and line terminators normalized
-----


Finally, looking at lines: "Returns a stream of lines extracted from 
this string, separated by line terminators." makes it sound like the 
stream includes a line terminator element after every line element. The 
separation happened during the extraction, not the streaming. Recommend: 
  "Returns a stream of lines extracted from this string, split at line 
terminators."

Alex

From andrew_m_leonard at uk.ibm.com  Wed May 22 18:06:29 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Wed, 22 May 2019 19:06:29 +0100
Subject: How to identify prioritized bugs/enhancements needing working on?
Message-ID: <OFE02707A3.79F520CA-ON80258402.0060E460-80258402.0063783C@notes.na.collabserv.com>

Hi,
I'm currently looking through the "bugs" database to see what 
issues/enhancements I can help out with.. but struggling a bit to find a 
clear list of what looks like a suitably prioritized bug/enhancement to 
work on.
How best could I view what should be looked at for the upcoming releases? 
or is it just sort by P1/2/3/4 and a "pick what looks interesting/doable" 
approach?
Generally looking in this maillist at what bugs are being fixed currently, 
it seems generally bugs are newly raised for whatever jep/feature happened 
to be being worked on, and not a lot of the older backlog?
Any guidance pointing me at where I can concentrate my efforts to 
contribute would be much appreciated.
Many Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From Roger.Riggs at oracle.com  Wed May 22 18:09:06 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 22 May 2019 14:09:06 -0400
Subject: RFR: 8224202: Speed up Properties.load
In-Reply-To: <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com>
References: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>
 <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com>
Message-ID: <94d45c5b-b09e-1c25-80e7-b7bbdad0ea93@oracle.com>

Hi Claes,

Properties.java: 542-547, 636-639 you might find the function Ivan added 
useful:
 ??????? newlen =? ArraySupport.newLength(oldlength, min, preferred);

Can it be refactored differently to read the bytes into a char array and
then process that to avoid the processing code duplication.

If not, can you put the two byte and char versions of readLine in 
separate methods,
That massive if..else is ugly. Not sharing most of the code doing the 
same things is quite ugly too.

Roger


On 05/22/2019 01:15 PM, Claes Redestad wrote:
> Reworked after further analysis:
>
> - swapping out char[] for StringBuilder was only a win for the outgoing
> ? buffer
> - using locals for oft-accessed variables in readLine is a substantial
> ? interpreter-only optimization[1]
> - the skipLF logic can safely be folded into the end-of-line logic,
> ? thus removing a test from every non-comment character read
> - splitting apart the InputStream / Reader removes numerous branches
> ? and allows some improvements for the common InputStream case - at the
> ? price of some code duplication
>
> In total, this patch now means we need to execute almost half as much
> bytecode to load java.security. In my local tests this means we load
> java.security ~1.5-2ms faster.
>
> New webrev: http://cr.openjdk.java.net/~redestad/8224202/open.01/
>
> /Claes
>
> [1] this optimization effort is motivated by startup regressions caused
> by loading java.security earlier during bootstrap in some
> configurations; the number of property files we load is typically small
> and happen early, so optimization focus is thus on making it faster
> during bootstrap, i.e., interpreted performance - if we were optimizing
> for parsing many property files we'd probably need to restructure the
> logic, e.g., splitting out duplicate code into smaller methods etc..
>
>
> On 2019-05-21 12:22, Claes Redestad wrote:
>> Hi,
>>
>> a few smaller optimizations for Properties.load:
>>
>> - when parsing comment lines, we unnecessarily breaks the fast path loop
>> on backslashes, even though a backslash embedded in a comment line 
>> will never have any effect on subsequent logical lines
>>
>> - inside that same loop, we always do two comparisons in the common 
>> case: testing c <= '\r' && c >= '\n' would mean only one comparison 
>> in the common case, since c is very likely to be > '\r' (also when 
>> reading from a byte stream)
>>
>> - we currently store everything into temporary char[]'s which we then
>> instantiate Strings with. Since Compact String this means we often
>> use more temporary storage than necessary, and do unnecessary work
>> packing from char[] to byte[] representation internally; by using
>> StringBuilder encoding transitions is handled more gracefully and is a
>> speed-up in general (both interpreted and compiled) while simplifying
>> the code somewhat.
>>
>> Result is ~5-20% faster depending on how comment-heavy the properties
>> file we're loading is.
>>
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8224202
>> Webrev: http://cr.openjdk.java.net/~redestad/8224202/open.00/
>>
>> Testing: tier1-3
>>
>> Patch is applied on top of JDK-8224240, patch for which is out for
>> review here: 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060301.html
>>
>> Thanks!
>>
>> /Claes


From dmitry.chuyko at bell-sw.com  Wed May 22 18:38:37 2019
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Wed, 22 May 2019 21:38:37 +0300
Subject: RFR(XS): 8220072: GCC 8.3 reports errors in java.base
In-Reply-To: <d0fb2b96-629a-72d1-a441-6ead3a6868e2@oracle.com>
References: <62C11EC0-AE63-47F1-9379-38F2E133E385@bell-sw.com>
 <d0fb2b96-629a-72d1-a441-6ead3a6868e2@oracle.com>
Message-ID: <6c59de22-4a1b-3615-c19b-69a870c0a8f7@bell-sw.com>

Thanks for the review, pushed with copyright update.

-Dmitry

On 5/22/19 8:36 PM, Roger Riggs wrote:
> Hi Dmitry,
>
> Looks ok.
>
> Roger
>
>
> On 05/21/2019 04:24 PM, Dmitry Chuyko wrote:
>> Hello,
>>
>> Please review a small fix for compilation error reported by recent 
>> compiler in canonicalize() from canonicalize_md.c. PATH_MAX may be 
>> passed as num argument to strncpy() and ?\0? is added to resulting 
>> string. The case of too long name is processed at the beginning of 
>> canonicalize() so duplicate check is removed.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8220072 
>> <https://bugs.openjdk.java.net/browse/JDK-8220072>
>> webrev: http://cr.openjdk.java.net/~dchuyko/8220072/webrev.01/ 
>> <http://cr.openjdk.java.net/~dchuyko/8220072/webrev.01/>
>> testing: dev-submit 
>> mach5-one-dchuyko-JDK-8220072-1-20190521-1536-2605973: PASSED
>>
>> -Dmitry
>

From claes.redestad at oracle.com  Wed May 22 22:19:35 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 23 May 2019 00:19:35 +0200
Subject: RFR: 8224202: Speed up Properties.load
In-Reply-To: <94d45c5b-b09e-1c25-80e7-b7bbdad0ea93@oracle.com>
References: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>
 <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com>
 <94d45c5b-b09e-1c25-80e7-b7bbdad0ea93@oracle.com>
Message-ID: <e46abefb-32d4-27be-2b68-7cb697fc6770@oracle.com>

Hi Roger,

On 2019-05-22 20:09, Roger Riggs wrote:
> Hi Claes,
> 
> Properties.java: 542-547, 636-639 you might find the function Ivan added 
> useful:
>  ??????? newlen =? ArraySupport.newLength(oldlength, min, preferred);

good suggestion - this is a slow path that we don't hit in any of the
startup tests I'm concerned with, so let's use that.

> 
> Can it be refactored differently to read the bytes into a char array and
> then process that to avoid the processing code duplication.

.. not without a slowdown.

> 
> If not, can you put the two byte and char versions of readLine in 
> separate methods,
> That massive if..else is ugly. Not sharing most of the code doing the 
> same things is quite ugly too.

... let's take a step back from that particular ugliness. :-)

http://cr.openjdk.java.net/~redestad/8224202/open.02/

- Joined stream/reader code paths back together
- Consume comment lines completely - reading new data from
   stream/reader if we need to - removes the need for the
   isCommentLine control variable
- Realized isNewLine is true iff len == 0, so it can be removed

This ends up being almost exactly as fast as open.01, with much
less code duplication. The break-to-label is unfortunate, of course.

/Claes

From naoto.sato at oracle.com  Wed May 22 22:26:08 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 22 May 2019 15:26:08 -0700
Subject: [13] RFR: 8221431: Support for Unicode 12.1
Message-ID: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com>

Hi,

Please review the changes to the following issue:

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

The proposed CSR and changeset are located at:

https://bugs.openjdk.java.net/browse/JDK-8222771
https://cr.openjdk.java.net/~naoto/8221431/webrev.03/

This enhancement incorporates support for the recently released Unicode 
version 12.1. Besides the usual addition of new characters/scripts, this 
enhancement includes normalization of the Japanese Reiwa era character 
(U+32FF), and up-to-date extended grapheme cluster support in regex package.

Naoto

From naoto.sato at oracle.com  Wed May 22 22:56:19 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 22 May 2019 15:56:19 -0700
Subject: [13] RFR: 8221431: Support for Unicode 12.1
In-Reply-To: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com>
References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com>
Message-ID: <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com>

Adding build-dev, as the change adds a small build tool to parse emoji-data.

Naoto

On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote:
> Hi,
> 
> Please review the changes to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8221431
> 
> The proposed CSR and changeset are located at:
> 
> https://bugs.openjdk.java.net/browse/JDK-8222771
> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/
> 
> This enhancement incorporates support for the recently released Unicode 
> version 12.1. Besides the usual addition of new characters/scripts, this 
> enhancement includes normalization of the Japanese Reiwa era character 
> (U+32FF), and up-to-date extended grapheme cluster support in regex 
> package.
> 
> Naoto

From erik.joelsson at oracle.com  Wed May 22 23:13:32 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 22 May 2019 16:13:32 -0700
Subject: [13] RFR: 8221431: Support for Unicode 12.1
In-Reply-To: <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com>
References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com>
 <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com>
Message-ID: <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com>

Hello Naoto,

In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the double 
$$. I would recommend calling the newer MakeTargetDir macro instead. It 
doesn't take an argument.

Otherwise build changes look good.

/Erik

On 2019-05-22 15:56, naoto.sato at oracle.com wrote:
> Adding build-dev, as the change adds a small build tool to parse 
> emoji-data.
>
> Naoto
>
> On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the changes to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8221431
>>
>> The proposed CSR and changeset are located at:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8222771
>> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/
>>
>> This enhancement incorporates support for the recently released 
>> Unicode version 12.1. Besides the usual addition of new 
>> characters/scripts, this enhancement includes normalization of the 
>> Japanese Reiwa era character (U+32FF), and up-to-date extended 
>> grapheme cluster support in regex package.
>>
>> Naoto

From ivan.gerasimov at oracle.com  Thu May 23 00:11:44 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 22 May 2019 17:11:44 -0700
Subject: RFR: 8224202: Speed up Properties.load
In-Reply-To: <e46abefb-32d4-27be-2b68-7cb697fc6770@oracle.com>
References: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>
 <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com>
 <94d45c5b-b09e-1c25-80e7-b7bbdad0ea93@oracle.com>
 <e46abefb-32d4-27be-2b68-7cb697fc6770@oracle.com>
Message-ID: <97ce78c1-9c14-7309-1a14-db5f6da8f6b6@oracle.com>

Hi Claes!

A few comments:

1)

  571                     if (len == lineBuf.length) {
  572                         int newLength = 
ArraysSupport.newLength(lineBuf.length, 1, lineBuf.length);

could be written slightly shorter as

  571                     if (len == lineBuf.length) {
  572                         int newLength = 
ArraysSupport.newLength(len, 1, len);

2)
  585                     if (len == 0) {
  586                         skipWhiteSpace = true;
  587                         len = 0;

no need to update len here

3)
In loadConvert(char[] in, int off, int len, StringBuilder out):

It may make sense to first scan the input buffer for backslash, and if 
not found (should be a common case), return new String(in, off, len), so 
a copying to the StringBuilder will be avoided.

Otherwise:
     out.append(in, off, posOfSlash - off);
     off = posOfSlash;

and continue as before...

With kind regards,
Ivan


On 5/22/19 3:19 PM, Claes Redestad wrote:
> Hi Roger,
>
> On 2019-05-22 20:09, Roger Riggs wrote:
>> Hi Claes,
>>
>> Properties.java: 542-547, 636-639 you might find the function Ivan 
>> added useful:
>>          newlen =  ArraySupport.newLength(oldlength, min, preferred);
>
> good suggestion - this is a slow path that we don't hit in any of the
> startup tests I'm concerned with, so let's use that.
>
>>
>> Can it be refactored differently to read the bytes into a char array and
>> then process that to avoid the processing code duplication.
>
> .. not without a slowdown.
>
>>
>> If not, can you put the two byte and char versions of readLine in 
>> separate methods,
>> That massive if..else is ugly. Not sharing most of the code doing the 
>> same things is quite ugly too.
>
> ... let's take a step back from that particular ugliness. :-)
>
> http://cr.openjdk.java.net/~redestad/8224202/open.02/
>
> - Joined stream/reader code paths back together
> - Consume comment lines completely - reading new data from
>   stream/reader if we need to - removes the need for the
>   isCommentLine control variable
> - Realized isNewLine is true iff len == 0, so it can be removed
>
> This ends up being almost exactly as fast as open.01, with much
> less code duplication. The break-to-label is unfortunate, of course.
>
> /Claes
>

-- 
With kind regards,
Ivan Gerasimov


From amalloy at google.com  Thu May 23 00:42:59 2019
From: amalloy at google.com (Alan Malloy)
Date: Wed, 22 May 2019 17:42:59 -0700
Subject: RFR: 8224629: Unnecessary indirection in LambdaToMethod
Message-ID: <CAC1Wh8Hj9VzkVAwbiMowJk9J9MK2aHaRa4730mixHre9PZCeoQ@mail.gmail.com>

Hello. Please review this patch to eliminate an unnecessary upcast and
method call in LambdaToMethod.

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

Testing: All of jtreg:test/langtools/tools/javac pass locally. No new test
added, as no behavior change is intended.

Thanks,
    Alan

From david.holmes at oracle.com  Thu May 23 00:47:29 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 May 2019 10:47:29 +1000
Subject: RFR: 8224629: Unnecessary indirection in LambdaToMethod
In-Reply-To: <CAC1Wh8Hj9VzkVAwbiMowJk9J9MK2aHaRa4730mixHre9PZCeoQ@mail.gmail.com>
References: <CAC1Wh8Hj9VzkVAwbiMowJk9J9MK2aHaRa4730mixHre9PZCeoQ@mail.gmail.com>
Message-ID: <265f5495-8ee1-f8b0-e021-f60589c07124@oracle.com>

Hi Alan,

This javac change should be reviewed on compiler-dev not core-libs-dev.

Thanks,
David

On 23/05/2019 10:42 am, Alan Malloy wrote:
> Hello. Please review this patch to eliminate an unnecessary upcast and
> method call in LambdaToMethod.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8224629
> webrev: http://cr.openjdk.java.net/~cushon/8224629/webrev.00/
> 
> Testing: All of jtreg:test/langtools/tools/javac pass locally. No new test
> added, as no behavior change is intended.
> 
> Thanks,
>      Alan
> 

From amalloy at google.com  Thu May 23 00:48:19 2019
From: amalloy at google.com (Alan Malloy)
Date: Wed, 22 May 2019 17:48:19 -0700
Subject: RFR: 8224629: Unnecessary indirection in LambdaToMethod
In-Reply-To: <265f5495-8ee1-f8b0-e021-f60589c07124@oracle.com>
References: <CAC1Wh8Hj9VzkVAwbiMowJk9J9MK2aHaRa4730mixHre9PZCeoQ@mail.gmail.com>
 <265f5495-8ee1-f8b0-e021-f60589c07124@oracle.com>
Message-ID: <CAC1Wh8HAJ+3aQCqQNsq8-OD5y5bF-285jWHQdNP2W==fiDGgAA@mail.gmail.com>

Ah, of course. Thanks, will do.

On Wed, May 22, 2019 at 5:47 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Alan,
>
> This javac change should be reviewed on compiler-dev not core-libs-dev.
>
> Thanks,
> David
>
> On 23/05/2019 10:42 am, Alan Malloy wrote:
> > Hello. Please review this patch to eliminate an unnecessary upcast and
> > method call in LambdaToMethod.
> >
> > bug: https://bugs.openjdk.java.net/browse/JDK-8224629
> > webrev: http://cr.openjdk.java.net/~cushon/8224629/webrev.00/
> >
> > Testing: All of jtreg:test/langtools/tools/javac pass locally. No new
> test
> > added, as no behavior change is intended.
> >
> > Thanks,
> >      Alan
> >
>

From henry.jen at oracle.com  Thu May 23 01:07:55 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 22 May 2019 18:07:55 -0700
Subject: RFR: 8215156: Deprecate the -Xfuture option
Message-ID: <DBBC5028-DC6D-4704-ABD8-D8284AD7F3ED@oracle.com>

Hi,

Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2].

Cheers,
Henry
 
[1] https://cr.openjdk.java.net/~henryjen/jdk13/8215156/open/webrev/
[2] https://bugs.openjdk.java.net/browse/JDK-8224524

From david.holmes at oracle.com  Thu May 23 01:34:47 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 May 2019 11:34:47 +1000
Subject: RFR: 8215156: Deprecate the -Xfuture option
In-Reply-To: <DBBC5028-DC6D-4704-ABD8-D8284AD7F3ED@oracle.com>
References: <DBBC5028-DC6D-4704-ABD8-D8284AD7F3ED@oracle.com>
Message-ID: <37f69dc9-9256-e575-9003-c3f294410427@oracle.com>

Hi Henry,

On 23/05/2019 11:07 am, Henry Jen wrote:
> Hi,
> 
> Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2].

src/hotspot/share/Xusage.txt

Ignoring the usefulness, or otherwise of this file, the entry for 
Xfuture should not be deleted (that happens when an option is actually 
removed) but just have "(deprecated)" added to it.

---

In hotspot we include the version of the JDK that deprecated the option:

"Option %s was deprecated in version %s and will likely be removed in a 
future release."

Perhaps you could do the same for the launcher?

Otherwise seems fine.

Thanks,
David
-----

> Cheers,
> Henry
>   
> [1] https://cr.openjdk.java.net/~henryjen/jdk13/8215156/open/webrev/
> [2] https://bugs.openjdk.java.net/browse/JDK-8224524
> 

From naoto.sato at oracle.com  Thu May 23 01:36:40 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 22 May 2019 18:36:40 -0700
Subject: [13] RFR: 8221431: Support for Unicode 12.1
In-Reply-To: <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com>
References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com>
 <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com>
 <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com>
Message-ID: <d6ac40eb-09b9-7b64-d07c-cce8773e2d9f@oracle.com>

Hi Erik,

Thank you for your comments. Updated the webrev accordingly:

https://cr.openjdk.java.net/~naoto/8221431/webrev.04/

Naoto

On 5/22/19 4:13 PM, Erik Joelsson wrote:
> Hello Naoto,
> 
> In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the double 
> $$. I would recommend calling the newer MakeTargetDir macro instead. It 
> doesn't take an argument.
> 
> Otherwise build changes look good.
> 
> /Erik
> 
> On 2019-05-22 15:56, naoto.sato at oracle.com wrote:
>> Adding build-dev, as the change adds a small build tool to parse 
>> emoji-data.
>>
>> Naoto
>>
>> On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the changes to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8221431
>>>
>>> The proposed CSR and changeset are located at:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8222771
>>> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/
>>>
>>> This enhancement incorporates support for the recently released 
>>> Unicode version 12.1. Besides the usual addition of new 
>>> characters/scripts, this enhancement includes normalization of the 
>>> Japanese Reiwa era character (U+32FF), and up-to-date extended 
>>> grapheme cluster support in regex package.
>>>
>>> Naoto

From henry.jen at oracle.com  Thu May 23 01:56:51 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 22 May 2019 18:56:51 -0700
Subject: RFR: 8215156: Deprecate the -Xfuture option
In-Reply-To: <37f69dc9-9256-e575-9003-c3f294410427@oracle.com>
References: <DBBC5028-DC6D-4704-ABD8-D8284AD7F3ED@oracle.com>
 <37f69dc9-9256-e575-9003-c3f294410427@oracle.com>
Message-ID: <332CCF4C-9DAA-4A7A-94B9-052204F1FA54@oracle.com>

Thanks for the quick review,

> On May 22, 2019, at 6:34 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Henry,
> 
> On 23/05/2019 11:07 am, Henry Jen wrote:
>> Hi,
>> Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2].
> 
> src/hotspot/share/Xusage.txt
> 
> Ignoring the usefulness, or otherwise of this file, the entry for Xfuture should not be deleted (that happens when an option is actually removed) but just have "(deprecated)" added to it.
> 

I was wondering if I should prefix (deprecated) or append to the content. It make the line over the 80 so I decided just remove it since this document is not official we don?t want to advocate that option any more.

So, we have couple options,


     -Xfuture          enable strictest checks, anticipating future default
                       (deprecated)
     -Xrs              reduce use of OS signals by Java/VM (see documentation)

or 

    -Xfuture          enable strictest checks (deprecated)

or 

    -Xfuture          (deprecated)
                      enable strictest checks, anticipating future default

or keep in one line don?t mind the 80 width.

Let me know which do we prefer.

> ---
> 
> In hotspot we include the version of the JDK that deprecated the option:
> 
> "Option %s was deprecated in version %s and will likely be removed in a future release."
> 
> Perhaps you could do the same for the launcher?
> 

During the CSR discussion, we asked Dr Deprecator?s opinion and decided on 
?XXX is deprecated and may be removed in a future release.?

It was suggested to change JVM message to match.

Cheers,
Henry

> Otherwise seems fine.
> 
> Thanks,
> David
> -----
> 
>> Cheers,
>> Henry
>>  [1] https://cr.openjdk.java.net/~henryjen/jdk13/8215156/open/webrev/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8224524


From david.holmes at oracle.com  Thu May 23 02:04:32 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 May 2019 12:04:32 +1000
Subject: RFR: 8215156: Deprecate the -Xfuture option
In-Reply-To: <332CCF4C-9DAA-4A7A-94B9-052204F1FA54@oracle.com>
References: <DBBC5028-DC6D-4704-ABD8-D8284AD7F3ED@oracle.com>
 <37f69dc9-9256-e575-9003-c3f294410427@oracle.com>
 <332CCF4C-9DAA-4A7A-94B9-052204F1FA54@oracle.com>
Message-ID: <71e1a4c5-2f3d-ef99-d82c-d7ad68617028@oracle.com>

On 23/05/2019 11:56 am, Henry Jen wrote:
> Thanks for the quick review,
> 
>> On May 22, 2019, at 6:34 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Henry,
>>
>> On 23/05/2019 11:07 am, Henry Jen wrote:
>>> Hi,
>>> Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2].
>>
>> src/hotspot/share/Xusage.txt
>>
>> Ignoring the usefulness, or otherwise of this file, the entry for Xfuture should not be deleted (that happens when an option is actually removed) but just have "(deprecated)" added to it.
>>
> 
> I was wondering if I should prefix (deprecated) or append to the content. It make the line over the 80 so I decided just remove it since this document is not official we don?t want to advocate that option any more.
> 
> So, we have couple options,
> 
> 
>       -Xfuture          enable strictest checks, anticipating future default
>                         (deprecated)
>       -Xrs              reduce use of OS signals by Java/VM (see documentation)

I prefer option 1.

> or
> 
>      -Xfuture          enable strictest checks (deprecated)
> 
> or
> 
>      -Xfuture          (deprecated)
>                        enable strictest checks, anticipating future default
> 
> or keep in one line don?t mind the 80 width.
> 
> Let me know which do we prefer.
> 
>> ---
>>
>> In hotspot we include the version of the JDK that deprecated the option:
>>
>> "Option %s was deprecated in version %s and will likely be removed in a future release."
>>
>> Perhaps you could do the same for the launcher?
>>
> 
> During the CSR discussion, we asked Dr Deprecator?s opinion and decided on
> ?XXX is deprecated and may be removed in a future release.?
> 
> It was suggested to change JVM message to match.

Okay.

Thanks,
David

> Cheers,
> Henry
> 
>> Otherwise seems fine.
>>
>> Thanks,
>> David
>> -----
>>
>>> Cheers,
>>> Henry
>>>   [1] https://cr.openjdk.java.net/~henryjen/jdk13/8215156/open/webrev/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8224524
> 

From henry.jen at oracle.com  Thu May 23 02:44:19 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 22 May 2019 19:44:19 -0700
Subject: RFR: 8215156: Deprecate the -Xfuture option
In-Reply-To: <71e1a4c5-2f3d-ef99-d82c-d7ad68617028@oracle.com>
References: <DBBC5028-DC6D-4704-ABD8-D8284AD7F3ED@oracle.com>
 <37f69dc9-9256-e575-9003-c3f294410427@oracle.com>
 <332CCF4C-9DAA-4A7A-94B9-052204F1FA54@oracle.com>
 <71e1a4c5-2f3d-ef99-d82c-d7ad68617028@oracle.com>
Message-ID: <8F3B3DF5-0525-4DE0-88E3-0A7151ECC246@oracle.com>


> On May 22, 2019, at 7:04 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 23/05/2019 11:56 am, Henry Jen wrote:
>> Thanks for the quick review,
>>> On May 22, 2019, at 6:34 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Henry,
>>> 
>>> On 23/05/2019 11:07 am, Henry Jen wrote:
>>>> Hi,
>>>> Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2].
>>> 
>>> src/hotspot/share/Xusage.txt
>>> 
>>> Ignoring the usefulness, or otherwise of this file, the entry for Xfuture should not be deleted (that happens when an option is actually removed) but just have "(deprecated)" added to it.
>>> 
>> I was wondering if I should prefix (deprecated) or append to the content. It make the line over the 80 so I decided just remove it since this document is not official we don?t want to advocate that option any more.
>> So, we have couple options,
>>      -Xfuture          enable strictest checks, anticipating future default
>>                        (deprecated)
>>      -Xrs              reduce use of OS signals by Java/VM (see documentation)
> 
> I prefer option 1.
> 

OK, updated[1].

[1] https://cr.openjdk.java.net/~henryjen/jdk13/8215156/open/1/webrev/

Cheers,
Henry


From david.holmes at oracle.com  Thu May 23 03:20:04 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 May 2019 13:20:04 +1000
Subject: RFR: 8215156: Deprecate the -Xfuture option
In-Reply-To: <8F3B3DF5-0525-4DE0-88E3-0A7151ECC246@oracle.com>
References: <DBBC5028-DC6D-4704-ABD8-D8284AD7F3ED@oracle.com>
 <37f69dc9-9256-e575-9003-c3f294410427@oracle.com>
 <332CCF4C-9DAA-4A7A-94B9-052204F1FA54@oracle.com>
 <71e1a4c5-2f3d-ef99-d82c-d7ad68617028@oracle.com>
 <8F3B3DF5-0525-4DE0-88E3-0A7151ECC246@oracle.com>
Message-ID: <9c051b8e-db36-dfad-34e1-b7a3854c04f1@oracle.com>

Looks good.

Thanks,
David

On 23/05/2019 12:44 pm, Henry Jen wrote:
> 
>> On May 22, 2019, at 7:04 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 23/05/2019 11:56 am, Henry Jen wrote:
>>> Thanks for the quick review,
>>>> On May 22, 2019, at 6:34 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Henry,
>>>>
>>>> On 23/05/2019 11:07 am, Henry Jen wrote:
>>>>> Hi,
>>>>> Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2].
>>>>
>>>> src/hotspot/share/Xusage.txt
>>>>
>>>> Ignoring the usefulness, or otherwise of this file, the entry for Xfuture should not be deleted (that happens when an option is actually removed) but just have "(deprecated)" added to it.
>>>>
>>> I was wondering if I should prefix (deprecated) or append to the content. It make the line over the 80 so I decided just remove it since this document is not official we don?t want to advocate that option any more.
>>> So, we have couple options,
>>>       -Xfuture          enable strictest checks, anticipating future default
>>>                         (deprecated)
>>>       -Xrs              reduce use of OS signals by Java/VM (see documentation)
>>
>> I prefer option 1.
>>
> 
> OK, updated[1].
> 
> [1] https://cr.openjdk.java.net/~henryjen/jdk13/8215156/open/1/webrev/
> 
> Cheers,
> Henry
> 

From christoph.langer at sap.com  Thu May 23 07:41:17 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 23 May 2019 07:41:17 +0000
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <DB7PR02MB51937A87EECD7D1E01F71D098A070@DB7PR02MB5193.eurprd02.prod.outlook.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <fd756aff51134b15a40fe55247d4a87e@sap.com>
 <CA+3eh13dP-tCdq4H4z3KWJZQzfMJYqDNkx9fMh3tNfL08RCtDg@mail.gmail.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <a3e64312-d902-b751-d55d-0af1c4c6e3c5@oracle.com>
 <953449f0913340f6a94ae3d83611fd92@sap.com>
 <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>
 <HE1PR0201MB2266326D98F5119796990BFC8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
 <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <fad24c8f-aa40-821e-fa15-9cbe32b0eb76@oracle.com>
 <DB7PR02MB51937A87EECD7D1E01F71D098A070@DB7PR02MB5193.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB5192FA14961F3A1C24E502DA8A010@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

here is a little update to my latest webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.11/

I had to make modifications to fix test errors and enhance testing:
a) in initOwner/initGroup the UOE has to be catched and handled explicitly as it is never wrapped into PAE because it is a RuntimeException.
b) updated the test to expect the zip file's group as default group
c) added a sanity check to read and extract a zip file created by zipfs with posix permissions set via java.util.zip.ZipFile

Best regards
Christoph


> -----Original Message-----
> From: Langer, Christoph
> Sent: Dienstag, 21. Mai 2019 17:24
> To: Alan Bateman <Alan.Bateman at oracle.com>
> Cc: nio-dev <nio-dev at openjdk.java.net>; Java Core Libs <core-libs-
> dev at openjdk.java.net>
> Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions
> 
> Hi Alan,
> 
> Thank you for your comments. Here comes the next update... increasing the
> turnaround time a little bit ??
> 
> http://cr.openjdk.java.net/~clanger/webrevs/8213031.10/
> 
> 
> > Thanks. I think you've addressed most of my points. The only thing that
> > isn't clear is the group owner as I thought we had converged on using
> > the zip file's group owner.? If I read the code correctly then it uses
> > the file owner (and makes the assumption that defaultOwner is
> > initialized before initGroup is called).
> 
> Ok, makes sense. I've updated the coding such that the zip's file owner
> would be the default owner, in case it can be retrieved.
> 
> > In passing, the name of the PosixFileAttributeView implementation should
> > probably be ZipPosixFileAttributeView rather than
> > ZipFilePosixAttributeViewPosix. Also EntryPosix extends Entry, should
> > probably be PosixEntry. Not important as these are internal but noticed
> > them when scanning the changes.
> 
> I changed the class names, hopefully to your liking.
> 
> > Also in passing, there are several places using
> > AccessController.doPrivileged that are bit ugly due to the casting. The
> > doPrivileged methods are awkward to use with lambda expressions (not
> > your doing) but one approach that I find readable is to separate the
> > creation of the action, e.g. file the zip file owner it could be:
> >
> > PrivilegedExceptionAction<UserPrincipal> pa = () ->
> Files.getOwner(zfpath);
> > return AccessController.doPrivileged(pa).
> 
> I updated these places. Seems more readable indeed.
> 
> > In the same area, the code in initOwner catches UOE but that will always
> > be wrapped in PAE.
> 
> Fixed.
> 
> > > I have updated module-info a little bit to reflect the latest changes. Is it
> > now time to focus on the CSR?
> > >
> > The "For extended POSIX support ..." paragraph has the property name
> > from a previous iteration so I assume you'll update that. I think it
> > would be using to put quotes around the names too. It also specifies the
> > fallback group owner to be the file owner but I think we converged on
> > use the zip file's group owner where possible.
> >
> > A small bit of word smiting required but I think this is really close to
> > writing the CSR.
> 
> I have updated the doc in module-info.java quite a bit. Please check.
> 
> Is it time to work on the CSR now? How shall we proceed there?
> 
> Thanks
> Christoph


From daniel.fuchs at oracle.com  Thu May 23 09:32:38 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 23 May 2019 10:32:38 +0100
Subject: RFR: 8224656: Problem list
 java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed
Message-ID: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>

Hi,

Please find a patch below that temporarily problem lists
java/security/SecureClassLoader/DefineClass.java
on linux and windows until JDK-8224635 [1] is fixed:

8224656: Problem list java/security/SecureClassLoader/DefineClass.java
          until JDK-8224635 is fixed
https://bugs.openjdk.java.net/browse/JDK-8224656

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/

best regards

-- daniel

diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -664,6 +664,7 @@
  sun/security/provider/KeyStore/DKSTest.sh 
8180266 windows-all

  sun/security/pkcs11/KeyStore/SecretKeysBasic.sh 
8209398 generic-all
+java/security/SecureClassLoader/DefineClass.java                8224635 
windows-all,linux-all

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


From david.holmes at oracle.com  Thu May 23 09:40:11 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 May 2019 19:40:11 +1000
Subject: RFR: 8224656: Problem list
 java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed
In-Reply-To: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
Message-ID: <10b2ec3d-ebce-2e50-ebc3-e8fcc001b791@oracle.com>

Looks good! Thanks Daniel.

David

On 23/05/2019 7:32 pm, Daniel Fuchs wrote:
> Hi,
> 
> Please find a patch below that temporarily problem lists
> java/security/SecureClassLoader/DefineClass.java
> on linux and windows until JDK-8224635 [1] is fixed:
> 
> 8224656: Problem list java/security/SecureClassLoader/DefineClass.java
>  ???????? until JDK-8224635 is fixed
> https://bugs.openjdk.java.net/browse/JDK-8224656
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/
> 
> best regards
> 
> -- daniel
> 
> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -664,6 +664,7 @@
>  ?sun/security/provider/KeyStore/DKSTest.sh 8180266 windows-all
> 
>  ?sun/security/pkcs11/KeyStore/SecretKeysBasic.sh 8209398 generic-all
> +java/security/SecureClassLoader/DefineClass.java??????????????? 8224635 
> windows-all,linux-all
> 
> 
> ############################################################################ 
> 
> 

From Alan.Bateman at oracle.com  Thu May 23 09:39:47 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 May 2019 10:39:47 +0100
Subject: RFR: 8224656: Problem list
 java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed
In-Reply-To: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
Message-ID: <d6d88597-7990-d175-aff1-44df7d7fe31f@oracle.com>

On 23/05/2019 10:32, Daniel Fuchs wrote:
> Hi,
>
> Please find a patch below that temporarily problem lists
> java/security/SecureClassLoader/DefineClass.java
> on linux and windows until JDK-8224635 [1] is fixed:
>
> 8224656: Problem list java/security/SecureClassLoader/DefineClass.java
> ???????? until JDK-8224635 is fixed
> https://bugs.openjdk.java.net/browse/JDK-8224656
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/
Looks fine.

From chris.hegarty at oracle.com  Thu May 23 09:40:58 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 23 May 2019 10:40:58 +0100
Subject: RFR: 8224656: Problem list
 java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed
In-Reply-To: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
References: <59bd3b92-e04d-b28b-9090-6961fb94439e@oracle.com>
Message-ID: <7AB30D9D-23D0-407A-8D7A-2130F0237475@oracle.com>

Daniel,

> On 23 May 2019, at 10:32, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find a patch below that temporarily problem lists
> java/security/SecureClassLoader/DefineClass.java
> on linux and windows until JDK-8224635 [1] is fixed:
> 
> 8224656: Problem list java/security/SecureClassLoader/DefineClass.java
>         until JDK-8224635 is fixed
> https://bugs.openjdk.java.net/browse/JDK-8224656
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.00/
> 
Reviewed.

Thanks,
-Chris.

From adinn at redhat.com  Thu May 23 10:55:59 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 23 May 2019 11:55:59 +0100
Subject: RFR: 8207851: Implement JEP 352
Message-ID: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>

Hi,

Could I please have reviews of the following change set which implements
JEP 352:

JEP:    https://openjdk.java.net/jeps/352
JIRA:   https://bugs.openjdk.java.net/browse/JDK-8207851
webrev: http://cr.openjdk.java.net/~adinn/8207851/webrev.00/

I would also very much like to target this implementation for JDK13.

Testing:

The webrev includes a simple test (in directory
test/jdk/java/nio/MappedByteBuffer) which ensures that an NVRAM-backed
MappedByteBuffer can be created, updated and forced using cache line
flushes. This test is marked as ignored because it requires, inter alia,
a suitably configured host, fitted with an NVRAM DIMM device or
employing a pseudo-NVAM device simulated over volatile RAM.

The above test has been run successfully on Linux x86_64 with an Optane
DIMM and with a pseduo-NVRAM device. Further, more rigorous testing has
been done in both the above configurations using the Narayana
Transactions logger and Infinispan distributed data grid.

Testing of /successful/ use of the API on Linux AArch64 has not yet been
possible with either emulated or real NVRAM devices as it requires an
updated (ARMv8.2) CPU hardware capability as well as access to AArch64
compatible NVRAM devices. n.b. an AArch64 compatibility flag
(-X:UsePOCForPOP) has been provided in the current patch to support
testing on older CPUs using simulated NVRAM. Unfortunately, it has not
yet been possible to obtain access to an AArch64 v8.1 machine that
supports simulation of NVRAM devices via volatile RAM.

In consequence, AArch64 testing has been limited to ensuring that the
relevant API failure modes correctly manifest: i.e.

  v8.1 CPUs which lack the relevant hardware instructions refuse to map
NVRAM-backed buffers trwoing UnsupportedOperationException

  v8.1 CPUs which bypass this failure via compatibility mode fail at the
mmap stage with IOException due to lack of NVRAM mapping support in the
underlying OS mmap API

It is expected that the omissions in AArch64 testing will be rectified
in the next few weeks. While this is desirable, the omissions are not
viewed as critical since there is currently no general access to the
relevant hardware.

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 claes.redestad at oracle.com  Thu May 23 12:57:21 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 23 May 2019 14:57:21 +0200
Subject: RFR: 8224202: Speed up Properties.load
In-Reply-To: <97ce78c1-9c14-7309-1a14-db5f6da8f6b6@oracle.com>
References: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>
 <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com>
 <94d45c5b-b09e-1c25-80e7-b7bbdad0ea93@oracle.com>
 <e46abefb-32d4-27be-2b68-7cb697fc6770@oracle.com>
 <97ce78c1-9c14-7309-1a14-db5f6da8f6b6@oracle.com>
Message-ID: <1fe928b1-58cc-9dcc-572f-20a9fe6fdb9e@oracle.com>

Hi Ivan!

On 2019-05-23 02:11, Ivan Gerasimov wrote:
> Hi Claes!
> 
> A few comments:
> 
> 1)
> 
>  ?571???????????????????? if (len == lineBuf.length) {
>  ?572???????????????????????? int newLength = 
> ArraysSupport.newLength(lineBuf.length, 1, lineBuf.length);
> 
> could be written slightly shorter as
> 
>  ?571???????????????????? if (len == lineBuf.length) {
>  ?572???????????????????????? int newLength = 
> ArraysSupport.newLength(len, 1, len);
> 
> 2)
>  ?585???????????????????? if (len == 0) {
>  ?586???????????????????????? skipWhiteSpace = true;
>  ?587???????????????????????? len = 0;
> 
> no need to update len here

nice catches, fixed.

> 
> 3)
> In loadConvert(char[] in, int off, int len, StringBuilder out):
> 
> It may make sense to first scan the input buffer for backslash, and if 
> not found (should be a common case), return new String(in, off, len), so 
> a copying to the StringBuilder will be avoided.
> 
> Otherwise:
>  ??? out.append(in, off, posOfSlash - off);
>  ??? off = posOfSlash;
> 
> and continue as before...

Right, this got a bit murky since String(char[], int, int) runs through
a noisy compress method and execute more bytecode in profiles. Still it
comes out a bit faster in a few real measurements, probably due to doing
fewer calls from interpreter to compiled code in the end:

http://cr.openjdk.java.net/~redestad/8224202/open.03/

Thanks!

/Claes

From christoph.langer at sap.com  Thu May 23 13:39:08 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 23 May 2019 13:39:08 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>
Message-ID: <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Stuart,

big thanks for your great updates here. This all looks a lot cleaner: http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/

So, for ConcurrentSkipListMap.java, the new coding is a real improvement, removing a @SuppressWarnings("unchecked") and a cast which are both unnecessary then.
@Martin Buchholz: What do I have to do to get this into the jsr166 integration 2019-06? Shall I open a separate bug? Or shall it be committed with the fix to JDK-8223553? Please guide me.

In the other 3 locations, we're able to eliminate the EC4J issues by introducing a local variable with the right type declaration. Sounds like a viable workaround.

At Eclipse we have the following bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=530236. It refers to the OpenJDK bug https://bugs.openjdk.java.net/browse/JDK-8016207. 

I'm wondering whether this should be submitted and I should at the same time submit another bug to evaluate these code places at a time when the final resolution for JDK-8016207 was provided?

Thank you
Christoph


> -----Original Message-----
> From: Stuart Marks <stuart.marks at oracle.com>
> Sent: Samstag, 18. Mai 2019 00:56
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: David Holmes <david.holmes at oracle.com>; Daniel Fuchs
> <daniel.fuchs at oracle.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; net-dev <net-dev at openjdk.java.net>; compiler-
> dev at openjdk.java.net
> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the
> Eclipse Java Compiler
> 
> Hi Christoph,
> 
> I'm still not entirely sure why this is so, but the introduction of a local
> variable in MethodHandles.java seems to make things work for Eclipse.
> Addition
> of a local variable seems to be minimally invasive, so it makes sense to see if
> this technique can be applied to other cases.
> 
> (In ConcurrentSkipListMap the issue seems to be solved by addition of
> wildcards,
> as I had suggested previously, and it cleans up the unchecked cast that was
> there in the first place. So I think that one is ok already.)
> 
> In ManagementFactory.java, an unchecked cast and warnings suppression is
> introduced, and in ExchangeImpl.java a helper method was introduced. I've
> found
> ways to introduce local variables that make Eclipse happy for these cases.
> (Well, on localized test cases; I haven't built the whole JDK with Eclipse.) See
> diffs below.
> 
> The type of the local variable in ExchangeImpl.java is a mouthful.
> Interestingly
> I had to change Function.identity() to the lambda x -> x. I think this is
> because Function.identity() returns a function that doesn't allow its return
> type to vary from its argument, whereas x -> x allows a widening conversion.
> (This might provide a clue as to the differences between javac and Eclipse
> here,
> but a full understanding eludes me.)
> 
> s'marks
> 
> 
> 
> diff -r 006dadb903ab
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav
> a
> ---
> a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.j
> ava
> Mon May 13 17:15:56 2019 -0700
> +++
> b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.j
> ava
> Fri May 17 15:46:14 2019 -0700
> @@ -1712,9 +1712,7 @@
>           Map<?,?> m = (Map<?,?>) o;
>           try {
>               Comparator<? super K> cmp = comparator;
> -            @SuppressWarnings("unchecked")
> -            Iterator<Map.Entry<?,?>> it =
> -                (Iterator<Map.Entry<?,?>>)m.entrySet().iterator();
> +            Iterator<? extends Map.Entry<?,?>> it = m.entrySet().iterator();
>               if (m instanceof SortedMap &&
>                   ((SortedMap<?,?>)m).comparator() == cmp) {
>                   Node<K,V> b, n;
> diff -r 006dadb903ab
> src/java.management/share/classes/java/lang/management/ManagementF
> actory.java
> ---
> a/src/java.management/share/classes/java/lang/management/Managemen
> tFactory.java
> Mon May 13 17:15:56 2019 -0700
> +++
> b/src/java.management/share/classes/java/lang/management/Managemen
> tFactory.java
> Fri May 17 15:46:14 2019 -0700
> @@ -872,12 +872,12 @@
>       public static Set<Class<? extends PlatformManagedObject>>
>              getPlatformManagementInterfaces()
>       {
> -        return platformComponents()
> +        Stream<Class<? extends PlatformManagedObject>> pmos =
> platformComponents()
>                   .stream()
>                   .flatMap(pc -> pc.mbeanInterfaces().stream())
>                   .filter(clazz ->
> PlatformManagedObject.class.isAssignableFrom(clazz))
> -                .map(clazz -> clazz.asSubclass(PlatformManagedObject.class))
> -                .collect(Collectors.toSet());
> +                .map(clazz -> clazz.asSubclass(PlatformManagedObject.class));
> +         return pmos.collect(Collectors.toSet());
>       }
> 
>       private static final String NOTIF_EMITTER =
> diff -r 006dadb903ab
> src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
> ---
> a/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
> Mon May 13 17:15:56 2019 -0700
> +++
> b/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
> Fri May 17 15:46:14 2019 -0700
> @@ -92,8 +92,9 @@
>               CompletableFuture<Http2Connection> c2f =
> c2.getConnectionFor(request, exchange);
>               if (debug.on())
>                   debug.log("get: Trying to get HTTP/2 connection");
> -            return c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange,
> connection))
> -                    .thenCompose(Function.identity());
> +            CompletableFuture<CompletableFuture<? extends
> ExchangeImpl<U>>> fxi =
> +                c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange,
> connection));
> +            return fxi.thenCompose(x -> x);
>           }
>       }
> 


From daniel.fuchs at oracle.com  Thu May 23 13:47:26 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 23 May 2019 14:47:26 +0100
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>
 <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <bea5f221-235d-9138-d039-b449a98e2510@oracle.com>

On 23/05/2019 14:39, Langer, Christoph wrote:
> big thanks for your great updates here. This all looks a lot cleaner:http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/

I concur. Thanks Stuart!

best regards,

-- daniel

From erik.joelsson at oracle.com  Thu May 23 13:46:44 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 May 2019 06:46:44 -0700
Subject: [13] RFR: 8221431: Support for Unicode 12.1
In-Reply-To: <d6ac40eb-09b9-7b64-d07c-cce8773e2d9f@oracle.com>
References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com>
 <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com>
 <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com>
 <d6ac40eb-09b9-7b64-d07c-cce8773e2d9f@oracle.com>
Message-ID: <36408f60-1669-1726-27be-b660267827c8@oracle.com>

Build changes look good.

/Erik

On 2019-05-22 18:36, naoto.sato at oracle.com wrote:
> Hi Erik,
>
> Thank you for your comments. Updated the webrev accordingly:
>
> https://cr.openjdk.java.net/~naoto/8221431/webrev.04/
>
> Naoto
>
> On 5/22/19 4:13 PM, Erik Joelsson wrote:
>> Hello Naoto,
>>
>> In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the 
>> double $$. I would recommend calling the newer MakeTargetDir macro 
>> instead. It doesn't take an argument.
>>
>> Otherwise build changes look good.
>>
>> /Erik
>>
>> On 2019-05-22 15:56, naoto.sato at oracle.com wrote:
>>> Adding build-dev, as the change adds a small build tool to parse 
>>> emoji-data.
>>>
>>> Naoto
>>>
>>> On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote:
>>>> Hi,
>>>>
>>>> Please review the changes to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8221431
>>>>
>>>> The proposed CSR and changeset are located at:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8222771
>>>> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/
>>>>
>>>> This enhancement incorporates support for the recently released 
>>>> Unicode version 12.1. Besides the usual addition of new 
>>>> characters/scripts, this enhancement includes normalization of the 
>>>> Japanese Reiwa era character (U+32FF), and up-to-date extended 
>>>> grapheme cluster support in regex package.
>>>>
>>>> Naoto

From Roger.Riggs at oracle.com  Thu May 23 14:42:22 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 23 May 2019 10:42:22 -0400
Subject: RFR: 8224202: Speed up Properties.load
In-Reply-To: <1fe928b1-58cc-9dcc-572f-20a9fe6fdb9e@oracle.com>
References: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>
 <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com>
 <94d45c5b-b09e-1c25-80e7-b7bbdad0ea93@oracle.com>
 <e46abefb-32d4-27be-2b68-7cb697fc6770@oracle.com>
 <97ce78c1-9c14-7309-1a14-db5f6da8f6b6@oracle.com>
 <1fe928b1-58cc-9dcc-572f-20a9fe6fdb9e@oracle.com>
Message-ID: <5c1d1fb2-8e1a-a645-62c0-1ba17d060a9d@oracle.com>

Hi Claes,

Looking good.

Is there any performance benefit to using ?: instead of if..else at
Line 509-515??? c = (fromStream) ? (char) (byteBuf[off++] & 0xFF) : 
charBuf[off++];

Line 578-581:?? precedingBackslash = (c == '\\') ? !precedingBackslash : 
false;

Line 600:? add 'the"? to "characters in +the+ following line"

Thanks, Roger

On 05/23/2019 08:57 AM, Claes Redestad wrote:
> Hi Ivan!
>
> On 2019-05-23 02:11, Ivan Gerasimov wrote:
>> Hi Claes!
>>
>> A few comments:
>>
>> 1)
>>
>> ??571???????????????????? if (len == lineBuf.length) {
>> ??572???????????????????????? int newLength = 
>> ArraysSupport.newLength(lineBuf.length, 1, lineBuf.length);
>>
>> could be written slightly shorter as
>>
>> ??571???????????????????? if (len == lineBuf.length) {
>> ??572???????????????????????? int newLength = 
>> ArraysSupport.newLength(len, 1, len);
>>
>> 2)
>> ??585???????????????????? if (len == 0) {
>> ??586???????????????????????? skipWhiteSpace = true;
>> ??587???????????????????????? len = 0;
>>
>> no need to update len here
>
> nice catches, fixed.
>
>>
>> 3)
>> In loadConvert(char[] in, int off, int len, StringBuilder out):
>>
>> It may make sense to first scan the input buffer for backslash, and 
>> if not found (should be a common case), return new String(in, off, 
>> len), so a copying to the StringBuilder will be avoided.
>>
>> Otherwise:
>> ???? out.append(in, off, posOfSlash - off);
>> ???? off = posOfSlash;
>>
>> and continue as before...
>
> Right, this got a bit murky since String(char[], int, int) runs through
> a noisy compress method and execute more bytecode in profiles. Still it
> comes out a bit faster in a few real measurements, probably due to doing
> fewer calls from interpreter to compiled code in the end:
>
> http://cr.openjdk.java.net/~redestad/8224202/open.03/
>
> Thanks!
>
> /Claes


From claes.redestad at oracle.com  Thu May 23 15:43:32 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 23 May 2019 17:43:32 +0200
Subject: RFR: 8224202: Speed up Properties.load
In-Reply-To: <5c1d1fb2-8e1a-a645-62c0-1ba17d060a9d@oracle.com>
References: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>
 <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com>
 <94d45c5b-b09e-1c25-80e7-b7bbdad0ea93@oracle.com>
 <e46abefb-32d4-27be-2b68-7cb697fc6770@oracle.com>
 <97ce78c1-9c14-7309-1a14-db5f6da8f6b6@oracle.com>
 <1fe928b1-58cc-9dcc-572f-20a9fe6fdb9e@oracle.com>
 <5c1d1fb2-8e1a-a645-62c0-1ba17d060a9d@oracle.com>
Message-ID: <cf9a3b5f-52ef-e053-bf89-80db236622f5@oracle.com>

Hi Roger,

On 2019-05-23 16:42, Roger Riggs wrote:
> Hi Claes,
> 
> Looking good.
> 
> Is there any performance benefit to using ?: instead of if..else at
> Line 509-515??? c = (fromStream) ? (char) (byteBuf[off++] & 0xFF) : 
> charBuf[off++];
> 
> Line 578-581:?? precedingBackslash = (c == '\\') ? !precedingBackslash : 
> false;

well, there's possibly a (tiny) benefit: ternary expressions generate
slightly more compact bytecode in some cases; in this case trims away
~40 bytes from LineReader.class. When looking at profiles of how many
get executed there's no real difference though, so it hardly matters.

> 
> Line 600:? add 'the"? to "characters in +the+ following line"

Done!

http://cr.openjdk.java.net/~redestad/8224202/open.04/

/Claes

From ivan.gerasimov at oracle.com  Thu May 23 16:28:51 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 23 May 2019 09:28:51 -0700
Subject: RFR: 8224202: Speed up Properties.load
In-Reply-To: <1fe928b1-58cc-9dcc-572f-20a9fe6fdb9e@oracle.com>
References: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>
 <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com>
 <94d45c5b-b09e-1c25-80e7-b7bbdad0ea93@oracle.com>
 <e46abefb-32d4-27be-2b68-7cb697fc6770@oracle.com>
 <97ce78c1-9c14-7309-1a14-db5f6da8f6b6@oracle.com>
 <1fe928b1-58cc-9dcc-572f-20a9fe6fdb9e@oracle.com>
Message-ID: <d4456670-eb41-3937-cb4b-d6aa843daf49@oracle.com>

Hi Claes!

Looks good to me!

The comment

630         // Reset the shared buffer

should probably be moved down to

645         out.setLength(0);

With kind regards,

Ivan


On 5/23/19 5:57 AM, Claes Redestad wrote:
> Hi Ivan!
>
> On 2019-05-23 02:11, Ivan Gerasimov wrote:
>> Hi Claes!
>>
>> A few comments:
>>
>> 1)
>>
>>   571                     if (len == lineBuf.length) {
>>   572                         int newLength = 
>> ArraysSupport.newLength(lineBuf.length, 1, lineBuf.length);
>>
>> could be written slightly shorter as
>>
>>   571                     if (len == lineBuf.length) {
>>   572                         int newLength = 
>> ArraysSupport.newLength(len, 1, len);
>>
>> 2)
>>   585                     if (len == 0) {
>>   586                         skipWhiteSpace = true;
>>   587                         len = 0;
>>
>> no need to update len here
>
> nice catches, fixed.
>
>>
>> 3)
>> In loadConvert(char[] in, int off, int len, StringBuilder out):
>>
>> It may make sense to first scan the input buffer for backslash, and 
>> if not found (should be a common case), return new String(in, off, 
>> len), so a copying to the StringBuilder will be avoided.
>>
>> Otherwise:
>>      out.append(in, off, posOfSlash - off);
>>      off = posOfSlash;
>>
>> and continue as before...
>
> Right, this got a bit murky since String(char[], int, int) runs through
> a noisy compress method and execute more bytecode in profiles. Still it
> comes out a bit faster in a few real measurements, probably due to doing
> fewer calls from interpreter to compiled code in the end:
>
> http://cr.openjdk.java.net/~redestad/8224202/open.03/
>
> Thanks!
>
> /Claes
>

-- 
With kind regards,
Ivan Gerasimov


From claes.redestad at oracle.com  Thu May 23 16:38:42 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 23 May 2019 18:38:42 +0200
Subject: RFR: 8224202: Speed up Properties.load
In-Reply-To: <d4456670-eb41-3937-cb4b-d6aa843daf49@oracle.com>
References: <e551bdb4-d171-ad02-a62d-b5720f79c27e@oracle.com>
 <96d85210-d852-fd59-5f8e-e0c69a639e7b@oracle.com>
 <94d45c5b-b09e-1c25-80e7-b7bbdad0ea93@oracle.com>
 <e46abefb-32d4-27be-2b68-7cb697fc6770@oracle.com>
 <97ce78c1-9c14-7309-1a14-db5f6da8f6b6@oracle.com>
 <1fe928b1-58cc-9dcc-572f-20a9fe6fdb9e@oracle.com>
 <d4456670-eb41-3937-cb4b-d6aa843daf49@oracle.com>
Message-ID: <10e7d984-00b8-a251-0c6c-6b0d1dc4a299@oracle.com>

On 2019-05-23 18:28, Ivan Gerasimov wrote:
> Hi Claes!
> 
> Looks good to me!

Thanks Ivan,

I'll fix up the comments before push.

/Claes

From guy.steele at oracle.com  Thu May 23 18:16:33 2019
From: guy.steele at oracle.com (Guy Steele)
Date: Thu, 23 May 2019 14:16:33 -0400
Subject: Need help with OpenJDK sandbox branch creation
In-Reply-To: <7D8C726E-BD86-4FF0-8BB9-0FB0893C73E6@oracle.com>
References: <7D8C726E-BD86-4FF0-8BB9-0FB0893C73E6@oracle.com>
Message-ID: <8B1CE98D-A2B3-4FF1-913B-4501BB0F380E@oracle.com>

Hi, sorry for wide distribution, but I am at my wits? end and need help.

I have finished writing the code for the new JEP on "Enhanced pseudo-random number generators? (https://bugs.openjdk.java.net/browse/JDK-8193209) and am now trying to follow the instructions at

	https://cr.openjdk.java.net/~chegar/docs/sandbox.html

to treat a new branch "JDK-8193209-branch? to which to push this code for wider inspection.

Following item 5 of those instructions, I successfully cloned the repository http://hg.openjdk.java.net/jdk/sandbox and created the branch and did the dummy commit.  But the push on the last step is failing for reasons I don?t understand.  Here?s a transcript:

???????????????????????????
gls% hg push -b JDK-8193209-branch --new-branch
pushing to ssh://gls at hg.openjdk.java.net/jdk/sandbox
searching for changes
remote: abort: could not lock repository jdk/sandbox: Read-only file system
abort: unexpected response: empty string
???????????????????????????

Here is the version info for Mercurial (I downloaded the latest one, for MacOS, just yesterday):

???????????????????????????
gls% hg --version
Mercurial Distributed SCM (version 5.0)
(see https://mercurial-scm.org for more information)

Copyright (C) 2005-2019 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
???????????????????????????

Here are the contents of the file sandbox/.hg/hgrc on my local machine:

???????????????????????????
[paths]
default = http://hg.openjdk.java.net/jdk/sandbox
default-push = ssh://gls at hg.openjdk.java.net/jdk/sandbox
???????????????????????????

 I do have an ssh-agent running, and here is what ssh-add had to say:

???????????????????????????
gls% ssh-add
Identity added: /Users/gls/.ssh/id_rsa (/Users/gls/.ssh/id_rsa)
???????????????????????????

Here is what ?hg outgoing? produces:

???????????????????????????
gls% hg outgoing
comparing with ssh://gls at hg.openjdk.java.net/jdk/sandbox
searching for changes
changeset:   56598:6a68d15c5569
branch:      JDK-8193209-branch
tag:         tip
parent:      56596:65b0b63d7f14
user:        Guy Steele <guy.steele at oracle.com>
date:        Wed May 22 16:15:51 2019 -0400
summary:     Initial changes for JDK-8193209
???????????????????????????

Please, does anyone have any clues for me?

?Guy


From kevin.rushforth at oracle.com  Thu May 23 18:23:53 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 23 May 2019 11:23:53 -0700
Subject: Need help with OpenJDK sandbox branch creation
In-Reply-To: <8B1CE98D-A2B3-4FF1-913B-4501BB0F380E@oracle.com>
References: <7D8C726E-BD86-4FF0-8BB9-0FB0893C73E6@oracle.com>
 <8B1CE98D-A2B3-4FF1-913B-4501BB0F380E@oracle.com>
Message-ID: <0a6fd1f3-b249-35e9-a339-82ec57b19365@oracle.com>

You need to be a 'jdk' Project Committer [1] in order to push to any 
repo in the jdk Project, including the sandbox.

-- Kevin

[1] https://openjdk.java.net/census#jdk


On 5/23/2019 11:16 AM, Guy Steele wrote:
> Hi, sorry for wide distribution, but I am at my wits? end and need help.
>
> I have finished writing the code for the new JEP on "Enhanced pseudo-random number generators? (https://bugs.openjdk.java.net/browse/JDK-8193209) and am now trying to follow the instructions at
>
> 	https://cr.openjdk.java.net/~chegar/docs/sandbox.html
>
> to treat a new branch "JDK-8193209-branch? to which to push this code for wider inspection.
>
> Following item 5 of those instructions, I successfully cloned the repository http://hg.openjdk.java.net/jdk/sandbox and created the branch and did the dummy commit.  But the push on the last step is failing for reasons I don?t understand.  Here?s a transcript:
>
> ???????????????????????????
> gls% hg push -b JDK-8193209-branch --new-branch
> pushing to ssh://gls at hg.openjdk.java.net/jdk/sandbox
> searching for changes
> remote: abort: could not lock repository jdk/sandbox: Read-only file system
> abort: unexpected response: empty string
> ???????????????????????????
>
> Here is the version info for Mercurial (I downloaded the latest one, for MacOS, just yesterday):
>
> ???????????????????????????
> gls% hg --version
> Mercurial Distributed SCM (version 5.0)
> (see https://mercurial-scm.org for more information)
>
> Copyright (C) 2005-2019 Matt Mackall and others
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> ???????????????????????????
>
> Here are the contents of the file sandbox/.hg/hgrc on my local machine:
>
> ???????????????????????????
> [paths]
> default = http://hg.openjdk.java.net/jdk/sandbox
> default-push = ssh://gls at hg.openjdk.java.net/jdk/sandbox
> ???????????????????????????
>
>   I do have an ssh-agent running, and here is what ssh-add had to say:
>
> ???????????????????????????
> gls% ssh-add
> Identity added: /Users/gls/.ssh/id_rsa (/Users/gls/.ssh/id_rsa)
> ???????????????????????????
>
> Here is what ?hg outgoing? produces:
>
> ???????????????????????????
> gls% hg outgoing
> comparing with ssh://gls at hg.openjdk.java.net/jdk/sandbox
> searching for changes
> changeset:   56598:6a68d15c5569
> branch:      JDK-8193209-branch
> tag:         tip
> parent:      56596:65b0b63d7f14
> user:        Guy Steele <guy.steele at oracle.com>
> date:        Wed May 22 16:15:51 2019 -0400
> summary:     Initial changes for JDK-8193209
> ???????????????????????????
>
> Please, does anyone have any clues for me?
>
> ?Guy
>


From ivan.gerasimov at oracle.com  Thu May 23 18:25:55 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 23 May 2019 11:25:55 -0700
Subject: RFR 7061590 : Javadoc issues in Charset and StandardCharsets
In-Reply-To: <624bf0ee-9ef7-6854-dfe3-a4f5b097e73d@oracle.com>
References: <42d93f0f-f725-5c72-bd0f-4e4b768e598f@oracle.com>
 <cad46f3f-579d-8f1f-cfb4-3d01dae2317f@oracle.com>
 <624bf0ee-9ef7-6854-dfe3-a4f5b097e73d@oracle.com>
Message-ID: <a858010a-a93f-0012-7185-c7b8d169c7ed@oracle.com>

Hello!

Do you think it's good to go now?

Thanks in advance,

Ivan


On 5/20/19 12:26 PM, Ivan Gerasimov wrote:
> Thank you Jon and Alan for your suggestions!
>
> Here's the new webrev updated accordingly:
>
> http://cr.openjdk.java.net/~igerasim/7061590/01/webrev/
>
> With kind regards,
>
> Ivan
>
>
> On 5/20/19 12:03 PM, Alan Bateman wrote:
>> On 20/05/2019 19:48, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> A few small javadoc issues.
>>>
>>> The most visible one is that the last dot in abbreviation a.k.a. is 
>>> treated as a period, so the generated description appears broken 
>>> (see [1] 
>>> <https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/nio/charset/StandardCharsets.html>):
>>>
>>> static Charset    ISO_8859_1    ISO Latin Alphabet No. 1, a.k.a.
>>> static Charset    US_ASCII      Seven-bit ASCII, a.k.a.
>>> ...
>>>
>>> Would you please help review the fix?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-7061590
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/7061590/00/webrev/
>> I agree with Jon on the a.k.a uages.
>>
>> Also Charsets puts a space after <p> so should probably keep that 
>> consistent.
>>
>> -Alan.
>>
>

-- 
With kind regards,
Ivan Gerasimov


From guy.steele at oracle.com  Thu May 23 18:32:57 2019
From: guy.steele at oracle.com (Guy Steele)
Date: Thu, 23 May 2019 14:32:57 -0400
Subject: Need help with OpenJDK sandbox branch creation
In-Reply-To: <0a6fd1f3-b249-35e9-a339-82ec57b19365@oracle.com>
References: <7D8C726E-BD86-4FF0-8BB9-0FB0893C73E6@oracle.com>
 <8B1CE98D-A2B3-4FF1-913B-4501BB0F380E@oracle.com>
 <0a6fd1f3-b249-35e9-a339-82ec57b19365@oracle.com>
Message-ID: <2A6D5DAA-F466-47E2-BE8C-6502F7E9AA38@oracle.com>


> On May 23, 2019, at 2:23 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> You need to be a 'jdk' Project Committer [1] in order to push to any repo in the jdk Project, including the sandbox.
> 
> -- Kevin
> 
> [1] https://openjdk.java.net/census#jdk

Yep, that?ll do it.  Thanks!


From Alan.Bateman at oracle.com  Thu May 23 18:35:11 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 May 2019 19:35:11 +0100
Subject: RFR 7061590 : Javadoc issues in Charset and StandardCharsets
In-Reply-To: <a858010a-a93f-0012-7185-c7b8d169c7ed@oracle.com>
References: <42d93f0f-f725-5c72-bd0f-4e4b768e598f@oracle.com>
 <cad46f3f-579d-8f1f-cfb4-3d01dae2317f@oracle.com>
 <624bf0ee-9ef7-6854-dfe3-a4f5b097e73d@oracle.com>
 <a858010a-a93f-0012-7185-c7b8d169c7ed@oracle.com>
Message-ID: <99c0baa4-73ed-f737-87e6-ccdcc6eddd1f@oracle.com>



On 23/05/2019 19:25, Ivan Gerasimov wrote:
> Hello!
>
> Do you think it's good to go now?
>
> Thanks in advance,
This version looks okay to me.

-Alan

From alexey.semenyuk at oracle.com  Thu May 23 18:57:45 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 23 May 2019 14:57:45 -0400
Subject: RFR: JDK-8223643: Provide better defined context for custom installer
 steps on Windows
Message-ID: <98b17332-1356-69e0-36a7-cb7cc4a491f8@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

src\jdk.jpackage\windows\classes\jdk\jpackage\internal\WinMsiBundler.java:
 ?- code running candle.exe on WiX sources reworked. Before the fix 
template.wxs file was used in text substitution with application 
specific strings and the result file was passed to candel.exe command 
line. With this patch application specific data is saved in WiX 
variables that are put on candle.exe command line and candle.exe runs on 
main.wxs that is used as is. Sample candle.exe command line:
---
Running [C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe, 
-nologo, 
C:\cygwin64\tmp\jdk.jpackage1414148896269938282\config\GuiTest.wxs, 
-ext, WixUtilExtension, -out, 
C:\cygwin64\tmp\jdk.jpackage1414148896269938282\tmp\GuiTest.wixobj, 
-dJpAppDescription=GuiTest, -dJpAppVersion=1.0, 
-dJpWixVersion36OrNewer=yes, 
-dJpProductCode=36784cc6-d050-4852-ac67-2f7de7c0b292, 
-dJpAppName=GuiTest, 
-dJpProductUpgradeCode=4f3374fd-f78a-4ffb-96f8-d5412bcca95f, 
-dJpIsSystemWide=yes, -dJpAppVendor=Unknown, 
-dJpConfigDir=C:\cygwin64\tmp\jdk.jpackage1414148896269938282\config] in 
C:\cygwin64\tmp\jdk.jpackage1414148896269938282\images\win-msi.image\GuiTest
GuiTest.wxs
---
 ?- high level description of what WinMsiBundler class does is 
documented in class comment. Meaning of WiX variables defined by 
jpackage on candle.exe command line documented as well. Main Wix source 
used by jpackage (main.wxs) and a set of WiX variables defined by 
jpackage should be considered as a public interface for custom 
extensions of WiX installers produced by jpackage;

- fix error when r/o non rtf file is passed with --license command line 
option (line 459).

test\jdk\tools\jpackage\createinstaller\windows:
 ?- added tests for runtime installer. Like all jpackage tests that 
depend on running platform specific packaging tools (WiX Toolkit, 
rpmbuild, etc.) the new tests come with @ignore tag.

src\jdk.jpackage\share\classes\jdk\jpackage\main\CommandLine.java:
 ?- fix javadoc errors and make the class package private.

src\jdk.jpackage\windows\classes\jdk\jpackage\internal\resources\WinResources.properties, 
MsiInstallerStrings_en.wxl:
 ?- move "message.install.dir.exist" string from .properties file to 
corresponding .wxl file. Reason: this string is referenced only from 
installers generated by jpackage, not in jpackage itself. All localized 
strings used in installers should be stored in .wxl files and not in 
.properties files.

src\jdk.jpackage\windows\classes\jdk\jpackage\internal\resources\template.wxs, 
main.wxs:
 ?- rename template.wxs into main.wxs and make it a valid WiX source 
that doesn't require preliminary text substitution.

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

[2] http://cr.openjdk.java.net/~asemenyuk/8223643/webrev.00/

Thanks,
Alexey

From stuart.marks at oracle.com  Thu May 23 19:10:52 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 23 May 2019 12:10:52 -0700
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>
 <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <52ff8820-c73c-1c56-e3f2-71ac174cfb57@oracle.com>



On 5/23/19 6:39 AM, Langer, Christoph wrote:
> big thanks for your great updates here. This all looks a lot cleaner: http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/

Great, glad to help. While I'm still unsure about the underlying reasons for 
this disagreement between the compilers, that might take a while to resolve. 
Putting in these fixes isn't very intrusive and it seems to make people's lives 
easier, so I don't have any objection to them going in.

> In the other 3 locations, we're able to eliminate the EC4J issues by introducing a local variable with the right type declaration. Sounds like a viable workaround.
> 
> At Eclipse we have the following bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=530236. It refers to the OpenJDK bug https://bugs.openjdk.java.net/browse/JDK-8016207.
> 
> I'm wondering whether this should be submitted and I should at the same time submit another bug to evaluate these code places at a time when the final resolution for JDK-8016207 was provided?

Overall, introducing a local variable is more-or-less reasonable even if it's 
used only once. One point is that somebody might come along and "clean up" the 
code and inline local variables and reintroduce the problem. Another point is 
that, hypothetically, if in the future Eclipse is changed to match javac's 
behavior, these changes should be reverted.

The bug database is a good place to capture actions that need to take place in 
the future. Unfortunately, it's pretty far from these locations, so the 
existence of such a bug wouldn't prevent the accidental cleanup from happening. 
That would indicate having a comment in the code at these locations.

On the other hand, if Eclipse is "fixed" and these locations don't get cleaned 
up for a long time, it doesn't seem like that big a deal.

I'd suggest to put a comment at these 3 locations, something like:

     // local variable required here; see JDK-8223553

and not bother with filing another bug report to track this.

I'll defer to Martin as to how he wants to handle the ConcurrentSkipListMap.java 
change.

s'marks

From ivan.gerasimov at oracle.com  Thu May 23 19:14:47 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 23 May 2019 12:14:47 -0700
Subject: RFR 7061590 : Javadoc issues in Charset and StandardCharsets
In-Reply-To: <99c0baa4-73ed-f737-87e6-ccdcc6eddd1f@oracle.com>
References: <42d93f0f-f725-5c72-bd0f-4e4b768e598f@oracle.com>
 <cad46f3f-579d-8f1f-cfb4-3d01dae2317f@oracle.com>
 <624bf0ee-9ef7-6854-dfe3-a4f5b097e73d@oracle.com>
 <a858010a-a93f-0012-7185-c7b8d169c7ed@oracle.com>
 <99c0baa4-73ed-f737-87e6-ccdcc6eddd1f@oracle.com>
Message-ID: <94ad5f60-a474-0659-e984-1b089b7f4a28@oracle.com>

Thank you Alan!


On 5/23/19 11:35 AM, Alan Bateman wrote:
>
>
> On 23/05/2019 19:25, Ivan Gerasimov wrote:
>> Hello!
>>
>> Do you think it's good to go now?
>>
>> Thanks in advance,
> This version looks okay to me.
>
> -Alan
>

-- 
With kind regards,
Ivan Gerasimov


From brent.christian at oracle.com  Thu May 23 19:39:30 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 23 May 2019 12:39:30 -0700
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <5CE58BA9.2090706@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
 <5CE43F5E.1050102@oracle.com>
 <008FA8AC-7CC8-4352-A90F-7B459288F364@oracle.com>
 <5CE48771.6030509@oracle.com> <5CE58BA9.2090706@oracle.com>
Message-ID: <ab0d0397-64b2-4473-dcac-28bd3806ccad@oracle.com>

Hi,

I have a couple questions/comments about the special treatment of the 
last line in a text block.

--
In the CSR we have:

"3. If the last line in the list of individual lines (i.e., the line 
with the text block closing delimiter) is blank, then add it to the set 
of determining lines. (The indentation of the closing delimiter should 
influence the indentation of the content as a whole -- a "significant 
trailing line" policy.)"

Doesn't this mean that the last line will *always* be included in the 
set of determining lines (if it's blank, and also if it's not blank) ? 
That could be stated more clearly.

--
Given that, one could put the closing delimiter at the beginning of a 
line to prevent any indent stripping, e.g.:

..............    </body>
..............</html>
""";

(I guess this is what 'optOut' is for in the webrev.)

Is it worth pointing out this possible usage more clearly?  (Or perhaps 
it's not expected to be used very often.)

Thanks,
-Brent


From francis.juge.boirard at gmail.com  Thu May 23 16:18:47 2019
From: francis.juge.boirard at gmail.com (Francis JUGE-BOIRARD (GMAIL))
Date: Thu, 23 May 2019 18:18:47 +0200
Subject: openjdk jpackage bug
Message-ID: <72c1d8d3-50a6-cdf2-97da-4af0c4d39a33@gmail.com>

<head><html> Hello,
I can not post bug on jdk bug database.

I encounter the following problem on Mac OS Mojave 10.14.5.

Execution of the order: clear; rm -rf ./tmpjpackage/ ./garbage/; ~ / 
jdk-13.jdk / Contents / Home / bin / jpackage create-installer 
--temp-root ./tmpjpackage/ --installer-type pkg -o ./garbage -i ../bin/ 
-n 'Product name'--main-jar main.jar --app-version 4.3.1 --resource-dir 
./resources/rs --vendor MyCompany --runtime-image ./jre --verbose

The command executes correctly but the output is:
Building PKG package for Product Name.
Using custom package resource [icon] (loaded from Product Name.icns).
Preparing Info.plist: 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/images/image-3449718040042442323/Product 
Name.app/Contents/Info.plist.
Using custom package resource [Application Info.plist] (loaded from 
Info.plist).
Using default package resource Runtime-Info.plist.template [Java Runtime 
Info.plist] (add Runtime-Info.plist to the resource-dir to customize).
Using custom package resource [loaded from Product Name-background.png].
Preparing distribution.dist: /Users/My 
Account/Desktop/deployment/macos/./tmpjpackage/config/distribution.dist.
no default package resource [add to Product Name-post-image.sh to the 
resource-dir to customize].
Running [pkgbuild, --root, 
./tmpjpackage/images/image-3449718040042442323, --install-location, / 
Applications, --analyze, 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/config/ cpl.plist]
pkgbuild: Inferring bundle components from contents of 
./tmpjpackage/images/image-3449718040042442323
pkgbuild: Writing new component property list to 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/config/cpl.plist
Preparing package scripts.
Using default package resource preinstall.template [PKG preinstall 
script] (add preinstall to the resource-dir to customize).
Using postinstall.template [PKG postinstall script] (add postinstall to 
the resource-dir to customize).
Running [pkgbuild, --root, 
./tmpjpackage/images/image-3449718040042442323, --install-location, / 
Applications, --component-plist, 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/ config / 
cpl.plist, --scripts, 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/config/scripts, 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/packages/Product 
Name-app.pkg]
pkgbuild: Reading components from 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/config/cpl.plist
pkgbuild: Adding component at Product Name.app
pkgbuild: Adding top-level preinstall script
pkgbuild: Adding top-level postinstall script
pkgbuild: Wrote package to 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/packages/Product 
Name-app.pkg
Running [productbuild, --resources, 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/config, 
--distribution, 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/config/distribution. 
dist, --package-path, 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage/packages, 
/Users/MyAccount/Desktop/deployment/macos/./garbage/Product Name-4.3.1.pkg ]
*productbuild: warning: No package found for distribution URL "file: 
///Users/MyAccount/Desktop/deployment/macos/tmpjpackage/config/Product+Name-app.pkg"*
productbuilder: Wrote product to 
/Users/MyAccount/Desktop/deployment/macos/./garbage/Product Name-4.3.1.pkg
Succeeded in building PKG Installer bundle.
Kept working directory for debug: 
/Users/MyAccount/Desktop/deployment/macos/./tmpjpackage.

The problem is that the pkg generated is not in the right place. See 
bold line.


I hope I'm not disturbing you.

Thanks in advance.

cordially

From martinrb at google.com  Thu May 23 21:07:05 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 23 May 2019 14:07:05 -0700
Subject: RFR: jsr166 integration 2019-06
In-Reply-To: <CA+kOe09_4jniMDStZoBztpfF1bU2WDBP+hLo0eE-N6=LN9SdJg@mail.gmail.com>
References: <CA+kOe09_4jniMDStZoBztpfF1bU2WDBP+hLo0eE-N6=LN9SdJg@mail.gmail.com>
Message-ID: <CA+kOe08WdsUWZu+thPvV=DtZL-tnQgMvfartds8o6Yt5fEiSqA@mail.gmail.com>

Adding trivial fix

8224698: ConcurrentSkipListMap.java does not compile with the Eclipse Java
Compiler
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ecj/index.html
https://bugs.openjdk.java.net/browse/JDK-8224698

On Thu, May 16, 2019 at 2:58 PM Martin Buchholz <martinrb at google.com> wrote:

>
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
>
> Just another test timeout tweak:
> 8224024: java/util/concurrent/BlockingQueue/DrainToFails.java testBounded
> fails intermittently
>
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/DrainToFails/index.html
> https://bugs.openjdk.java.net/browse/JDK-8224024
>
> 8220478: java/util/concurrent/ConcurrentHashMap/ToArray.java timed out
> intermittently
>
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/forkjoin/index.html
> 8223379: Clarify ForkJoinPool.getStealCount() javadoc
> https://bugs.openjdk.java.net/browse/JDK-8220478
>
> 8223245: Miscellaneous changes imported from jsr166 CVS 2019-06
>
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html
> https://bugs.openjdk.java.net/browse/JDK-8223245
>
>

From christoph.langer at sap.com  Thu May 23 21:23:27 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 23 May 2019 21:23:27 +0000
Subject: RFR: 8223553: Fix code constructs that do not compile with the
 Eclipse Java Compiler
In-Reply-To: <52ff8820-c73c-1c56-e3f2-71ac174cfb57@oracle.com>
References: <AM6PR02MB519235F6A09F0C22090F07928A320@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <aa0b3d32-6065-ace5-5712-2a73069e4906@oracle.com>
 <AM6PR02MB519208C9C375BF4084F2C6FF8A0C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <AM6PR02MB5192079EBDF2B00D887375E78A0F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <eae46c27-e130-3c4f-62e1-999a5154afc1@oracle.com>
 <AM6PR02MB5192DA04E92E1994A0547E8D8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <d700e152-5031-0bc0-dd94-0d5d7e7343f6@oracle.com>
 <AM6PR02MB51922E1D2C219CE90A4C407E8A080@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com>
 <AM6PR02MB519280B4DD7655AE5CAD6DCA8A090@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com>
 <AM6PR02MB51926411873A481ACA527AC08A010@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <52ff8820-c73c-1c56-e3f2-71ac174cfb57@oracle.com>
Message-ID: <AM6PR02MB5192D07EFE7EFBE9566B5DDD8A010@AM6PR02MB5192.eurprd02.prod.outlook.com>

> Overall, introducing a local variable is more-or-less reasonable even if it's
> used only once. One point is that somebody might come along and "clean
> up" the
> code and inline local variables and reintroduce the problem. Another point is
> that, hypothetically, if in the future Eclipse is changed to match javac's
> behavior, these changes should be reverted.
>
> The bug database is a good place to capture actions that need to take place in
> the future. Unfortunately, it's pretty far from these locations, so the
> existence of such a bug wouldn't prevent the accidental cleanup from
> happening.
> That would indicate having a comment in the code at these locations.
>
> On the other hand, if Eclipse is "fixed" and these locations don't get cleaned
> up for a long time, it doesn't seem like that big a deal.
>
> I'd suggest to put a comment at these 3 locations, something like:
>
>      // local variable required here; see JDK-8223553
>
> and not bother with filing another bug report to track this.

Ok, good idea. I'll add the comment before I push.

> I'll defer to Martin as to how he wants to handle the
> ConcurrentSkipListMap.java
> change.

As Martin has taken this to the jsr166 integration 2019-06, I'll push the change without ConcurrentSkipListMap.java tomorrow.

Thanks to all involved in this review!
/Christoph


From alexander.matveev at oracle.com  Thu May 23 22:06:40 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 23 May 2019 15:06:40 -0700
Subject: RFR: JDK-8223643: Provide better defined context for custom
 installer steps on Windows
In-Reply-To: <98b17332-1356-69e0-36a7-cb7cc4a491f8@oracle.com>
References: <98b17332-1356-69e0-36a7-cb7cc4a491f8@oracle.com>
Message-ID: <f2335767-1c62-1ac0-5bd1-8b6895ee5133@oracle.com>

Hi Alexey,

Looks fine.

Thanks,
Alexander

On 5/23/2019 11:57 AM, Alexey Semenyuk wrote:
> Please review the jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> src\jdk.jpackage\windows\classes\jdk\jpackage\internal\WinMsiBundler.java: 
>
> ?- code running candle.exe on WiX sources reworked. Before the fix 
> template.wxs file was used in text substitution with application 
> specific strings and the result file was passed to candel.exe command 
> line. With this patch application specific data is saved in WiX 
> variables that are put on candle.exe command line and candle.exe runs 
> on main.wxs that is used as is. Sample candle.exe command line:
> ---
> Running [C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe, 
> -nologo, 
> C:\cygwin64\tmp\jdk.jpackage1414148896269938282\config\GuiTest.wxs, 
> -ext, WixUtilExtension, -out, 
> C:\cygwin64\tmp\jdk.jpackage1414148896269938282\tmp\GuiTest.wixobj, 
> -dJpAppDescription=GuiTest, -dJpAppVersion=1.0, 
> -dJpWixVersion36OrNewer=yes, 
> -dJpProductCode=36784cc6-d050-4852-ac67-2f7de7c0b292, 
> -dJpAppName=GuiTest, 
> -dJpProductUpgradeCode=4f3374fd-f78a-4ffb-96f8-d5412bcca95f, 
> -dJpIsSystemWide=yes, -dJpAppVendor=Unknown, 
> -dJpConfigDir=C:\cygwin64\tmp\jdk.jpackage1414148896269938282\config] 
> in 
> C:\cygwin64\tmp\jdk.jpackage1414148896269938282\images\win-msi.image\GuiTest
> GuiTest.wxs
> ---
> ?- high level description of what WinMsiBundler class does is 
> documented in class comment. Meaning of WiX variables defined by 
> jpackage on candle.exe command line documented as well. Main Wix 
> source used by jpackage (main.wxs) and a set of WiX variables defined 
> by jpackage should be considered as a public interface for custom 
> extensions of WiX installers produced by jpackage;
>
> - fix error when r/o non rtf file is passed with --license command 
> line option (line 459).
>
> test\jdk\tools\jpackage\createinstaller\windows:
> ?- added tests for runtime installer. Like all jpackage tests that 
> depend on running platform specific packaging tools (WiX Toolkit, 
> rpmbuild, etc.) the new tests come with @ignore tag.
>
> src\jdk.jpackage\share\classes\jdk\jpackage\main\CommandLine.java:
> ?- fix javadoc errors and make the class package private.
>
> src\jdk.jpackage\windows\classes\jdk\jpackage\internal\resources\WinResources.properties, 
> MsiInstallerStrings_en.wxl:
> ?- move "message.install.dir.exist" string from .properties file to 
> corresponding .wxl file. Reason: this string is referenced only from 
> installers generated by jpackage, not in jpackage itself. All 
> localized strings used in installers should be stored in .wxl files 
> and not in .properties files.
>
> src\jdk.jpackage\windows\classes\jdk\jpackage\internal\resources\template.wxs, 
> main.wxs:
> ?- rename template.wxs into main.wxs and make it a valid WiX source 
> that doesn't require preliminary text substitution.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8223643
>
> [2] http://cr.openjdk.java.net/~asemenyuk/8223643/webrev.00/
>
> Thanks,
> Alexey


From brent.christian at oracle.com  Thu May 23 22:52:13 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 23 May 2019 15:52:13 -0700
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <65795019-4e7a-8d72-958c-196b35e36cf1@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
 <a1b52a84-2d67-f69f-65cb-72e32901060f@oracle.com>
 <FF5F81A2-D3DC-41BE-829E-13B0CDFE1A5A@oracle.com>
 <65795019-4e7a-8d72-958c-196b35e36cf1@oracle.com>
Message-ID: <b1941a18-a218-f118-41fe-deb2daec2f73@oracle.com>

Hi, Jim

I have a few comments on the webrev.

src/java.base/share/classes/java/lang/String.java

2982     private static int outdent(List<String> lines) {

Can you please add a doc comment for what this method does?


2973  .map(line -> {
2974      int firstNonWhitespace = line.indexOfNonWhitespace();
2975      int lastNonWhitespace = line.lastIndexOfNonWhitespace();
2976      return firstNonWhitespace > lastNonWhitespace
2977          ? "" : line.substring(Math.min(outdent, 
firstNonWhitespace), lastNonWhitespace);
2978  })
2979  .collect(Collectors.joining("\n", "", optOut ? "\n" : ""));


Like Vicente mentioned, it would be nice if less of this work were done 
when 'optOut' is true.


test/jdk/java/lang/String/StripIndent.java


I'd like for the test to be made easier to read, so it's clear which 
edge cases are covered (the last line determines a non-0 outdent, the 
last line opts out of all outdenting, etc).

Splitting the test data onto multiple lines would be a good start 
(though ironic, for this feature :).  And maybe even add a description 
of the case being tested, where not obvious.

Thanks,
-Brent

From lance.andersen at oracle.com  Thu May 23 22:58:19 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 23 May 2019 18:58:19 -0400
Subject: RFR 8224682: Remove the com.sun.CORBA.ORBIorTypeCheckRegistryFilter
 security property
Message-ID: <7E0DC760-9916-439B-9896-7C18CCF46F64@oracle.com>

Hi all,

Please review the fix for 8224682 which removes this legacy property left over from the removal from CORBA

The webrev can be found:  http://cr.openjdk.java.net/~lancea/8224682/webrev.00/ <http://cr.openjdk.java.net/~lancea/8224682/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>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 brent.christian at oracle.com  Thu May 23 23:10:21 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 23 May 2019 16:10:21 -0700
Subject: RFR 8224682: Remove the
 com.sun.CORBA.ORBIorTypeCheckRegistryFilter security property
In-Reply-To: <7E0DC760-9916-439B-9896-7C18CCF46F64@oracle.com>
References: <7E0DC760-9916-439B-9896-7C18CCF46F64@oracle.com>
Message-ID: <b7b4b371-106c-7154-4996-ab2656251753@oracle.com>

Looks fine.  I guess you'll want to update/add the Copyright year in 
JDKSecurityProperties.java.

-Brent

On 5/23/19 3:58 PM, Lance Andersen wrote:
> Hi all,
> 
> Please review the fix for 8224682 which removes this legacy property left over from the removal from CORBA
> 
> The webrev can be found:  http://cr.openjdk.java.net/~lancea/8224682/webrev.00/ <http://cr.openjdk.java.net/~lancea/8224682/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>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 lance.andersen at oracle.com  Thu May 23 23:15:38 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 23 May 2019 19:15:38 -0400
Subject: RFR 8224682: Remove the
 com.sun.CORBA.ORBIorTypeCheckRegistryFilter security property
In-Reply-To: <b7b4b371-106c-7154-4996-ab2656251753@oracle.com>
References: <7E0DC760-9916-439B-9896-7C18CCF46F64@oracle.com>
 <b7b4b371-106c-7154-4996-ab2656251753@oracle.com>
Message-ID: <C48841C7-3DE5-4F21-8FDC-5B5946427187@oracle.com>

Thank you Brent for the review.

> On May 23, 2019, at 7:10 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Looks fine.  I guess you'll want to update/add the Copyright year in JDKSecurityProperties.java.

Ah, forgot that, update below:

??????
$ hg diff test/lib/jdk/test/lib/security/JDKSecurityProperties.java
diff -r fb0cfce19262 test/lib/jdk/test/lib/security/JDKSecurityProperties.java
--- a/test/lib/jdk/test/lib/security/JDKSecurityProperties.java	Thu May 23 11:37:24 2019 -0700
+++ b/test/lib/jdk/test/lib/security/JDKSecurityProperties.java	Thu May 23 19:14:31 2019 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2018, 2019, 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,7 +29,6 @@
 public final class JDKSecurityProperties {
 
     public static final List<String> jdkProps = List.of(
-        "com.sun.CORBA.ORBIorTypeCheckRegistryFilter",
         "crypto.policy",
         "jceks.key.serialFilter",
         "jdk.certpath.disabledAlgorithms",
------------------
> 
> -Brent
> 
> On 5/23/19 3:58 PM, Lance Andersen wrote:
>> Hi all,
>> Please review the fix for 8224682 which removes this legacy property left over from the removal from CORBA
>> The webrev can be found:  http://cr.openjdk.java.net/~lancea/8224682/webrev.00/ <http://cr.openjdk.java.net/~lancea/8224682/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>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>

 <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 brent.christian at oracle.com  Thu May 23 23:17:25 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 23 May 2019 16:17:25 -0700
Subject: RFR 8224682: Remove the
 com.sun.CORBA.ORBIorTypeCheckRegistryFilter security property
In-Reply-To: <C48841C7-3DE5-4F21-8FDC-5B5946427187@oracle.com>
References: <7E0DC760-9916-439B-9896-7C18CCF46F64@oracle.com>
 <b7b4b371-106c-7154-4996-ab2656251753@oracle.com>
 <C48841C7-3DE5-4F21-8FDC-5B5946427187@oracle.com>
Message-ID: <715c7abe-9aee-4b51-49ac-d92f037a675e@oracle.com>

+1

On 5/23/19 4:15 PM, Lance Andersen wrote:
> Thank you Brent for the review.
> 
>> On May 23, 2019, at 7:10 PM, Brent Christian 
>> <brent.christian at oracle.com <mailto:brent.christian at oracle.com>> wrote:
>>
>> Looks fine. ?I guess you'll want to update/add the Copyright year in 
>> JDKSecurityProperties.java.
> 
> Ah, forgot that, update below:
> 
> ??????
> $ hg diff test/lib/jdk/test/lib/security/JDKSecurityProperties.java
> diff -r fb0cfce19262 
> test/lib/jdk/test/lib/security/JDKSecurityProperties.java
> --- a/test/lib/jdk/test/lib/security/JDKSecurityProperties.javaThu May 
> 23 11:37:24 2019 -0700
> +++ b/test/lib/jdk/test/lib/security/JDKSecurityProperties.javaThu May 
> 23 19:14:31 2019 -0400
> @@ -1,5 +1,5 @@
>  ?/*
> - * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2018, 2019, 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,7 +29,6 @@
>  ?public final class JDKSecurityProperties {
> 
> 
>  ?? ? public static final List<String> jdkProps = List.of(
> -? ? ? ? "com.sun.CORBA.ORBIorTypeCheckRegistryFilter",
>  ?? ? ? ? "crypto.policy",
>  ?? ? ? ? "jceks.key.serialFilter",
>  ?? ? ? ? "jdk.certpath.disabledAlgorithms",
> ------------------
>>
>> -Brent
>>
>> On 5/23/19 3:58 PM, Lance Andersen wrote:
>>> Hi all,
>>> Please review the fix for 8224682 which removes this legacy property 
>>> left over from the removal from CORBA
>>> The webrev can be found: 
>>> http://cr.openjdk.java.net/~lancea/8224682/webrev.00/ 
>>> <http://cr.openjdk.java.net/~lancea/8224682/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>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>
> 
> <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 jianglizhou at google.com  Thu May 23 23:21:18 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 23 May 2019 16:21:18 -0700
Subject: Thread stack size issue related to glibc TLS bug
Message-ID: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>

Hi David (and others),

There was a discussion [1] (between you, Jeremy, Martin and others)
back in 2015 regarding a stack size issue caused by a glibc bug
related to TLS (Thread local storage) [2]. The issue was manifested as
a StackOverflowError with the reported test in JDK-8130425 [0] when
large TLS size is used. A workaround was introduced with
-Djdk.lang.processReaperUseDefaultStackSize. Based on the glibc
discussion thread [2], Rust implemented a fix by taking into account
of the TLS size. From one of the comments in the OpenJDK discussion
archive [3], looks like you considered similar fix could be applied
for JVM. I talked to Jeremy about sharing his fix for this particular
issue today. The fix appears to be a more general solution than the
processReaperUseDefaultStackSize workaround. It has been tested/used
for server years and seems to be stable. The link to the changeset is
listed below. Please let me know your thoughts on taking the change in
OpenJDK.

[0] JDK bug: https://bugs.openjdk.java.net/browse/JDK-8130425
[1] OpenJDK discussion archive:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037558.html
[2] glibc discussion archive:
http://sourceware.org/bugzilla/show_bug.cgi?id=11787
[3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
(contributed by Jeremy Manson)

The #ifdef __GLIBC__ in the change could be removed as os_linux.cpp
already makes assumption about the use of glibc.

Best regards,
Jiangli

From philip.race at oracle.com  Thu May 23 23:33:55 2019
From: philip.race at oracle.com (Philip Race)
Date: Thu, 23 May 2019 16:33:55 -0700
Subject: RFR 8224682: Remove the
 com.sun.CORBA.ORBIorTypeCheckRegistryFilter security property
In-Reply-To: <b7b4b371-106c-7154-4996-ab2656251753@oracle.com>
References: <7E0DC760-9916-439B-9896-7C18CCF46F64@oracle.com>
 <b7b4b371-106c-7154-4996-ab2656251753@oracle.com>
Message-ID: <5CE72DE3.6020901@oracle.com>



On 5/23/19, 4:10 PM, Brent Christian wrote:
> Looks fine.  I guess you'll want to update/add the Copyright year in 
> JDKSecurityProperties.java.
>

Why ? What are you copyrighting ? There is nothing being added or 
modified, only a line deleted.
Copyright is held in created content, not the act of deleting content.

-phil.

> -Brent
>
> On 5/23/19 3:58 PM, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the fix for 8224682 which removes this legacy property 
>> left over from the removal from CORBA
>>
>> The webrev can be found:  
>> http://cr.openjdk.java.net/~lancea/8224682/webrev.00/ 
>> <http://cr.openjdk.java.net/~lancea/8224682/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>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  Fri May 24 02:08:44 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 May 2019 12:08:44 +1000
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
Message-ID: <46688d0d-1e7d-6c9e-0783-3adaec26c037@oracle.com>

Hi Jiangli,

On 24/05/2019 9:21 am, Jiangli Zhou wrote:
> Hi David (and others),
> 
> There was a discussion [1] (between you, Jeremy, Martin and others)
> back in 2015 regarding a stack size issue caused by a glibc bug
> related to TLS (Thread local storage) [2]. The issue was manifested as
> a StackOverflowError with the reported test in JDK-8130425 [0] when
> large TLS size is used. A workaround was introduced with
> -Djdk.lang.processReaperUseDefaultStackSize. Based on the glibc
> discussion thread [2], Rust implemented a fix by taking into account
> of the TLS size. From one of the comments in the OpenJDK discussion
> archive [3], looks like you considered similar fix could be applied
> for JVM. I talked to Jeremy about sharing his fix for this particular
> issue today. The fix appears to be a more general solution than the
> processReaperUseDefaultStackSize workaround. It has been tested/used
> for server years and seems to be stable. The link to the changeset is
> listed below. Please let me know your thoughts on taking the change in
> OpenJDK.

My thoughts haven't really changed since 2015 - and sadly neither has 
there been any change in glibc in that time. Nor, to my recollection, 
have there been any other reported issues with this.

If this were to be taken into hotspot then I think it has to be opt-in 
via a flag so that it doesn't make sudden and unexpected differences in 
the number of threads an application can create. It may also be worth 
considering, from the bugzilla discussion, only adding in the TLS size 
if it is greater than a certain percentage of the stack size being 
requested. That would limit the impact to threads with small stacks 
without forcing every thread to have to grow by the TLS size.

But I'd want to know how often this is actually needed. As Andrew Haley 
said in the original discussion thread "I think we're rather looking at 
abuse of TLS here.".

And I'd need to understand better what versions of glibc this would work 
for (and how they relate to current distros).

Cheers,
David

> [0] JDK bug: https://bugs.openjdk.java.net/browse/JDK-8130425
> [1] OpenJDK discussion archive:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037558.html
> [2] glibc discussion archive:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11787
> [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
> (contributed by Jeremy Manson)
> 
> The #ifdef __GLIBC__ in the change could be removed as os_linux.cpp
> already makes assumption about the use of glibc.
> 
> Best regards,
> Jiangli
> 

From peter.levart at gmail.com  Fri May 24 06:35:04 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 24 May 2019 08:35:04 +0200
Subject: RFR - JDK-8223775 String::stripIndent (Preview)
In-Reply-To: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com>
Message-ID: <9caee86d-c89b-9142-2742-5ce325349b08@gmail.com>

Hi,

Excuse me for asking, but I can't find any text describing motivation 
for introduction of this method in JEP-355 other than "Developers will 
have access to this algorithm via String::stripIndent instance method"...

If I understand the JEP correctly, this is an algorithm that is applied 
to Text Blocks during compilation. Is this method intended for 
developers writing java compilers?

Regards, Peter

On 5/21/19 4:56 PM, Jim Laskey wrote:
> Please do a code review of the new String::stripIndent instance 
> method. This instance method is being introduced to support JEP-355: 
> Text Blocks, by removing incidental indentation from the text block 
> content. The algorithm used is defined in the JEP and also described 
> in the JBS entry.
>
> Thank you.
>
> -- Jim
>
> webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01
> jbs: https://bugs.openjdk.java.net/browse/JDK-8223775
> csr: https://bugs.openjdk.java.net/browse/JDK-8223776
> jep: https://bugs.openjdk.java.net/browse/JDK-8222530
>
>


From christoph.langer at sap.com  Fri May 24 07:52:13 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 May 2019 07:52:13 +0000
Subject: [11u] RFR (Backport): 8223553: Fix code constructs that do not
 compile with the Eclipse Java Compiler
Message-ID: <AM6PR02MB5192152E7B11FE72DF083BEC8A020@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

I'd like to bring this fix down to jdk11 updates. Unfortunately, the webrev did not apply cleanly in the imports section of src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java, so I had to resolve this part manually. I also updated the copyright year. Please check.

Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.11u/

Thanks
Christoph


From fweimer at redhat.com  Fri May 24 09:46:35 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 24 May 2019 11:46:35 +0200
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 (Jiangli Zhou's message of "Thu, 23 May 2019 16:21:18 -0700")
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
Message-ID: <87ftp4tcas.fsf@oldenburg2.str.redhat.com>

* Jiangli Zhou:

> [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
> (contributed by Jeremy Manson)

_dl_get_tls_static_info is an internal symbol (it carries a
GLIBC_PRIVATE symbol version).  Its implementation can change at any
time.  Please do not do this.

Thanks,
Florian

From adinn at redhat.com  Fri May 24 10:06:41 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 24 May 2019 11:06:41 +0100
Subject: RFR: 8207851: Implement JEP 352
In-Reply-To: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
Message-ID: <67ad071d-376b-8b0d-9b2f-42dca17a1041@redhat.com>

Ping!

Any takers for a review?

Also, can anyone advise me on what I might need to do to target this JEP
to JDK13, other than the obvious reviewing and pushing of the
implementation?

regards,


Andrew Dinn
-----------

On 23/05/2019 11:55, Andrew Dinn wrote:
> Hi,
> 
> Could I please have reviews of the following change set which implements
> JEP 352:
> 
> JEP:    https://openjdk.java.net/jeps/352
> JIRA:   https://bugs.openjdk.java.net/browse/JDK-8207851
> webrev: http://cr.openjdk.java.net/~adinn/8207851/webrev.00/
> 
> I would also very much like to target this implementation for JDK13.
> 
> Testing:
> 
> The webrev includes a simple test (in directory
> test/jdk/java/nio/MappedByteBuffer) which ensures that an NVRAM-backed
> MappedByteBuffer can be created, updated and forced using cache line
> flushes. This test is marked as ignored because it requires, inter alia,
> a suitably configured host, fitted with an NVRAM DIMM device or
> employing a pseudo-NVAM device simulated over volatile RAM.
> 
> The above test has been run successfully on Linux x86_64 with an Optane
> DIMM and with a pseduo-NVRAM device. Further, more rigorous testing has
> been done in both the above configurations using the Narayana
> Transactions logger and Infinispan distributed data grid.
> 
> Testing of /successful/ use of the API on Linux AArch64 has not yet been
> possible with either emulated or real NVRAM devices as it requires an
> updated (ARMv8.2) CPU hardware capability as well as access to AArch64
> compatible NVRAM devices. n.b. an AArch64 compatibility flag
> (-X:UsePOCForPOP) has been provided in the current patch to support
> testing on older CPUs using simulated NVRAM. Unfortunately, it has not
> yet been possible to obtain access to an AArch64 v8.1 machine that
> supports simulation of NVRAM devices via volatile RAM.
> 
> In consequence, AArch64 testing has been limited to ensuring that the
> relevant API failure modes correctly manifest: i.e.
> 
>   v8.1 CPUs which lack the relevant hardware instructions refuse to map
> NVRAM-backed buffers trwoing UnsupportedOperationException
> 
>   v8.1 CPUs which bypass this failure via compatibility mode fail at the
> mmap stage with IOException due to lack of NVRAM mapping support in the
> underlying OS mmap API
> 
> It is expected that the omissions in AArch64 testing will be rectified
> in the next few weeks. While this is desirable, the omissions are not
> viewed as critical since there is currently no general access to the
> relevant hardware.
> 
> 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 fweimer at redhat.com  Fri May 24 10:13:21 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 24 May 2019 12:13:21 +0200
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <46688d0d-1e7d-6c9e-0783-3adaec26c037@oracle.com> (David Holmes's
 message of "Fri, 24 May 2019 12:08:44 +1000")
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <46688d0d-1e7d-6c9e-0783-3adaec26c037@oracle.com>
Message-ID: <874l5ktb26.fsf@oldenburg2.str.redhat.com>

* David Holmes:

> My thoughts haven't really changed since 2015 - and sadly neither has
> there been any change in glibc in that time. Nor, to my recollection,
> have there been any other reported issues with this.

The issue gets occasionally reported by people who use small stacks with
large initial-exec TLS consumers (such as jemalloc).  On the glibc side,
we aren't entirely sure what to do about this.  We have recently tweaked
the stack size computation, so that in many cases, threads now receive
an additional page.  This was necessary to work around a kernel/hardware
change where context switches started to push substantially more data on
the stack than before, and minimal stack sizes did not work anymore on
x86-64 (leading to ntpd crashing during startup, among other things).

The main concern is that for workloads with carefully tuned stack sizes,
revamping the stack size computation so that TLS is no longer
effectively allocated on the stack might result in address space
exhaustion.  (This should only be a concern on 32-bit architectures.)

Even if we changed this today (or had changed it in 2015), it would take
a long time for the change to end up with end users, so it's unclear how
much help it would be.

Maybe OpenJDK can add a property specifying a stack size reserve, and
htis number is added to all stack size requests?  This will at least
allow users to work around the issue locally.

If we change the accounting in glibc, we will have to add a similar
tunable on the glibc side, too.

Thanks,
Florian

From james.laskey at oracle.com  Fri May 24 12:17:45 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Fri, 24 May 2019 09:17:45 -0300
Subject: RFR (CSR) - JDK-8223776 String::stripIndent (Preview)
Message-ID: <22C33F78-63B8-42C7-A36D-1E420598BC54@oracle.com>

Please do a CSR review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry.

Thank you.

-- Jim

csr: https://bugs.openjdk.java.net/browse/JDK-8223776 <https://bugs.openjdk.java.net/browse/JDK-8223776>
webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 <http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02>
jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 <https://bugs.openjdk.java.net/browse/JDK-8223775>
jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>

From james.laskey at oracle.com  Fri May 24 12:22:35 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Fri, 24 May 2019 09:22:35 -0300
Subject: RFR (CSR) - JDK-8223781 String::translateEscapes (Preview)
Message-ID: <7AEBFD4E-8A86-4F2D-BC93-C16ABA759CFB@oracle.com>

Please do a CSR review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content.

Thank you.

-- Jim

csr: https://bugs.openjdk.java.net/browse/JDK-8223781 <https://bugs.openjdk.java.net/browse/JDK-8223781>
webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03 <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03>
jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 <https://bugs.openjdk.java.net/browse/JDK-8223780>
jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>

From philip.race at oracle.com  Fri May 24 16:35:15 2019
From: philip.race at oracle.com (Phil Race)
Date: Fri, 24 May 2019 09:35:15 -0700
Subject: RFR: 8223271: SplashScreen is still shown if defaulting to headless
 on MacOS
Message-ID: <a8c59f97-d1b2-570d-3e9a-a665fdfc9bb9@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8223271
Webrev : http://cr.openjdk.java.net/~prr/8223271/

Whilst working on removing some inappropriate coupling of the java 
launcher and the desktop module,
and testing out the -splash option, I noticed that on MacOS, in the case 
when we *default* to headless
mode (which happens when we determine that we are not in a desktop 
session), the launcher still
invokes the splash screen code. This could cause an application to 
completely hang.

The problem is explained in detail in the bug report, but briefly, the 
launcher isn't aware of this
defaulting to headless. And the calls the launcher makes to the 
dynamically loaded splashscreen
code, don't return any value it can use to be aware of this.

So this fix updates "DoSplashInit()" to return such a code, and in the 
event of a headful session
not being available, it can bail out and not try to show the splashscreen.
That is the gist of the small set of changes in java.c that relate to 
this fix.

However I also observed a small memory leak.
There are static variables

static char* splash_jar_entry = NULL; static char* splash_file_entry = 
NULL;

which are meant to hold the location of the splash image.
When everything is done the malloced storage these point to is freed ...
except that the malloc code looks like this :-

char* splash_file_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_FILE_ENV_ENTRY "=")+JLI_StrLen(splash_file_name)+1);
char* splash_jar_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_JAR_ENV_ENTRY "=")+JLI_StrLen(splash_jar_name)+1);

So the static vars are never used and the storage pointed to by local 
variables is never freed.

So I am fixing that too.

The rest of the fix is in the splashscreen code in the desktop module 
and it implements
the return of the status code described above.

There was one leak there too - a stream was not closed in a case where 
the splash could
not be displayed.

The regression tests for splash screen were run, but testing this is 
more an environmental issue -
sshing into a MacOS system and running tests and demos which would try 
to display a splash
and verifying they no longer do, so I didn't see a way to add a specific 
regression test.

-phil.






From huizhe.wang at oracle.com  Fri May 24 17:11:00 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 24 May 2019 10:11:00 -0700
Subject: RFR (JDK 13/java.xml) 8223658: Performance regression of
 XML.validation in 13-b19
Message-ID: <5CE825A4.5020806@oracle.com>

Please review a fix to the performance regression introduced by Xerces 
update. The performance benchmark gives weight to small XML files. Large 
chunk sizes are therefore not helpful. Performance tests with the 
following patch showed that the results are on par with that for JDK 13 b18.

https://bugs.openjdk.java.net/browse/JDK-8223658
http://cr.openjdk.java.net/~joehw/jdk13/8223658/webrev/

Thanks,
Joe


From lance.andersen at oracle.com  Fri May 24 17:18:17 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 24 May 2019 13:18:17 -0400
Subject: RFR (JDK 13/java.xml) 8223658: Performance regression of
 XML.validation in 13-b19
In-Reply-To: <5CE825A4.5020806@oracle.com>
References: <5CE825A4.5020806@oracle.com>
Message-ID: <EF647484-8955-4E99-A78A-1F00FA325C53@oracle.com>

+1 
> On May 24, 2019, at 1:11 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Please review a fix to the performance regression introduced by Xerces update. The performance benchmark gives weight to small XML files. Large chunk sizes are therefore not helpful. Performance tests with the following patch showed that the results are on par with that for JDK 13 b18.
> 
> https://bugs.openjdk.java.net/browse/JDK-8223658
> http://cr.openjdk.java.net/~joehw/jdk13/8223658/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 jianglizhou at google.com  Fri May 24 17:26:42 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 24 May 2019 10:26:42 -0700
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <46688d0d-1e7d-6c9e-0783-3adaec26c037@oracle.com>
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <46688d0d-1e7d-6c9e-0783-3adaec26c037@oracle.com>
Message-ID: <CALrW1jx2Un-CAUriJXyKpjL+XLGxEr7mn4k6s3r-v34aaKbVTw@mail.gmail.com>

Hi David,

Thanks for the feedback. One particular use case where the issue
surfaces is with FDO (feedback directed optimization) instrumentation
enabled build [0]. That could be a common use case.
_dl_get_tls_static_info is a glibc private symbol. I see Florian has
concerns about the usage of the API.

[0] https://en.wikipedia.org/wiki/Profile-guided_optimization

Thanks,
Jiangli

On Thu, May 23, 2019 at 7:08 PM David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Jiangli,
>
> On 24/05/2019 9:21 am, Jiangli Zhou wrote:
> > Hi David (and others),
> >
> > There was a discussion [1] (between you, Jeremy, Martin and others)
> > back in 2015 regarding a stack size issue caused by a glibc bug
> > related to TLS (Thread local storage) [2]. The issue was manifested as
> > a StackOverflowError with the reported test in JDK-8130425 [0] when
> > large TLS size is used. A workaround was introduced with
> > -Djdk.lang.processReaperUseDefaultStackSize. Based on the glibc
> > discussion thread [2], Rust implemented a fix by taking into account
> > of the TLS size. From one of the comments in the OpenJDK discussion
> > archive [3], looks like you considered similar fix could be applied
> > for JVM. I talked to Jeremy about sharing his fix for this particular
> > issue today. The fix appears to be a more general solution than the
> > processReaperUseDefaultStackSize workaround. It has been tested/used
> > for server years and seems to be stable. The link to the changeset is
> > listed below. Please let me know your thoughts on taking the change in
> > OpenJDK.
>
> My thoughts haven't really changed since 2015 - and sadly neither has
> there been any change in glibc in that time. Nor, to my recollection,
> have there been any other reported issues with this.
>
> If this were to be taken into hotspot then I think it has to be opt-in
> via a flag so that it doesn't make sudden and unexpected differences in
> the number of threads an application can create. It may also be worth
> considering, from the bugzilla discussion, only adding in the TLS size
> if it is greater than a certain percentage of the stack size being
> requested. That would limit the impact to threads with small stacks
> without forcing every thread to have to grow by the TLS size.
>
> But I'd want to know how often this is actually needed. As Andrew Haley
> said in the original discussion thread "I think we're rather looking at
> abuse of TLS here.".
>
> And I'd need to understand better what versions of glibc this would work
> for (and how they relate to current distros).
>
> Cheers,
> David
>
> > [0] JDK bug: https://bugs.openjdk.java.net/browse/JDK-8130425
> > [1] OpenJDK discussion archive:
> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037558.html
> > [2] glibc discussion archive:
> > http://sourceware.org/bugzilla/show_bug.cgi?id=11787
> > [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
> > (contributed by Jeremy Manson)
> >
> > The #ifdef __GLIBC__ in the change could be removed as os_linux.cpp
> > already makes assumption about the use of glibc.
> >
> > Best regards,
> > Jiangli
> >

From huizhe.wang at oracle.com  Fri May 24 17:29:52 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 24 May 2019 10:29:52 -0700
Subject: RFR (JDK 13/java.xml) 8223658: Performance regression of
 XML.validation in 13-b19
In-Reply-To: <EF647484-8955-4E99-A78A-1F00FA325C53@oracle.com>
References: <5CE825A4.5020806@oracle.com>
 <EF647484-8955-4E99-A78A-1F00FA325C53@oracle.com>
Message-ID: <5CE82A10.7080705@oracle.com>

Thanks Lance!  Pushed. Let's hope the performance will be back to normal 
in the next build.

Best,
Joe

On 5/24/19, 10:18 AM, Lance Andersen wrote:
> +1
>> On May 24, 2019, at 1:11 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> Please review a fix to the performance regression introduced by 
>> Xerces update. The performance benchmark gives weight to small XML 
>> files. Large chunk sizes are therefore not helpful. Performance tests 
>> with the following patch showed that the results are on par with that 
>> for JDK 13 b18.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8223658
>> http://cr.openjdk.java.net/~joehw/jdk13/8223658/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 alex.buckley at oracle.com  Fri May 24 17:35:06 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 24 May 2019 10:35:06 -0700
Subject: RFR (CSR) - JDK-8223781 String::translateEscapes (Preview)
In-Reply-To: <7AEBFD4E-8A86-4F2D-BC93-C16ABA759CFB@oracle.com>
References: <7AEBFD4E-8A86-4F2D-BC93-C16ABA759CFB@oracle.com>
Message-ID: <5CE82B4A.3090801@oracle.com>

It's a bit heavy to cite a JLS section in the summary of a method. 
Recommend:

"Returns a string whose value is this string, with escape sequences 
translated as if in a string literal."  [Not mentioning text blocks for 
simplicity. Plus, if you mention them, then it looks like you forgot 
character literals.]

@jls 3.10.7 Escape Sequences  [note the new shorter name]

@deprecated  This method is associated with text blocks, a preview 
language feature. Text blocks and/or this method may be changed or 
removed in a future release.  [Also for stripIndent]

Alex

On 5/24/2019 5:22 AM, Jim Laskey wrote:
> Please do a CSR review of the new String:: translateEscapes instance
> method. This instance method is being introduced to support JEP-355:
> Text Blocks, by translating escape sequences in the text block content.
>
> Thank you.
>
> -- Jim
>
> csr: https://bugs.openjdk.java.net/browse/JDK-8223781
> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03
> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780
> jep: https://bugs.openjdk.java.net/browse/JDK-8222530

From jianglizhou at google.com  Fri May 24 19:09:16 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 24 May 2019 12:09:16 -0700
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <874l5ktb26.fsf@oldenburg2.str.redhat.com>
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <46688d0d-1e7d-6c9e-0783-3adaec26c037@oracle.com>
 <874l5ktb26.fsf@oldenburg2.str.redhat.com>
Message-ID: <CALrW1jzHKfhao_BD2xbyPjOmJ8bDegT7yaAxv9Z6Oe_JNSL1nQ@mail.gmail.com>

Hi Florian,

Thanks for the feedback!

On Fri, May 24, 2019 at 3:13 AM Florian Weimer <fweimer at redhat.com> wrote:
>
> * David Holmes:
>
> > My thoughts haven't really changed since 2015 - and sadly neither has
> > there been any change in glibc in that time. Nor, to my recollection,
> > have there been any other reported issues with this.
>
> The issue gets occasionally reported by people who use small stacks with
> large initial-exec TLS consumers (such as jemalloc).  On the glibc side,
> we aren't entirely sure what to do about this.  We have recently tweaked
> the stack size computation, so that in many cases, threads now receive
> an additional page.  This was necessary to work around a kernel/hardware
> change where context switches started to push substantially more data on
> the stack than before, and minimal stack sizes did not work anymore on
> x86-64 (leading to ntpd crashing during startup, among other things).
>
> The main concern is that for workloads with carefully tuned stack sizes,
> revamping the stack size computation so that TLS is no longer
> effectively allocated on the stack might result in address space
> exhaustion.  (This should only be a concern on 32-bit architectures.)

Could it to be addressed for 64-bit (first) at foreseeable future?

>
> Even if we changed this today (or had changed it in 2015), it would take
> a long time for the change to end up with end users, so it's unclear how
> much help it would be.
>
> Maybe OpenJDK can add a property specifying a stack size reserve, and
> htis number is added to all stack size requests?  This will at least
> allow users to work around the issue locally.

One issue is that user may not know the property should be used and
what would be the proper reserved size when run into the stack size
issue related to TLS. The stack size issue could be hard for average
users to diagnose. Addressing the issue in glibc or JVM layer without
tuning may be more user friendly?

Thanks!

Jiangli

>
> If we change the accounting in glibc, we will have to add a similar
> tunable on the glibc side, too.
>
> Thanks,
> Florian

From fweimer at redhat.com  Fri May 24 19:17:07 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 24 May 2019 21:17:07 +0200
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <CALrW1jzHKfhao_BD2xbyPjOmJ8bDegT7yaAxv9Z6Oe_JNSL1nQ@mail.gmail.com>
 (Jiangli Zhou's message of "Fri, 24 May 2019 12:09:16 -0700")
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <46688d0d-1e7d-6c9e-0783-3adaec26c037@oracle.com>
 <874l5ktb26.fsf@oldenburg2.str.redhat.com>
 <CALrW1jzHKfhao_BD2xbyPjOmJ8bDegT7yaAxv9Z6Oe_JNSL1nQ@mail.gmail.com>
Message-ID: <87mujboe6k.fsf@oldenburg2.str.redhat.com>

* Jiangli Zhou:

> Hi Florian,
>
> Thanks for the feedback!
>
> On Fri, May 24, 2019 at 3:13 AM Florian Weimer <fweimer at redhat.com> wrote:
>>
>> * David Holmes:
>>
>> > My thoughts haven't really changed since 2015 - and sadly neither has
>> > there been any change in glibc in that time. Nor, to my recollection,
>> > have there been any other reported issues with this.
>>
>> The issue gets occasionally reported by people who use small stacks with
>> large initial-exec TLS consumers (such as jemalloc).  On the glibc side,
>> we aren't entirely sure what to do about this.  We have recently tweaked
>> the stack size computation, so that in many cases, threads now receive
>> an additional page.  This was necessary to work around a kernel/hardware
>> change where context switches started to push substantially more data on
>> the stack than before, and minimal stack sizes did not work anymore on
>> x86-64 (leading to ntpd crashing during startup, among other things).
>>
>> The main concern is that for workloads with carefully tuned stack sizes,
>> revamping the stack size computation so that TLS is no longer
>> effectively allocated on the stack might result in address space
>> exhaustion.  (This should only be a concern on 32-bit architectures.)
>
> Could it to be addressed for 64-bit (first) at foreseeable future?

Yes, I'd happily review a patch if we had one.

>> Even if we changed this today (or had changed it in 2015), it would take
>> a long time for the change to end up with end users, so it's unclear how
>> much help it would be.
>>
>> Maybe OpenJDK can add a property specifying a stack size reserve, and
>> htis number is added to all stack size requests?  This will at least
>> allow users to work around the issue locally.
>
> One issue is that user may not know the property should be used and
> what would be the proper reserved size when run into the stack size
> issue related to TLS. The stack size issue could be hard for average
> users to diagnose.

You could print the requested stack size, stack size reserve, and actual
stack size in the StackOverflowError message.  The fact that there is a
reserve (which would be zero by default) could serve as a hint and
quickly lead to the discovery of the tunable.  At least I hope that.

Thanks,
Florian

From jianglizhou at google.com  Fri May 24 20:29:11 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 24 May 2019 13:29:11 -0700
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <87ftp4tcas.fsf@oldenburg2.str.redhat.com>
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <87ftp4tcas.fsf@oldenburg2.str.redhat.com>
Message-ID: <CALrW1jxB2A9iV-i4vuip2xriH4ZVfHy6-M2eYhrhoOOBYbdY6w@mail.gmail.com>

Hi Florian,

On Fri, May 24, 2019 at 2:46 AM Florian Weimer <fweimer at redhat.com> wrote:
>
> * Jiangli Zhou:
>
> > [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
> > (contributed by Jeremy Manson)
>
> _dl_get_tls_static_info is an internal symbol (it carries a
> GLIBC_PRIVATE symbol version).  Its implementation can change at any
> time.  Please do not do this.

Point taken. Thanks.

It appears that asan is already carrying the same type of fix:

https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc

As the issue has not been able to be addressed in the glibc layer, all
the others have to workaround it (and possibly by using the glibc
private APIs, _dl_get_tls_static_info or __pthread_get_minstack). That
would cause more dependencies on the private APIs.

One alternative (besides fixing glibc) may be making
_dl_get_tls_static_info public. Would that be possible?

Best,

Jiangli
>
> Thanks,
> Florian

From fweimer at redhat.com  Fri May 24 20:50:21 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 24 May 2019 22:50:21 +0200
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <CALrW1jxB2A9iV-i4vuip2xriH4ZVfHy6-M2eYhrhoOOBYbdY6w@mail.gmail.com>
 (Jiangli Zhou's message of "Fri, 24 May 2019 13:29:11 -0700")
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <87ftp4tcas.fsf@oldenburg2.str.redhat.com>
 <CALrW1jxB2A9iV-i4vuip2xriH4ZVfHy6-M2eYhrhoOOBYbdY6w@mail.gmail.com>
Message-ID: <87y32vmvaq.fsf@oldenburg2.str.redhat.com>

* Jiangli Zhou:

> Hi Florian,
>
> On Fri, May 24, 2019 at 2:46 AM Florian Weimer <fweimer at redhat.com> wrote:
>>
>> * Jiangli Zhou:
>>
>> > [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
>> > (contributed by Jeremy Manson)
>>
>> _dl_get_tls_static_info is an internal symbol (it carries a
>> GLIBC_PRIVATE symbol version).  Its implementation can change at any
>> time.  Please do not do this.
>
> Point taken. Thanks.
>
> It appears that asan is already carrying the same type of fix:
>
> https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
>
> As the issue has not been able to be addressed in the glibc layer, all
> the others have to workaround it (and possibly by using the glibc
> private APIs, _dl_get_tls_static_info or __pthread_get_minstack). That
> would cause more dependencies on the private APIs.

_dl_get_tls_static_info changed ABI on i386 in glibc 2.27 already, so
you really don't want to use that (in case someone backported that
cleanup to an earlier version, although that might be bit unlikely).

The sanitizers are special and have a much shorter shelf life than the
OpenJDK binaries.

> One alternative (besides fixing glibc) may be making
> _dl_get_tls_static_info public. Would that be possible?

For __pthread_get_minstack, I can add a comment to the glibc sources
that if the ABI changes (or if TLS allocations are no longer considered
part of the stack), we should rename the function.  Then, as long as you
use a weak reference or dlsym (the latter is preferable for the sack of
RPM-based distributions which require special steps to reference
GLIBC_PRIVATE symbols directly), old binaries would keep working if we
make further changes.

Since _dl_get_tls_static_info already changed ABI once, I really can't
recommend its use.  Especially if you can work with
__pthread_get_minstack instead.

The value of PTHREAD_STACK_MIN is rather problematic on x86-64 (for the
reasons I explained earlier), but it's not likely we are going to change
the value of the constant any time soon.  It's more likely that we are
going to work around the AVX-512 register file issue by providing
exactly four usable stack pages with PTHREAD_STACK_MIN, and not less
than two as we did until recently.  So you can assume that it's indeed
possible to use PTHREAD_STACK_MIN and sysconf (_SC_PAGESIZE) to compute
the static TLS area size.

Thanks,
Florian

From brent.christian at oracle.com  Fri May 24 21:00:43 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 24 May 2019 14:00:43 -0700
Subject: RFR (CSR) - JDK-8223776 String::stripIndent (Preview)
In-Reply-To: <22C33F78-63B8-42C7-A36D-1E420598BC54@oracle.com>
References: <22C33F78-63B8-42C7-A36D-1E420598BC54@oracle.com>
Message-ID: <a2f90d1c-c506-5c49-acad-c2bbb04e52f3@oracle.com>

Hi,

In the description of the re-indentation algorithm, I think it's worth 
clarifying that the last line is always included.  So perhaps:

"3. The last line (i.e., the line with the text block closing delimiter) 
is included in the set of determining lines, even if it is blank. (The 
indentation of the closing delimiter should influence the indentation of 
the content as a whole -- a "significant trailing line" policy.)"

I think the corresponding portion of the JavaDoc is good.

Thanks,
-Brent

On 5/24/19 5:17 AM, Jim Laskey wrote:
> Please do a CSR review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry.
> 
> Thank you.
> 
> -- Jim
> 
> csr: https://bugs.openjdk.java.net/browse/JDK-8223776 <https://bugs.openjdk.java.net/browse/JDK-8223776>
> webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 <http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 <https://bugs.openjdk.java.net/browse/JDK-8223775>
> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>
> 

From joe.darcy at oracle.com  Sat May 25 01:15:54 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 24 May 2019 18:15:54 -0700
Subject: JDK 13 RFR of JDK-8224783: Javadoc of String strip methods uses link
 where linkplain would be better
Message-ID: <52781558-6064-40d5-55bc-f667c59f2e19@oracle.com>

Hello,

Please review the patch below to address:

 ??? JDK-8224783: Javadoc of String strip methods uses link where 
linkplain would be better

Thanks,

-Joe

diff -r 4947a097db60 src/java.base/share/classes/java/lang/String.java
--- a/src/java.base/share/classes/java/lang/String.java??? Fri May 24 
15:06:58 2019 -0400
+++ b/src/java.base/share/classes/java/lang/String.java??? Fri May 24 
18:14:28 2019 -0700
@@ -2690,21 +2690,21 @@

 ???? /**
 ????? * Returns a string whose value is this string, with all leading
-???? * and trailing {@link Character#isWhitespace(int) white space}
+???? * and trailing {@linkplain Character#isWhitespace(int) white space}
 ????? * removed.
 ????? * <p>
 ????? * If this {@code String} object represents an empty string,
 ????? * or if all code points in this string are
-???? * {@link Character#isWhitespace(int) white space}, then an empty 
string
+???? * {@linkplain Character#isWhitespace(int) white space}, then an 
empty string
 ????? * is returned.
 ????? * <p>
 ????? * Otherwise, returns a substring of this string beginning with 
the first
-???? * code point that is not a {@link Character#isWhitespace(int) 
white space}
+???? * code point that is not a {@linkplain Character#isWhitespace(int) 
white space}
 ????? * up to and including the last code point that is not a
-???? * {@link Character#isWhitespace(int) white space}.
+???? * {@linkplain Character#isWhitespace(int) white space}.
 ????? * <p>
 ????? * This method may be used to strip
-???? * {@link Character#isWhitespace(int) white space} from
+???? * {@linkplain Character#isWhitespace(int) white space} from
 ????? * the beginning and end of a string.
 ????? *
 ????? * @return? a string whose value is this string, with all leading
@@ -2722,19 +2722,19 @@

 ???? /**
 ????? * Returns a string whose value is this string, with all leading
-???? * {@link Character#isWhitespace(int) white space} removed.
+???? * {@linkplain Character#isWhitespace(int) white space} removed.
 ????? * <p>
 ????? * If this {@code String} object represents an empty string,
 ????? * or if all code points in this string are
-???? * {@link Character#isWhitespace(int) white space}, then an empty 
string
+???? * {@linkplain Character#isWhitespace(int) white space}, then an 
empty string
 ????? * is returned.
 ????? * <p>
 ????? * Otherwise, returns a substring of this string beginning with 
the first
-???? * code point that is not a {@link Character#isWhitespace(int) 
white space}
+???? * code point that is not a {@linkplain Character#isWhitespace(int) 
white space}
 ????? * up to and including the last code point of this string.
 ????? * <p>
 ????? * This method may be used to trim
-???? * {@link Character#isWhitespace(int) white space} from
+???? * {@linkplain Character#isWhitespace(int) white space} from
 ????? * the beginning of a string.
 ????? *
 ????? * @return? a string whose value is this string, with all leading 
white
@@ -2752,19 +2752,19 @@

 ???? /**
 ????? * Returns a string whose value is this string, with all trailing
-???? * {@link Character#isWhitespace(int) white space} removed.
+???? * {@linkplain Character#isWhitespace(int) white space} removed.
 ????? * <p>
 ????? * If this {@code String} object represents an empty string,
 ????? * or if all characters in this string are
-???? * {@link Character#isWhitespace(int) white space}, then an empty 
string
+???? * {@linkplain Character#isWhitespace(int) white space}, then an 
empty string
 ????? * is returned.
 ????? * <p>
 ????? * Otherwise, returns a substring of this string beginning with 
the first
 ????? * code point of this string up to and including the last code point
-???? * that is not a {@link Character#isWhitespace(int) white space}.
+???? * that is not a {@linkplain Character#isWhitespace(int) white space}.
 ????? * <p>
 ????? * This method may be used to trim
-???? * {@link Character#isWhitespace(int) white space} from
+???? * {@linkplain Character#isWhitespace(int) white space} from
 ????? * the end of a string.
 ????? *
 ????? * @return? a string whose value is this string, with all trailing 
white
@@ -2782,11 +2782,11 @@

 ???? /**
 ????? * Returns {@code true} if the string is empty or contains only
-???? * {@link Character#isWhitespace(int) white space} codepoints,
+???? * {@linkplain Character#isWhitespace(int) white space} codepoints,
 ????? * otherwise {@code false}.
 ????? *
 ????? * @return {@code true} if the string is empty or contains only
-???? *???????? {@link Character#isWhitespace(int) white space} codepoints,
+???? *???????? {@linkplain Character#isWhitespace(int) white space} 
codepoints,
 ????? *???????? otherwise {@code false}
 ????? *
 ????? * @see Character#isWhitespace(int)


From jianglizhou at google.com  Sat May 25 03:35:52 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 24 May 2019 20:35:52 -0700
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <87y32vmvaq.fsf@oldenburg2.str.redhat.com>
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <87ftp4tcas.fsf@oldenburg2.str.redhat.com>
 <CALrW1jxB2A9iV-i4vuip2xriH4ZVfHy6-M2eYhrhoOOBYbdY6w@mail.gmail.com>
 <87y32vmvaq.fsf@oldenburg2.str.redhat.com>
Message-ID: <CALrW1jwJWYtrTi0uxX7hQkkWugmyevpYKjV9_N-sp+PMCSpE7w@mail.gmail.com>

Hi Florian,

On Fri, May 24, 2019 at 1:50 PM Florian Weimer <fweimer at redhat.com> wrote:
>
> * Jiangli Zhou:
>
> > Hi Florian,
> >
> > On Fri, May 24, 2019 at 2:46 AM Florian Weimer <fweimer at redhat.com> wrote:
> >>
> >> * Jiangli Zhou:
> >>
> >> > [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
> >> > (contributed by Jeremy Manson)
> >>
> >> _dl_get_tls_static_info is an internal symbol (it carries a
> >> GLIBC_PRIVATE symbol version).  Its implementation can change at any
> >> time.  Please do not do this.
> >
> > Point taken. Thanks.
> >
> > It appears that asan is already carrying the same type of fix:
> >
> > https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
> >
> > As the issue has not been able to be addressed in the glibc layer, all
> > the others have to workaround it (and possibly by using the glibc
> > private APIs, _dl_get_tls_static_info or __pthread_get_minstack). That
> > would cause more dependencies on the private APIs.
>
> _dl_get_tls_static_info changed ABI on i386 in glibc 2.27 already, so
> you really don't want to use that (in case someone backported that
> cleanup to an earlier version, although that might be bit unlikely).
>
> The sanitizers are special and have a much shorter shelf life than the
> OpenJDK binaries.
>
> > One alternative (besides fixing glibc) may be making
> > _dl_get_tls_static_info public. Would that be possible?
>
> For __pthread_get_minstack, I can add a comment to the glibc sources
> that if the ABI changes (or if TLS allocations are no longer considered
> part of the stack), we should rename the function.  Then, as long as you
> use a weak reference or dlsym (the latter is preferable for the sack of
> RPM-based distributions which require special steps to reference
> GLIBC_PRIVATE symbols directly), old binaries would keep working if we
> make further changes.

Sounds good. Really appreciate for your help from the glibc layer. If
__pthread_get_minstack has more 'stability', I will change the patch
to use it. Jeremy also suggested that when we discussed yesterday.

>
> Since _dl_get_tls_static_info already changed ABI once, I really can't
> recommend its use.  Especially if you can work with
> __pthread_get_minstack instead.
>
> The value of PTHREAD_STACK_MIN is rather problematic on x86-64 (for the
> reasons I explained earlier), but it's not likely we are going to change
> the value of the constant any time soon.  It's more likely that we are
> going to work around the AVX-512 register file issue by providing
> exactly four usable stack pages with PTHREAD_STACK_MIN, and not less
> than two as we did until recently.  So you can assume that it's indeed
> possible to use PTHREAD_STACK_MIN and sysconf (_SC_PAGESIZE) to compute
> the static TLS area size.

Ok. That sounds reassuring.

Best,

Jiangli

>
> Thanks,
> Florian

From ivan.gerasimov at oracle.com  Sat May 25 06:28:03 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 24 May 2019 23:28:03 -0700
Subject: RFR 8224789 : Parsing repetition count in regex does not detect
 numeric overflow
Message-ID: <f91a2861-05b7-cc3e-19d7-c92f9514b914@oracle.com>

Hello!

When Pattern.compile() parses the repetition count in the expressions 
like '.{100}', '.{1,2}' or '.{3,}' it fails to detect numeric overflow 
if the result is still non-negative.

Could you please help review the patch?

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

Also, reading a char at line 3274 is done with skip(), so the exception 
thrown at 3315 displays the position of the error more accurately.

-- 
With kind regards,
Ivan Gerasimov


From lance.andersen at oracle.com  Sat May 25 12:36:00 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sat, 25 May 2019 08:36:00 -0400
Subject: JDK 13 RFR of JDK-8224783: Javadoc of String strip methods uses
 link where linkplain would be better
In-Reply-To: <52781558-6064-40d5-55bc-f667c59f2e19@oracle.com>
References: <52781558-6064-40d5-55bc-f667c59f2e19@oracle.com>
Message-ID: <ED225B03-AB35-45CE-ABBF-9C97E4570046@oracle.com>

+1
> On May 24, 2019, at 9:15 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Please review the patch below to address:
> 
>     JDK-8224783: Javadoc of String strip methods uses link where linkplain would be better
> 
> Thanks,
> 
> -Joe
> 
> diff -r 4947a097db60 src/java.base/share/classes/java/lang/String.java
> --- a/src/java.base/share/classes/java/lang/String.java    Fri May 24 15:06:58 2019 -0400
> +++ b/src/java.base/share/classes/java/lang/String.java    Fri May 24 18:14:28 2019 -0700
> @@ -2690,21 +2690,21 @@
> 
>      /**
>       * Returns a string whose value is this string, with all leading
> -     * and trailing {@link Character#isWhitespace(int) white space}
> +     * and trailing {@linkplain Character#isWhitespace(int) white space}
>       * removed.
>       * <p>
>       * If this {@code String} object represents an empty string,
>       * or if all code points in this string are
> -     * {@link Character#isWhitespace(int) white space}, then an empty string
> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>       * is returned.
>       * <p>
>       * Otherwise, returns a substring of this string beginning with the first
> -     * code point that is not a {@link Character#isWhitespace(int) white space}
> +     * code point that is not a {@linkplain Character#isWhitespace(int) white space}
>       * up to and including the last code point that is not a
> -     * {@link Character#isWhitespace(int) white space}.
> +     * {@linkplain Character#isWhitespace(int) white space}.
>       * <p>
>       * This method may be used to strip
> -     * {@link Character#isWhitespace(int) white space} from
> +     * {@linkplain Character#isWhitespace(int) white space} from
>       * the beginning and end of a string.
>       *
>       * @return  a string whose value is this string, with all leading
> @@ -2722,19 +2722,19 @@
> 
>      /**
>       * Returns a string whose value is this string, with all leading
> -     * {@link Character#isWhitespace(int) white space} removed.
> +     * {@linkplain Character#isWhitespace(int) white space} removed.
>       * <p>
>       * If this {@code String} object represents an empty string,
>       * or if all code points in this string are
> -     * {@link Character#isWhitespace(int) white space}, then an empty string
> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>       * is returned.
>       * <p>
>       * Otherwise, returns a substring of this string beginning with the first
> -     * code point that is not a {@link Character#isWhitespace(int) white space}
> +     * code point that is not a {@linkplain Character#isWhitespace(int) white space}
>       * up to and including the last code point of this string.
>       * <p>
>       * This method may be used to trim
> -     * {@link Character#isWhitespace(int) white space} from
> +     * {@linkplain Character#isWhitespace(int) white space} from
>       * the beginning of a string.
>       *
>       * @return  a string whose value is this string, with all leading white
> @@ -2752,19 +2752,19 @@
> 
>      /**
>       * Returns a string whose value is this string, with all trailing
> -     * {@link Character#isWhitespace(int) white space} removed.
> +     * {@linkplain Character#isWhitespace(int) white space} removed.
>       * <p>
>       * If this {@code String} object represents an empty string,
>       * or if all characters in this string are
> -     * {@link Character#isWhitespace(int) white space}, then an empty string
> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>       * is returned.
>       * <p>
>       * Otherwise, returns a substring of this string beginning with the first
>       * code point of this string up to and including the last code point
> -     * that is not a {@link Character#isWhitespace(int) white space}.
> +     * that is not a {@linkplain Character#isWhitespace(int) white space}.
>       * <p>
>       * This method may be used to trim
> -     * {@link Character#isWhitespace(int) white space} from
> +     * {@linkplain Character#isWhitespace(int) white space} from
>       * the end of a string.
>       *
>       * @return  a string whose value is this string, with all trailing white
> @@ -2782,11 +2782,11 @@
> 
>      /**
>       * Returns {@code true} if the string is empty or contains only
> -     * {@link Character#isWhitespace(int) white space} codepoints,
> +     * {@linkplain Character#isWhitespace(int) white space} codepoints,
>       * otherwise {@code false}.
>       *
>       * @return {@code true} if the string is empty or contains only
> -     *         {@link Character#isWhitespace(int) white space} codepoints,
> +     *         {@linkplain Character#isWhitespace(int) white space} codepoints,
>       *         otherwise {@code false}
>       *
>       * @see Character#isWhitespace(int)
> 

 <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 martinrb at google.com  Sat May 25 19:27:55 2019
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 25 May 2019 12:27:55 -0700
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <CALrW1jwJWYtrTi0uxX7hQkkWugmyevpYKjV9_N-sp+PMCSpE7w@mail.gmail.com>
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <87ftp4tcas.fsf@oldenburg2.str.redhat.com>
 <CALrW1jxB2A9iV-i4vuip2xriH4ZVfHy6-M2eYhrhoOOBYbdY6w@mail.gmail.com>
 <87y32vmvaq.fsf@oldenburg2.str.redhat.com>
 <CALrW1jwJWYtrTi0uxX7hQkkWugmyevpYKjV9_N-sp+PMCSpE7w@mail.gmail.com>
Message-ID: <CA+kOe0-Y=yYuEc3cU3vYs9nknAtDLNUV8q0Dk2Dv1gMTq2+awg@mail.gmail.com>

Very big picture - if we want to banish stack overflows forever, we would
need to migrate the industry to split runtime stacks, which would add a bit
of runtime overhead to every native function call.  No one is heroic enough
to make progress towards that.  Maybe developers of new OSes need to read
this thread?

---
Today, linux kernels run with a variety of libc implementations, so
attempts to use a private glibc symbol might end up looking just like
trying to use a public one, using dlsym at runtime.

---
It seems reasonable to switch from _dl_get_tls_static_info
to __pthread_get_minstack.
One strong hint is that glibc uses that when it needs to create its own
helper thread with minimal stack.
But why-oh-why not expose that for use by others?  Other software like Java
or Rust has the same needs!

  /* The helper thread needs only very little resources.  */
  (void) pthread_attr_setstacksize (&attr,
   __pthread_get_minstack (&attr)
   + 4 * PTHREAD_STACK_MIN);

From Alan.Bateman at oracle.com  Sun May 26 15:05:45 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 26 May 2019 16:05:45 +0100
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <DB7PR02MB51937A87EECD7D1E01F71D098A070@DB7PR02MB5193.eurprd02.prod.outlook.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <a3e64312-d902-b751-d55d-0af1c4c6e3c5@oracle.com>
 <953449f0913340f6a94ae3d83611fd92@sap.com>
 <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>
 <HE1PR0201MB2266326D98F5119796990BFC8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
 <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <fad24c8f-aa40-821e-fa15-9cbe32b0eb76@oracle.com>
 <DB7PR02MB51937A87EECD7D1E01F71D098A070@DB7PR02MB5193.eurprd02.prod.outlook.com>
Message-ID: <62a26037-a991-dc31-a972-a82386f63b92@oracle.com>



On 21/05/2019 16:24, Langer, Christoph wrote:
> Hi Alan,
>
> Thank you for your comments. Here comes the next update... increasing the turnaround time a little bit ??
>
> http://cr.openjdk.java.net/~clanger/webrevs/8213031.10/
I see your other mail with v11 so I switch to that version.

> :
> Ok, makes sense. I've updated the coding such that the zip's file owner would be the default owner, in case it can be retrieved.
I think this is mostly right now. One thing to check is that you are 
catching UOE whereas it's the PAE's cause that might be UOE.
> :
> I have updated the doc in module-info.java quite a bit. Please check.
>
> Is it time to work on the CSR now? How shall we proceed there?
>
The table items in L119-150 look fine, we just need to avoid really long 
lines One minor comment on L123 is that it might be clearer if you drop 
"created" from the sentence.

L48-78 is a "wall of text" and links that I don't think will be easy for 
most developers to read. Can I provide suggested wording for this part 
of the spec? I'm just thinking that an alternative wording might help 
avoid too much iteration on this.

-Alan

From martinrb at google.com  Sun May 26 16:25:39 2019
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 26 May 2019 09:25:39 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
Message-ID: <CA+kOe08hXx1jJ7-5-xAOsUKpzQmDOJAmc5Uw1oeAYZLqcQEhEA@mail.gmail.com>

On Mon, May 13, 2019 at 5:29 PM Stuart Marks <stuart.marks at oracle.com>
wrote:

>
>   - addition of FIXME comment and reference to javadoc bug report, where
> doc
> comment from interface cannot be inherited
>

This is yet another symptom of Java's fundamental design mistake of being
unable to simply inherit implementation, that we have learned to live with.
"Inheritance is not subtyping"

From Alan.Bateman at oracle.com  Sun May 26 18:25:29 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 26 May 2019 19:25:29 +0100
Subject: RFR: 8207851: Implement JEP 352
In-Reply-To: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
Message-ID: <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>

On 23/05/2019 11:55, Andrew Dinn wrote:
> Hi,
>
> Could I please have reviews of the following change set which implements
> JEP 352:
>
> JEP:    https://openjdk.java.net/jeps/352
> JIRA:   https://bugs.openjdk.java.net/browse/JDK-8207851
> webrev: http://cr.openjdk.java.net/~adinn/8207851/webrev.00/
>
> I would also very much like to target this implementation for JDK13.
>
You may want to take a pass over the JEP to make sure that everything is 
accurate. I notice, for example, the section on BufferPoolMXBean has the 
old name READ_ONLY_PERSISTENT. We went through a couple of iterations in 
the discussion here so there might be a few others.

I think the API changes are okay. I don't see a CSR yet but I assume 
you'll get to that soon.

I've read through the changes to java.base and jdk.unsupported.

Just a few minor points:

- I assume the update FileChannel.java should be dropped as it's just a 
left over from when we agreed to split out the updates to the Java SE API.

- com.sun.nio.file.ExtendedMapMode.*_SYNC are missing javadoc, or rather 
the descriptions are truncated with "...". I think this dates from when 
were working out the right place to expose these constants. The source 
file (and the internal ExtendedMapModes are missing copyright headers too).

- We didn't discuss the name of the buffer pool that is exposed through 
the JMX/management interface. We could take inspiration from the names 
of the CodeHeap spaces that are exposed with MemoryPoolMXBeans as there 
is an established convention for naming there, e.g. "mapped - 
'non-volatile memory'".

- Minor nit in Unmapper is that the methods to increment/decrement the 
usage should use Java conventions so probably should be incrementUsage 
and decrementUsage.

- PmemTest. This is awkward and I wonder if it should be @run 
main/manual rather than @ignore. Also `@modules jdk.unsupported` would 
be useful to ensure it will be skipped if run with a test JDK that 
doesn't have this module.

-Alan

From christoph.langer at sap.com  Sun May 26 20:54:45 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sun, 26 May 2019 20:54:45 +0000
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <62a26037-a991-dc31-a972-a82386f63b92@oracle.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <a3e64312-d902-b751-d55d-0af1c4c6e3c5@oracle.com>
 <953449f0913340f6a94ae3d83611fd92@sap.com>
 <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>
 <HE1PR0201MB2266326D98F5119796990BFC8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
 <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <fad24c8f-aa40-821e-fa15-9cbe32b0eb76@oracle.com>
 <DB7PR02MB51937A87EECD7D1E01F71D098A070@DB7PR02MB5193.eurprd02.prod.outlook.com>
 <62a26037-a991-dc31-a972-a82386f63b92@oracle.com>
Message-ID: <AM6PR02MB5192400CF12E423CA64C0A458A1C0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Alan,

> > http://cr.openjdk.java.net/~clanger/webrevs/8213031.10/
> I see your other mail with v11 so I switch to that version.

Right. ??

> > Ok, makes sense. I've updated the coding such that the zip's file owner
> would be the default owner, in case it can be retrieved.
> I think this is mostly right now. One thing to check is that you are
> catching UOE whereas it's the PAE's cause that might be UOE.

It's alright as it is. If you look at the source of AccessController.doPrivileged for a PrivilegedExceptionAction, you will see that RuntimeExceptions are caught and rethrown, not yielding a PAE. So I must catch UOE here explicitly because it's a RuntimeException.

> > :
> > I have updated the doc in module-info.java quite a bit. Please check.
> >
> > Is it time to work on the CSR now? How shall we proceed there?
> >
> The table items in L119-150 look fine, we just need to avoid really long
> lines One minor comment on L123 is that it might be clearer if you drop
> "created" from the sentence.
> 
> L48-78 is a "wall of text" and links that I don't think will be easy for
> most developers to read. Can I provide suggested wording for this part
> of the spec? I'm just thinking that an alternative wording might help
> avoid too much iteration on this.

Sure, you're very welcome ??

So, I'll be waiting for your input on that.

Thanks
Christoph


From peter.levart at gmail.com  Mon May 27 08:35:33 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 27 May 2019 10:35:33 +0200
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <CA+kOe08hXx1jJ7-5-xAOsUKpzQmDOJAmc5Uw1oeAYZLqcQEhEA@mail.gmail.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <CA+kOe08hXx1jJ7-5-xAOsUKpzQmDOJAmc5Uw1oeAYZLqcQEhEA@mail.gmail.com>
Message-ID: <876036be-ce3a-70e6-0762-3d02d1789b3f@gmail.com>



On 5/26/19 6:25 PM, Martin Buchholz wrote:
> On Mon, May 13, 2019 at 5:29 PM Stuart Marks <stuart.marks at oracle.com>
> wrote:
>
>>    - addition of FIXME comment and reference to javadoc bug report, where
>> doc
>> comment from interface cannot be inherited
>>
> This is yet another symptom of Java's fundamental design mistake of being
> unable to simply inherit implementation, that we have learned to live with.
> "Inheritance is not subtyping"

One way of inheriting "only implementation" is to have a package-private 
superclass with public methods. (AbstractStringBuilder for example). It 
confines all implementations (subclasses) to the same package though, so 
it is not a universal tool. With jigsaw there is another possibility: a 
public but internal (confined) superclass which is exported just to 
modules that need to subclass it.

Regards, Peter


From fweimer at redhat.com  Mon May 27 09:07:28 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 27 May 2019 11:07:28 +0200
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <CA+kOe0-Y=yYuEc3cU3vYs9nknAtDLNUV8q0Dk2Dv1gMTq2+awg@mail.gmail.com>
 (Martin Buchholz's message of "Sat, 25 May 2019 12:27:55 -0700")
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <87ftp4tcas.fsf@oldenburg2.str.redhat.com>
 <CALrW1jxB2A9iV-i4vuip2xriH4ZVfHy6-M2eYhrhoOOBYbdY6w@mail.gmail.com>
 <87y32vmvaq.fsf@oldenburg2.str.redhat.com>
 <CALrW1jwJWYtrTi0uxX7hQkkWugmyevpYKjV9_N-sp+PMCSpE7w@mail.gmail.com>
 <CA+kOe0-Y=yYuEc3cU3vYs9nknAtDLNUV8q0Dk2Dv1gMTq2+awg@mail.gmail.com>
Message-ID: <87r28kl0z3.fsf@oldenburg2.str.redhat.com>

* Martin Buchholz:

> Very big picture - if we want to banish stack overflows forever, we would
> need to migrate the industry to split runtime stacks, which would add a bit
> of runtime overhead to every native function call.  No one is heroic enough
> to make progress towards that.  Maybe developers of new OSes need to read
> this thread?

For an infinite recursion, you would still get an OutOfMemoryError, only
much later and potentially after taking down the desktop environment.

Furthermore, if the thread stack is not committed memory, then
try-finally blocks will not work reliably because any function call may
attempt to enlarge the stack and fail to do so.

> One strong hint is that glibc uses that when it needs to create its own
> helper thread with minimal stack.
> But why-oh-why not expose that for use by others?  Other software like Java
> or Rust has the same needs!

Creating a stack with __pthread_get_minstack() bytes doesn't mean the
thread can do anything useful.  For example, the thread will not on a
kernel with a vDSO compiled with -fstack-check.  You can can't call
(f)printf on a file stream which is unbuffered.  The thread may not be
able to receive any signals whatsoever.  And so on.  That's why it's not
a public interface.

I suggested to use this interface only as a workaround for the TLS
allocation issue.

Thanks,
Florian

From sundararajan.athijegannathan at oracle.com  Mon May 27 09:18:11 2019
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 27 May 2019 14:48:11 +0530
Subject: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules element
 from file path
Message-ID: <5CEBAB53.9020307@oracle.com>

Please review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8216553
Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/

Thanks,
-Sundar



From james.laskey at oracle.com  Mon May 27 11:58:50 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 27 May 2019 08:58:50 -0300
Subject: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules
 element from file path
In-Reply-To: <5CEBAB53.9020307@oracle.com>
References: <5CEBAB53.9020307@oracle.com>
Message-ID: <95D3E742-AE89-4C6F-9AE3-97128ECC4F3E@oracle.com>

+1


> On May 27, 2019, at 6:18 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8216553
> Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/
> 
> Thanks,
> -Sundar
> 
> 


From Alan.Bateman at oracle.com  Mon May 27 12:07:23 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 May 2019 13:07:23 +0100
Subject: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules
 element from file path
In-Reply-To: <5CEBAB53.9020307@oracle.com>
References: <5CEBAB53.9020307@oracle.com>
Message-ID: <7fa024a3-bc38-4cb7-8493-f9e59b26e762@oracle.com>

On 27/05/2019 10:18, Sundararajan Athijegannathan wrote:
> Please review.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8216553
> Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/
This addresses the points we discussed in the JIRA issue so I think it 
looks good.

-Alan

From james.laskey at oracle.com  Mon May 27 13:11:42 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 27 May 2019 10:11:42 -0300
Subject: RFR (CSR) - JDK-8223776 String::stripIndent (Preview)
In-Reply-To: <a2f90d1c-c506-5c49-acad-c2bbb04e52f3@oracle.com>
References: <22C33F78-63B8-42C7-A36D-1E420598BC54@oracle.com>
 <a2f90d1c-c506-5c49-acad-c2bbb04e52f3@oracle.com>
Message-ID: <66CB7ACE-A4B3-4D11-AED6-355804DDBCD1@oracle.com>

I think I have to leave it as is, since the Javadoc will become THE spec for text blocks, i.e., there is a direct correspondence between the JavaDoc and the JEP.

> On May 24, 2019, at 6:00 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Hi,
> 
> In the description of the re-indentation algorithm, I think it's worth clarifying that the last line is always included.  So perhaps:
> 
> "3. The last line (i.e., the line with the text block closing delimiter) is included in the set of determining lines, even if it is blank. (The indentation of the closing delimiter should influence the indentation of the content as a whole -- a "significant trailing line" policy.)"
> 
> I think the corresponding portion of the JavaDoc is good.
> 
> Thanks,
> -Brent
> 
> On 5/24/19 5:17 AM, Jim Laskey wrote:
>> Please do a CSR review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry.
>> Thank you.
>> -- Jim
>> csr: https://bugs.openjdk.java.net/browse/JDK-8223776 <https://bugs.openjdk.java.net/browse/JDK-8223776>
>> webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 <http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02>
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 <https://bugs.openjdk.java.net/browse/JDK-8223775>
>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>


From james.laskey at oracle.com  Mon May 27 13:12:51 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 27 May 2019 10:12:51 -0300
Subject: JDK 13 RFR of JDK-8224783: Javadoc of String strip methods uses
 link where linkplain would be better
In-Reply-To: <52781558-6064-40d5-55bc-f667c59f2e19@oracle.com>
References: <52781558-6064-40d5-55bc-f667c59f2e19@oracle.com>
Message-ID: <60822501-EC4E-49F6-828B-89FBE918BD24@oracle.com>

+1

> On May 24, 2019, at 10:15 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Please review the patch below to address:
> 
>     JDK-8224783: Javadoc of String strip methods uses link where linkplain would be better
> 
> Thanks,
> 
> -Joe
> 
> diff -r 4947a097db60 src/java.base/share/classes/java/lang/String.java
> --- a/src/java.base/share/classes/java/lang/String.java    Fri May 24 15:06:58 2019 -0400
> +++ b/src/java.base/share/classes/java/lang/String.java    Fri May 24 18:14:28 2019 -0700
> @@ -2690,21 +2690,21 @@
> 
>      /**
>       * Returns a string whose value is this string, with all leading
> -     * and trailing {@link Character#isWhitespace(int) white space}
> +     * and trailing {@linkplain Character#isWhitespace(int) white space}
>       * removed.
>       * <p>
>       * If this {@code String} object represents an empty string,
>       * or if all code points in this string are
> -     * {@link Character#isWhitespace(int) white space}, then an empty string
> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>       * is returned.
>       * <p>
>       * Otherwise, returns a substring of this string beginning with the first
> -     * code point that is not a {@link Character#isWhitespace(int) white space}
> +     * code point that is not a {@linkplain Character#isWhitespace(int) white space}
>       * up to and including the last code point that is not a
> -     * {@link Character#isWhitespace(int) white space}.
> +     * {@linkplain Character#isWhitespace(int) white space}.
>       * <p>
>       * This method may be used to strip
> -     * {@link Character#isWhitespace(int) white space} from
> +     * {@linkplain Character#isWhitespace(int) white space} from
>       * the beginning and end of a string.
>       *
>       * @return  a string whose value is this string, with all leading
> @@ -2722,19 +2722,19 @@
> 
>      /**
>       * Returns a string whose value is this string, with all leading
> -     * {@link Character#isWhitespace(int) white space} removed.
> +     * {@linkplain Character#isWhitespace(int) white space} removed.
>       * <p>
>       * If this {@code String} object represents an empty string,
>       * or if all code points in this string are
> -     * {@link Character#isWhitespace(int) white space}, then an empty string
> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>       * is returned.
>       * <p>
>       * Otherwise, returns a substring of this string beginning with the first
> -     * code point that is not a {@link Character#isWhitespace(int) white space}
> +     * code point that is not a {@linkplain Character#isWhitespace(int) white space}
>       * up to and including the last code point of this string.
>       * <p>
>       * This method may be used to trim
> -     * {@link Character#isWhitespace(int) white space} from
> +     * {@linkplain Character#isWhitespace(int) white space} from
>       * the beginning of a string.
>       *
>       * @return  a string whose value is this string, with all leading white
> @@ -2752,19 +2752,19 @@
> 
>      /**
>       * Returns a string whose value is this string, with all trailing
> -     * {@link Character#isWhitespace(int) white space} removed.
> +     * {@linkplain Character#isWhitespace(int) white space} removed.
>       * <p>
>       * If this {@code String} object represents an empty string,
>       * or if all characters in this string are
> -     * {@link Character#isWhitespace(int) white space}, then an empty string
> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>       * is returned.
>       * <p>
>       * Otherwise, returns a substring of this string beginning with the first
>       * code point of this string up to and including the last code point
> -     * that is not a {@link Character#isWhitespace(int) white space}.
> +     * that is not a {@linkplain Character#isWhitespace(int) white space}.
>       * <p>
>       * This method may be used to trim
> -     * {@link Character#isWhitespace(int) white space} from
> +     * {@linkplain Character#isWhitespace(int) white space} from
>       * the end of a string.
>       *
>       * @return  a string whose value is this string, with all trailing white
> @@ -2782,11 +2782,11 @@
> 
>      /**
>       * Returns {@code true} if the string is empty or contains only
> -     * {@link Character#isWhitespace(int) white space} codepoints,
> +     * {@linkplain Character#isWhitespace(int) white space} codepoints,
>       * otherwise {@code false}.
>       *
>       * @return {@code true} if the string is empty or contains only
> -     *         {@link Character#isWhitespace(int) white space} codepoints,
> +     *         {@linkplain Character#isWhitespace(int) white space} codepoints,
>       *         otherwise {@code false}
>       *
>       * @see Character#isWhitespace(int)
> 


From pavel.rappo at oracle.com  Mon May 27 15:38:00 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 27 May 2019 16:38:00 +0100
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <CA+kOe08hXx1jJ7-5-xAOsUKpzQmDOJAmc5Uw1oeAYZLqcQEhEA@mail.gmail.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <CA+kOe08hXx1jJ7-5-xAOsUKpzQmDOJAmc5Uw1oeAYZLqcQEhEA@mail.gmail.com>
Message-ID: <103800D4-06C9-49FE-9DFD-7C4D5CDF0DDE@oracle.com>

Would you care to elaborate on that? As far as I understand Stuart was simply
working around javadoc's bug in the "Copying of Method Comments" algorithm.

> On 26 May 2019, at 17:25, Martin Buchholz <martinrb at google.com> wrote:
> 
> This is yet another symptom of Java's fundamental design mistake of being
> unable to simply inherit implementation, that we have learned to live with.
> "Inheritance is not subtyping"


From Alan.Bateman at oracle.com  Mon May 27 19:44:54 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 May 2019 20:44:54 +0100
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <AM6PR02MB5192400CF12E423CA64C0A458A1C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <a3e64312-d902-b751-d55d-0af1c4c6e3c5@oracle.com>
 <953449f0913340f6a94ae3d83611fd92@sap.com>
 <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>
 <HE1PR0201MB2266326D98F5119796990BFC8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
 <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <fad24c8f-aa40-821e-fa15-9cbe32b0eb76@oracle.com>
 <DB7PR02MB51937A87EECD7D1E01F71D098A070@DB7PR02MB5193.eurprd02.prod.outlook.com>
 <62a26037-a991-dc31-a972-a82386f63b92@oracle.com>
 <AM6PR02MB5192400CF12E423CA64C0A458A1C0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <9cba070d-2fa1-c55d-9826-d526c91f5be6@oracle.com>

On 26/05/2019 21:54, Langer, Christoph wrote:
> :
> It's alright as it is. If you look at the source of AccessController.doPrivileged for a PrivilegedExceptionAction, you will see that RuntimeExceptions are caught and rethrown, not yielding a PAE. So I must catch UOE here explicitly because it's a RuntimeException.
Ah yes, this isn't the first time I forgot that.

> :
> So, I'll be waiting for your input on that.
On my list, I hope we should be agree the spec wording this week as this 
feature has been under discussion here for a long time.

-Alan


From ivan.gerasimov at oracle.com  Tue May 28 06:18:04 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 27 May 2019 23:18:04 -0700
Subject: RFR - JDK-8223780 String::translateEscapes (Preview)
In-Reply-To: <FFE10AB9-B2FB-402A-B24E-62D7E6B3C2FF@oracle.com>
References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>
 <abfcefd9-46f5-a49e-cf53-ed5930a04034@oracle.com>
 <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com>
 <FFE10AB9-B2FB-402A-B24E-62D7E6B3C2FF@oracle.com>
Message-ID: <ed926439-991d-206f-c0c3-b80d73dfb233@oracle.com>

Hi Jim!

I wonder why it was chosen to represent octal values as \[0-3][0-9][0-9] 
| \[0-9][0-9] | \[0-9] ?

First, it will allow multiple leading zeroes.

Second, it does not require a leading zero, while, I think, many users 
are used to octal numbers starting with a mandatory leading zero.

Was it considered to mirror the syntax from regex [1] ?

[1] 
https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/regex/Pattern.html#sum

With kind regards,

Ivan


On 5/21/19 12:24 PM, Jim Laskey wrote:
> Revised at 
> http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html 
> <http://cr.openjdk.java.net/%7Ejlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html> 
>
>
>
>
>> On May 21, 2019, at 3:23 PM, Jim Laskey <james.laskey at oracle.com 
>> <mailto:james.laskey at oracle.com>> wrote:
>>
>>
>>
>>> On May 21, 2019, at 2:57 PM, Ivan Gerasimov 
>>> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>>>
>>> Hi Jim!
>>>
>>> A few comments:
>>>
>>> 1)
>>> Probably, there's no need to update ch in these cases:
>>>               case '\'':
>>>                   ch = '\'';
>>>                   break;
>>>               case '\"':
>>>                   ch = '\"';
>>>                   break;
>>
>> True
>>
>>>
>>> 2)
>>> Character.digit(ch, 8) will accept non-Latin1 digits.
>>> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377.
>>> (Note, that the first digit still can only be from range '0'-'9').
>>
>> Also true. Subtlety in UnicodeReader.
>>
>>>
>>> 3)
>>> It's not obvious how this condition can be triggered:
>>>                   if (0377 < code) {
>>>                       throw new MalformedEscapeException(from);
>>>                   }
>>> I might be missing something, but I cannot see how 'code' can become 
>>> > 0377.
>>
>> I removed this check in round 2.
>>
>>>
>>> 4)
>>> throw new MalformedEscapeException(from);
>>> This will report the next index after the error.  Was it intentional?
>>>
>>
>> I switched to using an IllegalArgumentError and displaying the actual 
>> character.
>>
>>
>>> With kind regards,
>>> Ivan
>>
>> Much thanks.
>>
>>
>>>
>>>
>>> On 5/21/19 7:56 AM, Jim Laskey wrote:
>>>> Please do a code review of the new String:: translateEscapes 
>>>> instance method. This instance method is being introduced to 
>>>> support JEP-355: Text Blocks, by translating escape sequences in 
>>>> the text block content.
>>>>
>>>> Thank you.
>>>>
>>>> -- Jim
>>>>
>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 
>>>> <http://cr.openjdk.java.net/%7Ejlaskey/8223780/webrev-01> 
>>>> <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 
>>>> <http://cr.openjdk.java.net/%7Ejlaskey/8223780/webrev-01>>
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8223780>
>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8223781>
>>>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8222530>
>>>>
>>>>
>>>
>>> -- 
>>> With kind regards,
>>> Ivan Gerasimov
>>>
>>
>

-- 
With kind regards,
Ivan Gerasimov


From sundararajan.athijegannathan at oracle.com  Tue May 28 09:48:33 2019
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 28 May 2019 15:18:33 +0530
Subject: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules
 element from file path
In-Reply-To: <7fa024a3-bc38-4cb7-8493-f9e59b26e762@oracle.com>
References: <5CEBAB53.9020307@oracle.com>
 <7fa024a3-bc38-4cb7-8493-f9e59b26e762@oracle.com>
Message-ID: <5CED03F1.7020908@oracle.com>

Updated for java test failures:

https://cr.openjdk.java.net/~sundar/8216553/webrev.01/

PS. Test framework used wrong jrt: URI pattern. Fixed it.

-Sundar

On 27/05/19, 5:37 PM, Alan Bateman wrote:
> On 27/05/2019 10:18, Sundararajan Athijegannathan wrote:
>> Please review.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8216553
>> Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/
> This addresses the points we discussed in the JIRA issue so I think it 
> looks good.
>
> -Alan

From james.laskey at oracle.com  Tue May 28 11:30:12 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 28 May 2019 08:30:12 -0300
Subject: RFR 8216553: JrtFIleSystemProvider getPath(URI) omits /modules
 element from file path
In-Reply-To: <5CED03F1.7020908@oracle.com>
References: <5CEBAB53.9020307@oracle.com>
 <7fa024a3-bc38-4cb7-8493-f9e59b26e762@oracle.com>
 <5CED03F1.7020908@oracle.com>
Message-ID: <E82B1698-8A51-499B-BB53-1326DDEAE825@oracle.com>

+1

> On May 28, 2019, at 6:48 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Updated for java test failures:
> 
> https://cr.openjdk.java.net/~sundar/8216553/webrev.01/
> 
> PS. Test framework used wrong jrt: URI pattern. Fixed it.
> 
> -Sundar
> 
> On 27/05/19, 5:37 PM, Alan Bateman wrote:
>> On 27/05/2019 10:18, Sundararajan Athijegannathan wrote:
>>> Please review.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8216553
>>> Webrev: https://cr.openjdk.java.net/~sundar/8216553/webrev.00/
>> This addresses the points we discussed in the JIRA issue so I think it looks good.
>> 
>> -Alan


From james.laskey at oracle.com  Tue May 28 11:43:32 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 28 May 2019 08:43:32 -0300
Subject: RFR - JDK-8223780 String::translateEscapes (Preview)
In-Reply-To: <ed926439-991d-206f-c0c3-b80d73dfb233@oracle.com>
References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com>
 <abfcefd9-46f5-a49e-cf53-ed5930a04034@oracle.com>
 <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com>
 <FFE10AB9-B2FB-402A-B24E-62D7E6B3C2FF@oracle.com>
 <ed926439-991d-206f-c0c3-b80d73dfb233@oracle.com>
Message-ID: <05F974A6-202D-40F5-A331-736BD4AF4B07@oracle.com>

It is critical to replicate what the javac compiler is doing presently, otherwise we break existing code.

    char leadch = reader.ch;
    int oct = reader.digit(pos, 8);
    reader.scanChar();
    if ('0' <= reader.ch && reader.ch <= '7') {
        oct = oct * 8 + reader.digit(pos, 8);
        reader.scanChar();
        if (leadch <= '3' && '0' <= reader.ch && reader.ch <= '7') {
            oct = oct * 8 + reader.digit(pos, 8);
            reader.scanChar();
        }
    }

If you look at the JSL 3.10.6, this is also the pattern used.

OctalEscape:
    \ OctalDigit
    \ OctalDigit OctalDigit
    \ ZeroToThree OctalDigit OctalDigit

Cheers,

-- Jim



> On May 28, 2019, at 3:18 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> Hi Jim!
> 
> I wonder why it was chosen to represent octal values as \[0-3][0-9][0-9] | \[0-9][0-9] | \[0-9] ?
> 
> First, it will allow multiple leading zeroes.
> 
> Second, it does not require a leading zero, while, I think, many users are used to octal numbers starting with a mandatory leading zero.
> 
> Was it considered to mirror the syntax from regex [1] ?
> 
> [1] https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/regex/Pattern.html#sum <https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/regex/Pattern.html#sum>
> With kind regards,
> 
> Ivan
> 
> 
> On 5/21/19 12:24 PM, Jim Laskey wrote:
>> Revised at http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html <http://cr.openjdk.java.net/%7Ejlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html>
>> 
>> 
>> 
>>> On May 21, 2019, at 3:23 PM, Jim Laskey <james.laskey at oracle.com <mailto:james.laskey at oracle.com>> wrote:
>>> 
>>> 
>>> 
>>>> On May 21, 2019, at 2:57 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>>>> 
>>>> Hi Jim!
>>>> 
>>>> A few comments:
>>>> 
>>>> 1)
>>>> Probably, there's no need to update ch in these cases:
>>>>               case '\'':
>>>>                   ch = '\'';
>>>>                   break;
>>>>               case '\"':
>>>>                   ch = '\"';
>>>>                   break;
>>> 
>>> True
>>> 
>>>> 
>>>> 2)
>>>> Character.digit(ch, 8) will accept non-Latin1 digits.
>>>> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377.
>>>> (Note, that the first digit still can only be from range '0'-'9').
>>> 
>>> Also true. Subtlety in UnicodeReader.
>>> 
>>>> 
>>>> 3)
>>>> It's not obvious how this condition can be triggered:
>>>>                   if (0377 < code) {
>>>>                       throw new MalformedEscapeException(from);
>>>>                   }
>>>> I might be missing something, but I cannot see how 'code' can become > 0377.
>>> 
>>> I removed this check in round 2.
>>> 
>>>> 
>>>> 4)
>>>> throw new MalformedEscapeException(from);
>>>> This will report the next index after the error.  Was it intentional?
>>>> 
>>> 
>>> I switched to using an IllegalArgumentError and displaying the actual character.
>>> 
>>> 
>>>> With kind regards,
>>>> Ivan
>>> 
>>> Much thanks.
>>> 
>>> 
>>>> 
>>>> 
>>>> On 5/21/19 7:56 AM, Jim Laskey wrote:
>>>>> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content.
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> -- Jim
>>>>> 
>>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 <http://cr.openjdk.java.net/%7Ejlaskey/8223780/webrev-01> <http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 <http://cr.openjdk.java.net/%7Ejlaskey/8223780/webrev-01>>
>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 <https://bugs.openjdk.java.net/browse/JDK-8223780> <https://bugs.openjdk.java.net/browse/JDK-8223780 <https://bugs.openjdk.java.net/browse/JDK-8223780>>
>>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 <https://bugs.openjdk.java.net/browse/JDK-8223781> <https://bugs.openjdk.java.net/browse/JDK-8223781 <https://bugs.openjdk.java.net/browse/JDK-8223781>>
>>>>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530> <https://bugs.openjdk.java.net/browse/JDK-8222530 <https://bugs.openjdk.java.net/browse/JDK-8222530>>
>>>>> 
>>>>> 
>>>> 
>>>> -- 
>>>> With kind regards,
>>>> Ivan Gerasimov
>>>> 
>>> 
>> 
> 
> -- 
> With kind regards,
> Ivan Gerasimov


From adinn at redhat.com  Tue May 28 15:00:39 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 28 May 2019 16:00:39 +0100
Subject: RFR: 8207851: Implement JEP 352
In-Reply-To: <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
Message-ID: <f77da070-529b-d1d4-4b34-7f0c02794c39@redhat.com>

Hi Alan,

Thank you for the review.

On 26/05/2019 19:25, Alan Bateman wrote:

> You may want to take a pass over the JEP to make sure that everything is
> accurate. I notice, for example, the section on BufferPoolMXBean has the
> old name READ_ONLY_PERSISTENT. We went through a couple of iterations in
> the discussion here so there might be a few others.

Thanks for spotting that. I corrected several wrong mentions of
PERSISTENT instead of SYNC. I also coerced a mention of MAP_SYNC to
render using a fixed width font.

I also updated the description of the exception signature changes to
FileChannel.map to explain how they will correlate with specific cases
handled by this JEP implementation (or, rather, cases that are
explicitly not handled by the implementation).

Finally I updated the MXBean name as you suggested (see below).

> I think the API changes are okay. I don't see a CSR yet but I assume
> you'll get to that soon.

Yes, I'll raise one ASAP. Could you clarify  what changes I need to
document in the CSR? Here are my current thoughts:

ManagementFactoryHelper/FileChannelImpl
I am assuming the change that exposes the new MXBean needs to be
mentioned somwehere. However, that change doesn't actually affect any
API. It just means that a new bean with a new name appears in the list
of memory beans. I don't see anything which documents those bean names.
Am I missing something? (probably :).

com/sun/nio/file/ExtendedMapMode (in jdk.unsupported)

I'm assuming the CSR needs to propose javadoc for the 2 exposed MapMode
values, explaining what these modes are used for and which exceptions
documented in FileChannel.map get thrown for the cases where their use
is unsupported by the JVM or the OS, respectively. Is that correct?

jdk/internal/misc/ExtendedMapMode (in java.base)

Do I need to provide javadoc for the two new MapMode values and include
them in the CSR? I was assuming not.

FileChannelImpl method map
The javadoc in FileChannel lists the new exceptions that might be thrown
by this implementation but does not mention any specifics to say how
they might relate to use of the XXX_SYNC MapModes. Do I need to propose
updates for the FileChannel javadoc in the CSR or am I ok to provide
that detail in the doc for com/sun/nio/file/ExtendedMapMode?

Unsafe method writebackMemory
I was assuming Unsafe.writebackMemory is internal to the JDK so does not
need a mention in the CSR. Is that correct?

> I've read through the changes to java.base and jdk.unsupported.
> 
> Just a few minor points:
> 
> - I assume the update FileChannel.java should be dropped as it's just a
> left over from when we agreed to split out the updates to the Java SE API.

Yes, that is a leftover. It has been removed from the latest patch.

> - com.sun.nio.file.ExtendedMapMode.*_SYNC are missing javadoc, or rather
> the descriptions are truncated with "...". I think this dates from when
> were working out the right place to expose these constants. The source
> file (and the internal ExtendedMapModes are missing copyright headers too).

Thanks, I have added javadoc comments.

> - We didn't discuss the name of the buffer pool that is exposed through
> the JMX/management interface. We could take inspiration from the names
> of the CodeHeap spaces that are exposed with MemoryPoolMXBeans as there
> is an established convention for naming there, e.g. "mapped -
> 'non-volatile memory'".

The JEP used the name mapped_persistent" while the code named it
mapped_sync. I have changed both to use the name "mapped - 'non-volatile
memory'". Does this need further discussion by other parties? Or is that
a final decision?

> - Minor nit in Unmapper is that the methods to increment/decrement the
> usage should use Java conventions so probably should be incrementUsage
> and decrementUsage.

Caught me red-handed. Also fixed.

> - PmemTest. This is awkward and I wonder if it should be @run
> main/manual rather than @ignore. Also `@modules jdk.unsupported` would
> be useful to ensure it will be skipped if run with a test JDK that
> doesn't have this module.
Yes, I agree that @run main/manual is far better than @ignore and the
@modules requirement is also a very good idea. I have updated both.

New webrev: http://cr.openjdk.java.net/~adinn/8207851/webrev.01


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  Tue May 28 16:14:03 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 May 2019 17:14:03 +0100
Subject: RFR: 8207851: Implement JEP 352
In-Reply-To: <f77da070-529b-d1d4-4b34-7f0c02794c39@redhat.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@redhat.com>
Message-ID: <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com>

On 28/05/2019 16:00, Andrew Dinn wrote:
> :
> Yes, I'll raise one ASAP. Could you clarify  what changes I need to
> document in the CSR? Here are my current thoughts:
>
> ManagementFactoryHelper/FileChannelImpl
> I am assuming the change that exposes the new MXBean needs to be
> mentioned somwehere. However, that change doesn't actually affect any
> API. It just means that a new bean with a new name appears in the list
> of memory beans. I don't see anything which documents those bean names.
> Am I missing something? (probably :).
It's not the main event but I think useful to list it in the CSR. You 
are right that the existing "direct" and "mapped" aren't documented 
anywhere but it wouldn't be too surprising to find tools that rely on them.

>
> com/sun/nio/file/ExtendedMapMode (in jdk.unsupported)
>
> I'm assuming the CSR needs to propose javadoc for the 2 exposed MapMode
> values, explaining what these modes are used for and which exceptions
> documented in FileChannel.map get thrown for the cases where their use
> is unsupported by the JVM or the OS, respectively. Is that correct?
Yes, including the javadoc for the class and the two new map modes. The 
javadoc for both modes can reference the UOE thrown by FileChannel.map 
when the mode is not supported.


>
> jdk/internal/misc/ExtendedMapMode (in java.base)
>
> Do I need to provide javadoc for the two new MapMode values and include
> them in the CSR? I was assuming not.
Right, it's JDK internal so no need to list that.

>
> FileChannelImpl method map
> The javadoc in FileChannel lists the new exceptions that might be thrown
> by this implementation but does not mention any specifics to say how
> they might relate to use of the XXX_SYNC MapModes. Do I need to propose
> updates for the FileChannel javadoc in the CSR or am I ok to provide
> that detail in the doc for com/sun/nio/file/ExtendedMapMode?
JDK-8221397 had the "enabling" changes so no changes to FileChannel.map, 
just the reference from ExtendedMapMode.


>
> Unsafe method writebackMemory
> I was assuming Unsafe.writebackMemory is internal to the JDK so does not
> need a mention in the CSR. Is that correct?
That's right.

-Alan

From ivan.gerasimov at oracle.com  Tue May 28 16:33:09 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 28 May 2019 09:33:09 -0700
Subject: RFR 8224849 : Flag (?U:...) is allowed for non-capturing groups
Message-ID: <d0947a69-2d25-dca1-0177-035137e14ed8@oracle.com>

Hello!

When the fix for JDK-7039066 (which added support for the flag 
UNICODE_CHARACTER_CLASS and corresponding embedded expression (?U)) was 
integrated back in JDK 7, the documentation for the non-capturing groups 
was not updated accordingly.

Would you please help review the fix, which only updates the javadoc?

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

Thanks in advance!

-- 
With kind regards,
Ivan Gerasimov


From Roger.Riggs at oracle.com  Tue May 28 16:33:27 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 28 May 2019 12:33:27 -0400
Subject: RFR 8224789 : Parsing repetition count in regex does not detect
 numeric overflow
In-Reply-To: <f91a2861-05b7-cc3e-19d7-c92f9514b914@oracle.com>
References: <f91a2861-05b7-cc3e-19d7-c92f9514b914@oracle.com>
Message-ID: <4f430138-d705-20d0-3b6a-cf9b356b2067@oracle.com>

Hi Ivan,

test/jdk/java/util/regex/RegExTest.java:

4954: The test should print the failing exception information and
4951: a message if the Pattern.compile does not fail to distinguish that 
failure from any others.

I don't think there is a need for so many cases of values > 2^31; there 
is no different code path for all those values.
They are fairly cheap, but redundant.

Otherwise, looks fine.

Thanks, Roger


On 05/25/2019 02:28 AM, Ivan Gerasimov wrote:
> Hello!
>
> When Pattern.compile() parses the repetition count in the expressions 
> like '.{100}', '.{1,2}' or '.{3,}' it fails to detect numeric overflow 
> if the result is still non-negative.
>
> Could you please help review the patch?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8224789
> WEBREV: http://cr.openjdk.java.net/~igerasim/8224789/00/webrev/
>
> Also, reading a char at line 3274 is done with skip(), so the 
> exception thrown at 3315 displays the position of the error more 
> accurately.
>


From martinrb at google.com  Tue May 28 16:50:22 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 28 May 2019 09:50:22 -0700
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <87r28kl0z3.fsf@oldenburg2.str.redhat.com>
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <87ftp4tcas.fsf@oldenburg2.str.redhat.com>
 <CALrW1jxB2A9iV-i4vuip2xriH4ZVfHy6-M2eYhrhoOOBYbdY6w@mail.gmail.com>
 <87y32vmvaq.fsf@oldenburg2.str.redhat.com>
 <CALrW1jwJWYtrTi0uxX7hQkkWugmyevpYKjV9_N-sp+PMCSpE7w@mail.gmail.com>
 <CA+kOe0-Y=yYuEc3cU3vYs9nknAtDLNUV8q0Dk2Dv1gMTq2+awg@mail.gmail.com>
 <87r28kl0z3.fsf@oldenburg2.str.redhat.com>
Message-ID: <CA+kOe0_hp7ngerEpnLxDzydZDU0T6R-njELWAcLdDdW-scM=6A@mail.gmail.com>

On Mon, May 27, 2019 at 2:07 AM Florian Weimer <fweimer at redhat.com> wrote:

> * Martin Buchholz:
>
> > Very big picture - if we want to banish stack overflows forever, we would
> > need to migrate the industry to split runtime stacks, which would add a
> bit
> > of runtime overhead to every native function call.  No one is heroic
> enough
> > to make progress towards that.  Maybe developers of new OSes need to read
> > this thread?
>
> For an infinite recursion, you would still get an OutOfMemoryError, only
> much later and potentially after taking down the desktop environment.
>

Of course there is a problem with resource exhaustion.
The idea is to have fewer different limits for the same sort of resource
(here, memory).
Conceptually, I don't see any difference between allocating stack space and
allocating native heap space (via malloc).
Both sorts of memory could come out of the same pool.
We need to protect against global resource exhaustion, but I'd like to see
all the limits at the process level.

We have some existing code that converts recursive call chains into an
explicit data structure on the java heap to avoid StackOverflowError.


> Furthermore, if the thread stack is not committed memory, then
> try-finally blocks will not work reliably because any function call may
> attempt to enlarge the stack and fail to do so.
>

We already have a problem with try-finally failing when stack space is
exhausted.
We have a kludgy unreliable workaround via @ReservedStackAccess.


> > One strong hint is that glibc uses that when it needs to create its own
> > helper thread with minimal stack.
> > But why-oh-why not expose that for use by others?  Other software like
> Java
> > or Rust has the same needs!
>
> Creating a stack with __pthread_get_minstack() bytes doesn't mean the
> thread can do anything useful.  For example, the thread will not on a
> kernel with a vDSO compiled with -fstack-check.  You can can't call
> (f)printf on a file stream which is unbuffered.  The thread may not be
> able to receive any signals whatsoever.  And so on.  That's why it's not
> a public interface.
>

Well, of course a thread stack allocator can't
expect __pthread_get_minstack() by itself to be sufficient.
Any application specific requirements need to be added.
glibc  itself adds 4 * PTHREAD_STACK_MIN.
Java would add user-specified stack size (for java frames) plus any other
JVM overhead like "red zone" pages.
Again, I see glibc's  own needs to be very similar to the JVM's needs.


> I suggested to use this interface only as a workaround for the TLS
> allocation issue.
>
> Thanks,
> Florian
>

From martinrb at google.com  Tue May 28 17:19:23 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 28 May 2019 10:19:23 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <103800D4-06C9-49FE-9DFD-7C4D5CDF0DDE@oracle.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <CA+kOe08hXx1jJ7-5-xAOsUKpzQmDOJAmc5Uw1oeAYZLqcQEhEA@mail.gmail.com>
 <103800D4-06C9-49FE-9DFD-7C4D5CDF0DDE@oracle.com>
Message-ID: <CA+kOe0_ip1jsGUu3tA4-WmN1P8VOrKscfS_0iCxS=Ern=wk5=g@mail.gmail.com>

On Mon, May 27, 2019 at 8:38 AM Pavel Rappo <pavel.rappo at oracle.com> wrote:

> Would you care to elaborate on that? As far as I understand Stuart was
> simply
> working around javadoc's bug in the "Copying of Method Comments" algorithm.
>

It's not really a javadoc bug.  Java doesn't really provide any way to
distinguish between inheritance for implementation and subtyping.
AbstractFoo classes provide only implementation.
(Or do they?  Reality is more subtle - if you inherit
AbstraceSet.removeAll, you might also want to inherit its javadoc (but its
javadoc is targeted at subclassers, not users (but it doesn't
use @implSpec) ... sigh)
If you override removeAll, you are more likely to want to inherit the
javadoc from Set than AbstractSet, but how is javadoc supposed to know?  We
could enhance @inheritDoc to make the source clear {@inheritDoc from
Set.removeAll})
It's a hard problem ... and the ancient root cause is conflating
inheritance and subtyping.


> > On 26 May 2019, at 17:25, Martin Buchholz <martinrb at google.com> wrote:
> >
> > This is yet another symptom of Java's fundamental design mistake of being
> > unable to simply inherit implementation, that we have learned to live
> with.
> > "Inheritance is not subtyping"
>
>

From joe.darcy at oracle.com  Tue May 28 17:42:58 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 28 May 2019 10:42:58 -0700
Subject: JDK 13 RFR of JDK-8224783: Javadoc of String strip methods uses
 link where linkplain would be better
In-Reply-To: <60822501-EC4E-49F6-828B-89FBE918BD24@oracle.com>
References: <52781558-6064-40d5-55bc-f667c59f2e19@oracle.com>
 <60822501-EC4E-49F6-828B-89FBE918BD24@oracle.com>
Message-ID: <b4cc5cf2-c0fb-d61f-770b-182c69d4bdc4@oracle.com>

Hello,

Double-checking the changes, I found a few more instances of "white 
space" in a code markup that I'll change to plain text as part of the 
fix; several edits of

 ??? {@link Character#isWhitespace(int) white space characters}

to

 ???? {@linkplain Character#isWhitespace(int) white space characters}

Additional patch:

@@ -2849,10 +2849,10 @@
 ????? * beginning of each line.
 ????? * <p>
 ????? * If {@code n < 0} then up to {@code n}
-???? * {@link Character#isWhitespace(int) white space characters} are 
removed
+???? * {@linkplain Character#isWhitespace(int) white space characters} 
are removed
 ????? * from the beginning of each line. If a given line does not contain
 ????? * sufficient white space then all leading
-???? * {@link Character#isWhitespace(int) white space characters} are 
removed.
+???? * {@linkplain Character#isWhitespace(int) white space characters} 
are removed.
 ????? * Each white space character is treated as a single character. In
 ????? * particular, the tab character {@code "\t"} (U+0009) is considered a
 ????? * single character; it is not expanded.
@@ -2861,7 +2861,7 @@
 ????? * terminators are still normalized.
 ????? *
 ????? * @param n? number of leading
-???? *?????????? {@link Character#isWhitespace(int) white space characters}
+???? *?????????? {@linkplain Character#isWhitespace(int) white space 
characters}
 ????? *?????????? to add or remove
 ????? *
 ????? * @return string with indentation adjusted and line endings 
normalized

Thanks,

-Joe

On 5/27/2019 6:12 AM, Jim Laskey wrote:
> +1
>
>> On May 24, 2019, at 10:15 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
>>
>> Hello,
>>
>> Please review the patch below to address:
>>
>>      JDK-8224783: Javadoc of String strip methods uses link where linkplain would be better
>>
>> Thanks,
>>
>> -Joe
>>
>> diff -r 4947a097db60 src/java.base/share/classes/java/lang/String.java
>> --- a/src/java.base/share/classes/java/lang/String.java    Fri May 24 15:06:58 2019 -0400
>> +++ b/src/java.base/share/classes/java/lang/String.java    Fri May 24 18:14:28 2019 -0700
>> @@ -2690,21 +2690,21 @@
>>
>>       /**
>>        * Returns a string whose value is this string, with all leading
>> -     * and trailing {@link Character#isWhitespace(int) white space}
>> +     * and trailing {@linkplain Character#isWhitespace(int) white space}
>>        * removed.
>>        * <p>
>>        * If this {@code String} object represents an empty string,
>>        * or if all code points in this string are
>> -     * {@link Character#isWhitespace(int) white space}, then an empty string
>> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>>        * is returned.
>>        * <p>
>>        * Otherwise, returns a substring of this string beginning with the first
>> -     * code point that is not a {@link Character#isWhitespace(int) white space}
>> +     * code point that is not a {@linkplain Character#isWhitespace(int) white space}
>>        * up to and including the last code point that is not a
>> -     * {@link Character#isWhitespace(int) white space}.
>> +     * {@linkplain Character#isWhitespace(int) white space}.
>>        * <p>
>>        * This method may be used to strip
>> -     * {@link Character#isWhitespace(int) white space} from
>> +     * {@linkplain Character#isWhitespace(int) white space} from
>>        * the beginning and end of a string.
>>        *
>>        * @return  a string whose value is this string, with all leading
>> @@ -2722,19 +2722,19 @@
>>
>>       /**
>>        * Returns a string whose value is this string, with all leading
>> -     * {@link Character#isWhitespace(int) white space} removed.
>> +     * {@linkplain Character#isWhitespace(int) white space} removed.
>>        * <p>
>>        * If this {@code String} object represents an empty string,
>>        * or if all code points in this string are
>> -     * {@link Character#isWhitespace(int) white space}, then an empty string
>> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>>        * is returned.
>>        * <p>
>>        * Otherwise, returns a substring of this string beginning with the first
>> -     * code point that is not a {@link Character#isWhitespace(int) white space}
>> +     * code point that is not a {@linkplain Character#isWhitespace(int) white space}
>>        * up to and including the last code point of this string.
>>        * <p>
>>        * This method may be used to trim
>> -     * {@link Character#isWhitespace(int) white space} from
>> +     * {@linkplain Character#isWhitespace(int) white space} from
>>        * the beginning of a string.
>>        *
>>        * @return  a string whose value is this string, with all leading white
>> @@ -2752,19 +2752,19 @@
>>
>>       /**
>>        * Returns a string whose value is this string, with all trailing
>> -     * {@link Character#isWhitespace(int) white space} removed.
>> +     * {@linkplain Character#isWhitespace(int) white space} removed.
>>        * <p>
>>        * If this {@code String} object represents an empty string,
>>        * or if all characters in this string are
>> -     * {@link Character#isWhitespace(int) white space}, then an empty string
>> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>>        * is returned.
>>        * <p>
>>        * Otherwise, returns a substring of this string beginning with the first
>>        * code point of this string up to and including the last code point
>> -     * that is not a {@link Character#isWhitespace(int) white space}.
>> +     * that is not a {@linkplain Character#isWhitespace(int) white space}.
>>        * <p>
>>        * This method may be used to trim
>> -     * {@link Character#isWhitespace(int) white space} from
>> +     * {@linkplain Character#isWhitespace(int) white space} from
>>        * the end of a string.
>>        *
>>        * @return  a string whose value is this string, with all trailing white
>> @@ -2782,11 +2782,11 @@
>>
>>       /**
>>        * Returns {@code true} if the string is empty or contains only
>> -     * {@link Character#isWhitespace(int) white space} codepoints,
>> +     * {@linkplain Character#isWhitespace(int) white space} codepoints,
>>        * otherwise {@code false}.
>>        *
>>        * @return {@code true} if the string is empty or contains only
>> -     *         {@link Character#isWhitespace(int) white space} codepoints,
>> +     *         {@linkplain Character#isWhitespace(int) white space} codepoints,
>>        *         otherwise {@code false}
>>        *
>>        * @see Character#isWhitespace(int)
>>

From martinrb at google.com  Tue May 28 17:47:24 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 28 May 2019 10:47:24 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <876036be-ce3a-70e6-0762-3d02d1789b3f@gmail.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <CA+kOe08hXx1jJ7-5-xAOsUKpzQmDOJAmc5Uw1oeAYZLqcQEhEA@mail.gmail.com>
 <876036be-ce3a-70e6-0762-3d02d1789b3f@gmail.com>
Message-ID: <CA+kOe09QETOd0pnWGngb7=wWpANCUmbnY_hj44mcOCs0CHN+fA@mail.gmail.com>

On Mon, May 27, 2019 at 1:35 AM Peter Levart <peter.levart at gmail.com> wrote:

>
>
> On 5/26/19 6:25 PM, Martin Buchholz wrote:
> > On Mon, May 13, 2019 at 5:29 PM Stuart Marks <stuart.marks at oracle.com>
> > wrote:
> >
> >>    - addition of FIXME comment and reference to javadoc bug report,
> where
> >> doc
> >> comment from interface cannot be inherited
> >>
> > This is yet another symptom of Java's fundamental design mistake of being
> > unable to simply inherit implementation, that we have learned to live
> with.
> > "Inheritance is not subtyping"
>
> One way of inheriting "only implementation" is to have a package-private
> superclass with public methods. (AbstractStringBuilder for example). It
> confines all implementations (subclasses) to the same package though, so
> it is not a universal tool. With jigsaw there is another possibility: a
> public but internal (confined) superclass which is exported just to
> modules that need to subclass it.
>

These are useful techniques, but good reusable snippets of implementation
should often be public, and the unit of reusability should somehow include
javadoc (in two flavors, for subclassers and callers).  Default methods in
interfaces are another partial solution to the implementation reuse problem.

From lance.andersen at oracle.com  Tue May 28 17:50:42 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 28 May 2019 13:50:42 -0400
Subject: JDK 13 RFR of JDK-8224783: Javadoc of String strip methods uses
 link where linkplain would be better
In-Reply-To: <b4cc5cf2-c0fb-d61f-770b-182c69d4bdc4@oracle.com>
References: <52781558-6064-40d5-55bc-f667c59f2e19@oracle.com>
 <60822501-EC4E-49F6-828B-89FBE918BD24@oracle.com>
 <b4cc5cf2-c0fb-d61f-770b-182c69d4bdc4@oracle.com>
Message-ID: <4F4054B1-B306-499E-ABA1-12D0E391A0C6@oracle.com>

+1
> On May 28, 2019, at 1:42 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Double-checking the changes, I found a few more instances of "white space" in a code markup that I'll change to plain text as part of the fix; several edits of
> 
>     {@link Character#isWhitespace(int) white space characters}
> 
> to
> 
>      {@linkplain Character#isWhitespace(int) white space characters}
> 
> Additional patch:
> 
> @@ -2849,10 +2849,10 @@
>       * beginning of each line.
>       * <p>
>       * If {@code n < 0} then up to {@code n}
> -     * {@link Character#isWhitespace(int) white space characters} are removed
> +     * {@linkplain Character#isWhitespace(int) white space characters} are removed
>       * from the beginning of each line. If a given line does not contain
>       * sufficient white space then all leading
> -     * {@link Character#isWhitespace(int) white space characters} are removed.
> +     * {@linkplain Character#isWhitespace(int) white space characters} are removed.
>       * Each white space character is treated as a single character. In
>       * particular, the tab character {@code "\t"} (U+0009) is considered a
>       * single character; it is not expanded.
> @@ -2861,7 +2861,7 @@
>       * terminators are still normalized.
>       *
>       * @param n  number of leading
> -     *           {@link Character#isWhitespace(int) white space characters}
> +     *           {@linkplain Character#isWhitespace(int) white space characters}
>       *           to add or remove
>       *
>       * @return string with indentation adjusted and line endings normalized
> 
> Thanks,
> 
> -Joe
> 
> On 5/27/2019 6:12 AM, Jim Laskey wrote:
>> +1
>> 
>>> On May 24, 2019, at 10:15 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
>>> 
>>> Hello,
>>> 
>>> Please review the patch below to address:
>>> 
>>>     JDK-8224783: Javadoc of String strip methods uses link where linkplain would be better
>>> 
>>> Thanks,
>>> 
>>> -Joe
>>> 
>>> diff -r 4947a097db60 src/java.base/share/classes/java/lang/String.java
>>> --- a/src/java.base/share/classes/java/lang/String.java    Fri May 24 15:06:58 2019 -0400
>>> +++ b/src/java.base/share/classes/java/lang/String.java    Fri May 24 18:14:28 2019 -0700
>>> @@ -2690,21 +2690,21 @@
>>> 
>>>      /**
>>>       * Returns a string whose value is this string, with all leading
>>> -     * and trailing {@link Character#isWhitespace(int) white space}
>>> +     * and trailing {@linkplain Character#isWhitespace(int) white space}
>>>       * removed.
>>>       * <p>
>>>       * If this {@code String} object represents an empty string,
>>>       * or if all code points in this string are
>>> -     * {@link Character#isWhitespace(int) white space}, then an empty string
>>> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>>>       * is returned.
>>>       * <p>
>>>       * Otherwise, returns a substring of this string beginning with the first
>>> -     * code point that is not a {@link Character#isWhitespace(int) white space}
>>> +     * code point that is not a {@linkplain Character#isWhitespace(int) white space}
>>>       * up to and including the last code point that is not a
>>> -     * {@link Character#isWhitespace(int) white space}.
>>> +     * {@linkplain Character#isWhitespace(int) white space}.
>>>       * <p>
>>>       * This method may be used to strip
>>> -     * {@link Character#isWhitespace(int) white space} from
>>> +     * {@linkplain Character#isWhitespace(int) white space} from
>>>       * the beginning and end of a string.
>>>       *
>>>       * @return  a string whose value is this string, with all leading
>>> @@ -2722,19 +2722,19 @@
>>> 
>>>      /**
>>>       * Returns a string whose value is this string, with all leading
>>> -     * {@link Character#isWhitespace(int) white space} removed.
>>> +     * {@linkplain Character#isWhitespace(int) white space} removed.
>>>       * <p>
>>>       * If this {@code String} object represents an empty string,
>>>       * or if all code points in this string are
>>> -     * {@link Character#isWhitespace(int) white space}, then an empty string
>>> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>>>       * is returned.
>>>       * <p>
>>>       * Otherwise, returns a substring of this string beginning with the first
>>> -     * code point that is not a {@link Character#isWhitespace(int) white space}
>>> +     * code point that is not a {@linkplain Character#isWhitespace(int) white space}
>>>       * up to and including the last code point of this string.
>>>       * <p>
>>>       * This method may be used to trim
>>> -     * {@link Character#isWhitespace(int) white space} from
>>> +     * {@linkplain Character#isWhitespace(int) white space} from
>>>       * the beginning of a string.
>>>       *
>>>       * @return  a string whose value is this string, with all leading white
>>> @@ -2752,19 +2752,19 @@
>>> 
>>>      /**
>>>       * Returns a string whose value is this string, with all trailing
>>> -     * {@link Character#isWhitespace(int) white space} removed.
>>> +     * {@linkplain Character#isWhitespace(int) white space} removed.
>>>       * <p>
>>>       * If this {@code String} object represents an empty string,
>>>       * or if all characters in this string are
>>> -     * {@link Character#isWhitespace(int) white space}, then an empty string
>>> +     * {@linkplain Character#isWhitespace(int) white space}, then an empty string
>>>       * is returned.
>>>       * <p>
>>>       * Otherwise, returns a substring of this string beginning with the first
>>>       * code point of this string up to and including the last code point
>>> -     * that is not a {@link Character#isWhitespace(int) white space}.
>>> +     * that is not a {@linkplain Character#isWhitespace(int) white space}.
>>>       * <p>
>>>       * This method may be used to trim
>>> -     * {@link Character#isWhitespace(int) white space} from
>>> +     * {@linkplain Character#isWhitespace(int) white space} from
>>>       * the end of a string.
>>>       *
>>>       * @return  a string whose value is this string, with all trailing white
>>> @@ -2782,11 +2782,11 @@
>>> 
>>>      /**
>>>       * Returns {@code true} if the string is empty or contains only
>>> -     * {@link Character#isWhitespace(int) white space} codepoints,
>>> +     * {@linkplain Character#isWhitespace(int) white space} codepoints,
>>>       * otherwise {@code false}.
>>>       *
>>>       * @return {@code true} if the string is empty or contains only
>>> -     *         {@link Character#isWhitespace(int) white space} codepoints,
>>> +     *         {@linkplain Character#isWhitespace(int) white space} codepoints,
>>>       *         otherwise {@code false}
>>>       *
>>>       * @see Character#isWhitespace(int)
>>> 

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




From jonathan.gibbons at oracle.com  Tue May 28 17:51:22 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 28 May 2019 10:51:22 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <CA+kOe0_ip1jsGUu3tA4-WmN1P8VOrKscfS_0iCxS=Ern=wk5=g@mail.gmail.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <CA+kOe08hXx1jJ7-5-xAOsUKpzQmDOJAmc5Uw1oeAYZLqcQEhEA@mail.gmail.com>
 <103800D4-06C9-49FE-9DFD-7C4D5CDF0DDE@oracle.com>
 <CA+kOe0_ip1jsGUu3tA4-WmN1P8VOrKscfS_0iCxS=Ern=wk5=g@mail.gmail.com>
Message-ID: <64ca3c57-3608-4fec-921f-37652e05670e@oracle.com>


On 5/28/19 10:19 AM, Martin Buchholz wrote:
> We could enhance @inheritDoc to make the source clear {@inheritDoc from
> Set.removeAll})

Generally, improving {@inheritDoc} is on the list.

-- Jon



From ivan.gerasimov at oracle.com  Tue May 28 17:55:51 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 28 May 2019 10:55:51 -0700
Subject: RFR 8224789 : Parsing repetition count in regex does not detect
 numeric overflow
In-Reply-To: <4f430138-d705-20d0-3b6a-cf9b356b2067@oracle.com>
References: <f91a2861-05b7-cc3e-19d7-c92f9514b914@oracle.com>
 <4f430138-d705-20d0-3b6a-cf9b356b2067@oracle.com>
Message-ID: <713f7465-19c2-863a-f8b6-b558f362b63a@oracle.com>

Thank you Roger for reviewing!


On 5/28/19 9:33 AM, Roger Riggs wrote:
> Hi Ivan,
>
> test/jdk/java/util/regex/RegExTest.java:
>
> 4954: The test should print the failing exception information and
> 4951: a message if the Pattern.compile does not fail to distinguish 
> that failure from any others.
>
Yes, it will be useful, if the test fails.
So, I added some debug output.

The webrev was updated in place:
http://cr.openjdk.java.net/~igerasim/8224789/00/webrev/

> I don't think there is a need for so many cases of values > 2^31; 
> there is no different code path for all those values.
> They are fairly cheap, but redundant.
>
I wanted to cover cases when the number would overflow 64-bit integer, 
so that the test would fail if the count were implemented as a long.

Also, I tried to cover different configurations of the quantifier {N}, 
{N,}, {N,M} with both N and M overflowing int, unsigned int, long, 
unsigned long.

With kind regards,
Ivan

> Otherwise, looks fine.
>
> Thanks, Roger
>
>
> On 05/25/2019 02:28 AM, Ivan Gerasimov wrote:
>> Hello!
>>
>> When Pattern.compile() parses the repetition count in the expressions 
>> like '.{100}', '.{1,2}' or '.{3,}' it fails to detect numeric 
>> overflow if the result is still non-negative.
>>
>> Could you please help review the patch?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8224789
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8224789/00/webrev/
>>
>> Also, reading a char at line 3274 is done with skip(), so the 
>> exception thrown at 3315 displays the position of the error more 
>> accurately.
>>
>
>

-- 
With kind regards,
Ivan Gerasimov


From Roger.Riggs at oracle.com  Tue May 28 17:58:53 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 28 May 2019 13:58:53 -0400
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an
 explicit 'no guarantee' statement
Message-ID: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>

Please review a change to the javadoc of Runtime.gc() and System.gc() to 
clarify
that invoking these methods does not guarantee any specific result or 
timeliness
of completion.

The revised text is:

       * Runs the garbage collector in the Java Virtual Machine.
       *
       * Calling this method suggests that the Java Virtual Machine
       * expend effort toward recycling unused objects in order to
       * make the memory they currently occupy available for reuse
       * by the Java Virtual Machine.
       * There is no guarantee that this effort will recycle any particular
       * number of unused objects, reclaim any particular amount of space,
       * or complete at any particular time, if at all.

Issue:
 ? https://bugs.openjdk.java.net/browse/JDK-8220238

CSR:
 ? https://bugs.openjdk.java.net/browse/JDK-8224760

Webrev:
 ? http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238/index.html

Please review and comment, Roger


From shade at redhat.com  Tue May 28 18:06:30 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 28 May 2019 20:06:30 +0200
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
Message-ID: <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>

On 5/28/19 7:58 PM, Roger Riggs wrote:
> Please review a change to the javadoc of Runtime.gc() and System.gc() to clarify
> that invoking these methods does not guarantee any specific result or timeliness
> of completion.
> 
> The revised text is:
> 
> ????? * Runs the garbage collector in the Java Virtual Machine.
> ????? *
> ????? * Calling this method suggests that the Java Virtual Machine
> ????? * expend effort toward recycling unused objects in order to
> ????? * make the memory they currently occupy available for reuse
> ????? * by the Java Virtual Machine.
> ????? * There is no guarantee that this effort will recycle any particular
> ????? * number of unused objects, reclaim any particular amount of space,
> ????? * or complete at any particular time, if at all.
> 
> Issue:
> ? https://bugs.openjdk.java.net/browse/JDK-8220238
> 
> CSR:
> ? https://bugs.openjdk.java.net/browse/JDK-8224760
> 
> Webrev:
> ? http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238/index.html

Thank you.

It feels like <p/> is missing between paragraphs?

Also, I don't think it is sensible to drop the blocking behavior ("When control returns...") -- I
think some programs enjoy that property, and certainly many GCs have special tests to enforce this
property, even if GC is fully concurrent.

-- 
Thanks,
-Aleksey


From martinrb at google.com  Tue May 28 19:21:19 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 28 May 2019 12:21:19 -0700
Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are
 surprisingly dependent on relative sizes
In-Reply-To: <3BAF7EFF-8229-402E-B8F5-09EA80434313@cbfiddle.com>
References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com>
 <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com>
 <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com>
 <C8F82E77-C1A6-4A7D-A984-8F2B32883620@cbfiddle.com>
 <ef9cde9c-909b-9387-3165-58e62a6bdbcc@gmail.com>
 <32291cb3-a2e2-b3ba-5396-f6b8c8deb17f@oracle.com>
 <3BAF7EFF-8229-402E-B8F5-09EA80434313@cbfiddle.com>
Message-ID: <CA+kOe0_pzyQ3+Y2JM-fBERXUsBzFtnUOGwyr342uNo9CiZ0HOQ@mail.gmail.com>

I remember looking at this bug back in 2005 and being afraid to touch it.
The size-based algorithm does feel kludgy but it *is* specified, and
changing that is too incompatible - it would have been rejected at that
time.

I have a lot of sympathy for Alan's insistence on keeping the optimization
for e.g. hashMap.removeAll(otherHashMap).

Java has achieved success via judicious cheating.  The collection framework
was so appealing that any class that came "close enough" to implementing a
spec was given that type in the type system.  (I'm the author of a
collection class that pragmatically cheats a little - no one has ever
complained).

It is when you operate on two collection classes (via removeAll,
containsAll, equals) that have differing semantics that the cheating
becomes most apparent and you get into trouble the most.  We could lower
user expectations in the spec.

Other programming environments allow parameterization of membership
semantics, e.g. C++ std::unordered_map.  Java understandably chose not to
do that, and it resulted in some shoe-horning that we have to live with.

it would be interesting to see if an alternative set of collection classes
was written that focused on flexibility and correctness.  In the real
world, most such alternatives focused on performance, I think.

From james.laskey at oracle.com  Tue May 28 19:39:00 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 28 May 2019 16:39:00 -0300
Subject: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits
 /modules element from file path
Message-ID: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>

Please review. Need to revert a change Sundar did earlier today that is causing 33 tier2 failures.

Cheers,

-- Jim

Reverse webrev: http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
JBS: https://bugs.openjdk.java.net/browse/JDK-8224908 <https://bugs.openjdk.java.net/browse/JDK-8224908>

Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946 <http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
Original changset: http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69 <http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69>

From joe.darcy at oracle.com  Tue May 28 19:44:20 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 28 May 2019 12:44:20 -0700
Subject: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits
 /modules element from file path
In-Reply-To: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>
References: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>
Message-ID: <5e2387a5-4942-1b2e-f2f3-54552464f64e@oracle.com>

If this is a straight backport of the previous change, I approve the 
revision.

Cheers,

-Joe

On 5/28/2019 12:39 PM, Jim Laskey wrote:
> Please review. Need to revert a change Sundar did earlier today that is causing 33 tier2 failures.
>
> Cheers,
>
> -- Jim
>
> Reverse webrev: http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908 <https://bugs.openjdk.java.net/browse/JDK-8224908>
>
> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946 <http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
> Original changset: http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69 <http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69>

From james.laskey at oracle.com  Tue May 28 19:45:12 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 28 May 2019 16:45:12 -0300
Subject: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits
 /modules element from file path
In-Reply-To: <5e2387a5-4942-1b2e-f2f3-54552464f64e@oracle.com>
References: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>
 <5e2387a5-4942-1b2e-f2f3-54552464f64e@oracle.com>
Message-ID: <7D9BEE1A-80EE-438B-9B2A-B029338CE5FE@oracle.com>

Thank you.


> On May 28, 2019, at 4:44 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> If this is a straight backport of the previous change, I approve the revision.
> 
> Cheers,
> 
> -Joe
> 
> On 5/28/2019 12:39 PM, Jim Laskey wrote:
>> Please review. Need to revert a change Sundar did earlier today that is causing 33 tier2 failures.
>> 
>> Cheers,
>> 
>> -- Jim
>> 
>> Reverse webrev: http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908 <https://bugs.openjdk.java.net/browse/JDK-8224908>
>> 
>> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946 <http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
>> Original changset: http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69 <http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69>


From kim.barrett at oracle.com  Tue May 28 19:46:00 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 28 May 2019 15:46:00 -0400
Subject: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits
 /modules element from file path
In-Reply-To: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>
References: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>
Message-ID: <30473649-DD51-4113-A564-4819EF8CBC49@oracle.com>

On May 28, 2019, at 3:39 PM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Please review. Need to revert a change Sundar did earlier today that is causing 33 tier2 failures.
> 
> Cheers,
> 
> -- Jim
> 
> Reverse webrev: http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908 <https://bugs.openjdk.java.net/browse/JDK-8224908>
> 
> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946 <http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
> Original changset: http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69 <http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69>


Looks good.


From james.laskey at oracle.com  Tue May 28 19:47:24 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 28 May 2019 16:47:24 -0300
Subject: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits
 /modules element from file path
In-Reply-To: <30473649-DD51-4113-A564-4819EF8CBC49@oracle.com>
References: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>
 <30473649-DD51-4113-A564-4819EF8CBC49@oracle.com>
Message-ID: <1A5BD0BC-D95F-4EEC-AFCF-2F116CCFD8E2@oracle.com>

Thank you.

> On May 28, 2019, at 4:46 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> On May 28, 2019, at 3:39 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>> 
>> Please review. Need to revert a change Sundar did earlier today that is causing 33 tier2 failures.
>> 
>> Cheers,
>> 
>> -- Jim
>> 
>> Reverse webrev: http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908 <https://bugs.openjdk.java.net/browse/JDK-8224908>
>> 
>> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946 <http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
>> Original changset: http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69 <http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69>
> 
> 
> Looks good.
> 


From james.laskey at oracle.com  Tue May 28 19:49:27 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 28 May 2019 16:49:27 -0300
Subject: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits
 /modules element from file path
In-Reply-To: <5e2387a5-4942-1b2e-f2f3-54552464f64e@oracle.com>
References: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>
 <5e2387a5-4942-1b2e-f2f3-54552464f64e@oracle.com>
Message-ID: <F6855BEE-2378-4A51-AEB5-C477687E5F73@oracle.com>

Thank you.

> On May 28, 2019, at 4:44 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> If this is a straight backport of the previous change, I approve the revision.
> 
> Cheers,
> 
> -Joe
> 
> On 5/28/2019 12:39 PM, Jim Laskey wrote:
>> Please review. Need to revert a change Sundar did earlier today that is causing 33 tier2 failures.
>> 
>> Cheers,
>> 
>> -- Jim
>> 
>> Reverse webrev: http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908 <https://bugs.openjdk.java.net/browse/JDK-8224908>
>> 
>> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946 <http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
>> Original changset: http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69 <http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69>


From Roger.Riggs at oracle.com  Tue May 28 20:36:16 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 28 May 2019 16:36:16 -0400
Subject: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits
 /modules element from file path
In-Reply-To: <30473649-DD51-4113-A564-4819EF8CBC49@oracle.com>
References: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>
 <30473649-DD51-4113-A564-4819EF8CBC49@oracle.com>
Message-ID: <67654dd9-35ea-3d4f-6371-3b2071d97860@oracle.com>

+1,? Roger


On 05/28/2019 03:46 PM, Kim Barrett wrote:
> On May 28, 2019, at 3:39 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>> Please review. Need to revert a change Sundar did earlier today that is causing 33 tier2 failures.
>>
>> Cheers,
>>
>> -- Jim
>>
>> Reverse webrev: http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908 <https://bugs.openjdk.java.net/browse/JDK-8224908>
>>
>> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946 <http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
>> Original changset: http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69 <http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69>
>
> Looks good.
>


From Roger.Riggs at oracle.com  Tue May 28 20:54:36 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 28 May 2019 16:54:36 -0400
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
Message-ID: <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>

Hi Aleksey,

The </p> is always optional (in html5).

The issue with the "when control returns" and "best effort" sentence is 
that is implies that something has been done
and that is not necessarily true.? At best, it could say is that the 
implementation may have done something or done nothing
and anything in between.

Suggestions welcome.

Thanks, Roger



On 05/28/2019 02:06 PM, Aleksey Shipilev wrote:
> On 5/28/19 7:58 PM, Roger Riggs wrote:
>> Please review a change to the javadoc of Runtime.gc() and System.gc() to clarify
>> that invoking these methods does not guarantee any specific result or timeliness
>> of completion.
>>
>> The revised text is:
>>
>>  ????? * Runs the garbage collector in the Java Virtual Machine.
>>  ????? *
>>  ????? * Calling this method suggests that the Java Virtual Machine
>>  ????? * expend effort toward recycling unused objects in order to
>>  ????? * make the memory they currently occupy available for reuse
>>  ????? * by the Java Virtual Machine.
>>  ????? * There is no guarantee that this effort will recycle any particular
>>  ????? * number of unused objects, reclaim any particular amount of space,
>>  ????? * or complete at any particular time, if at all.
>>
>> Issue:
>>  ? https://bugs.openjdk.java.net/browse/JDK-8220238
>>
>> CSR:
>>  ? https://bugs.openjdk.java.net/browse/JDK-8224760
>>
>> Webrev:
>>  ? http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238/index.html
> Thank you.
>
> It feels like <p/> is missing between paragraphs?
>
> Also, I don't think it is sensible to drop the blocking behavior ("When control returns...") -- I
> think some programs enjoy that property, and certainly many GCs have special tests to enforce this
> property, even if GC is fully concurrent.
>


From james.laskey at oracle.com  Tue May 28 20:54:59 2019
From: james.laskey at oracle.com (James Laskey)
Date: Tue, 28 May 2019 17:54:59 -0300
Subject: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits
 /modules element from file path
In-Reply-To: <67654dd9-35ea-3d4f-6371-3b2071d97860@oracle.com>
References: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>
 <30473649-DD51-4113-A564-4819EF8CBC49@oracle.com>
 <67654dd9-35ea-3d4f-6371-3b2071d97860@oracle.com>
Message-ID: <7A5A2BC2-4A95-415A-AA86-C849C1FD7DF0@oracle.com>

Thank you Roger. 

Sent from my iPhone

> On May 28, 2019, at 5:36 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> +1,  Roger
> 
> 
>> On 05/28/2019 03:46 PM, Kim Barrett wrote:
>>> On May 28, 2019, at 3:39 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>>> Please review. Need to revert a change Sundar did earlier today that is causing 33 tier2 failures.
>>> 
>>> Cheers,
>>> 
>>> -- Jim
>>> 
>>> Reverse webrev: http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908 <https://bugs.openjdk.java.net/browse/JDK-8224908>
>>> 
>>> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946 <http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
>>> Original changset: http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69 <http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69>
>> 
>> Looks good.
>> 
> 


From brent.christian at oracle.com  Tue May 28 23:06:10 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 28 May 2019 16:06:10 -0700
Subject: RFR 8224789 : Parsing repetition count in regex does not detect
 numeric overflow
In-Reply-To: <f91a2861-05b7-cc3e-19d7-c92f9514b914@oracle.com>
References: <f91a2861-05b7-cc3e-19d7-c92f9514b914@oracle.com>
Message-ID: <c91b94d9-93b1-59dd-b04e-cc6e6a6b9a53@oracle.com>

Hi, Ivan

I agree with Roger that there are more test cases than necessary. 
Otherwise I think it looks pretty good.

I find the addExact/multiplyExact code less readable.  I'm not sure what 
could be done about it - maybe some different indentation:

cmin = Math.addExact(
                      Math.multiplyExact(cmin, 10),
                      ch - '0');

though that makes for some long lines.  Just a thought.

Thanks,
-Brent

On 5/24/19 11:28 PM, Ivan Gerasimov wrote:
> Hello!
> 
> When Pattern.compile() parses the repetition count in the expressions 
> like '.{100}', '.{1,2}' or '.{3,}' it fails to detect numeric overflow 
> if the result is still non-negative.
> 
> Could you please help review the patch?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8224789
> WEBREV: http://cr.openjdk.java.net/~igerasim/8224789/00/webrev/
> 
> Also, reading a char at line 3274 is done with skip(), so the exception 
> thrown at 3315 displays the position of the error more accurately.
> 

From hboehm at google.com  Tue May 28 23:36:33 2019
From: hboehm at google.com (Hans Boehm)
Date: Tue, 28 May 2019 16:36:33 -0700
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
Message-ID: <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>

I agree with Aleksey's concern.

AFAICT, these methods are usually used for one of two purposes:

1) Let the implementation know that this would be a good time to garbage
collect because the application is likely to remain idle for a while.

2) Ensure that as many references as possible have been enqueued, and
traditionally, with runFinalization(), to ensure that as many finalizers as
possible have been run. If I run out of some resource managed this way, I
may want to try this before giving up.

I don't think this API was ever that well suited to either of these. For
(1), I really want a call that says "garbage collect if we're n% of the way
to triggering the next GC". For (2), I really want a call that does
precisely that but, so long as we still have finalizers, with a better
specification of what happens if I hold a lock needed by a finalizer.

I'm a bit concerned that with the watered-down spec, (2) becomes completely
unimplementable. (1) was already kind of unimplementable, since it's hard
to avoid triggering way too many GCs in a row. In my mind, this raises the
question of whether these are actually still useful.


On Tue, May 28, 2019 at 1:55 PM Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Aleksey,
>
> The </p> is always optional (in html5).
>
> The issue with the "when control returns" and "best effort" sentence is
> that is implies that something has been done
> and that is not necessarily true.  At best, it could say is that the
> implementation may have done something or done nothing
> and anything in between.
>
> Suggestions welcome.
>
> Thanks, Roger
>
>
>
> On 05/28/2019 02:06 PM, Aleksey Shipilev wrote:
> > On 5/28/19 7:58 PM, Roger Riggs wrote:
> >> Please review a change to the javadoc of Runtime.gc() and System.gc()
> to clarify
> >> that invoking these methods does not guarantee any specific result or
> timeliness
> >> of completion.
> >>
> >> The revised text is:
> >>
> >>        * Runs the garbage collector in the Java Virtual Machine.
> >>        *
> >>        * Calling this method suggests that the Java Virtual Machine
> >>        * expend effort toward recycling unused objects in order to
> >>        * make the memory they currently occupy available for reuse
> >>        * by the Java Virtual Machine.
> >>        * There is no guarantee that this effort will recycle any
> particular
> >>        * number of unused objects, reclaim any particular amount of
> space,
> >>        * or complete at any particular time, if at all.
> >>
> >> Issue:
> >>    https://bugs.openjdk.java.net/browse/JDK-8220238
> >>
> >> CSR:
> >>    https://bugs.openjdk.java.net/browse/JDK-8224760
> >>
> >> Webrev:
> >>    http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238/index.html
> > Thank you.
> >
> > It feels like <p/> is missing between paragraphs?
> >
> > Also, I don't think it is sensible to drop the blocking behavior ("When
> control returns...") -- I
> > think some programs enjoy that property, and certainly many GCs have
> special tests to enforce this
> > property, even if GC is fully concurrent.
> >
>
>

From ivan.gerasimov at oracle.com  Wed May 29 02:08:45 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 28 May 2019 19:08:45 -0700
Subject: RFR 8224789 : Parsing repetition count in regex does not detect
 numeric overflow
In-Reply-To: <c91b94d9-93b1-59dd-b04e-cc6e6a6b9a53@oracle.com>
References: <f91a2861-05b7-cc3e-19d7-c92f9514b914@oracle.com>
 <c91b94d9-93b1-59dd-b04e-cc6e6a6b9a53@oracle.com>
Message-ID: <7ad74482-a718-e51d-46b9-de0e60547973@oracle.com>

Hi Brent!


On 5/28/19 4:06 PM, Brent Christian wrote:
> Hi, Ivan
>
> I agree with Roger that there are more test cases than necessary. 
> Otherwise I think it looks pretty good.
>
Okay.  Then let's make the list of invalid ranges shorter, but add a 
randomly generated value!

Please find the updated webrev here:
http://cr.openjdk.java.net/~igerasim/8224789/01/webrev/

With kind regards,
Ivan

> I find the addExact/multiplyExact code less readable. I'm not sure 
> what could be done about it - maybe some different indentation:
>
> cmin = Math.addExact(
>                      Math.multiplyExact(cmin, 10),
>                      ch - '0');
>
> though that makes for some long lines.  Just a thought.
>
> Thanks,
> -Brent
>
> On 5/24/19 11:28 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> When Pattern.compile() parses the repetition count in the expressions 
>> like '.{100}', '.{1,2}' or '.{3,}' it fails to detect numeric 
>> overflow if the result is still non-negative.
>>
>> Could you please help review the patch?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8224789
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8224789/00/webrev/
>>
>> Also, reading a char at line 3274 is done with skip(), so the 
>> exception thrown at 3315 displays the position of the error more 
>> accurately.
>>
>

-- 
With kind regards,
Ivan Gerasimov


From sundararajan.athijegannathan at oracle.com  Wed May 29 04:55:10 2019
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 29 May 2019 10:25:10 +0530
Subject: RFR: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits
 /modules element from file path
In-Reply-To: <F6855BEE-2378-4A51-AEB5-C477687E5F73@oracle.com>
References: <BF7AE424-5394-4904-8E09-7996F16486F4@oracle.com>
 <5e2387a5-4942-1b2e-f2f3-54552464f64e@oracle.com>
 <F6855BEE-2378-4A51-AEB5-C477687E5F73@oracle.com>
Message-ID: <5CEE10AE.1090507@oracle.com>

Thanks Jim for pushing the reverting changeset.

PS. Sorry that I broke the build. I did run jrtfs, javac and javap 
tests. Didn't realise that faulty jrt: URIs are pervasive in tests (per 
JEP jrt: URIs should not have '/modules/' part - which is the bug fix is 
about)

-Sundar

On 29/05/19, 1:19 AM, Jim Laskey wrote:
> Thank you.
>
>> On May 28, 2019, at 4:44 PM, Joe Darcy<joe.darcy at oracle.com>  wrote:
>>
>> If this is a straight backport of the previous change, I approve the revision.
>>
>> Cheers,
>>
>> -Joe
>>
>> On 5/28/2019 12:39 PM, Jim Laskey wrote:
>>> Please review. Need to revert a change Sundar did earlier today that is causing 33 tier2 failures.
>>>
>>> Cheers,
>>>
>>> -- Jim
>>>
>>> Reverse webrev: http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html<http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908<https://bugs.openjdk.java.net/browse/JDK-8224908>
>>>
>>> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946<http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
>>> Original changset: http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69<http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69>

From joe.darcy at oracle.com  Wed May 29 05:52:20 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 28 May 2019 22:52:20 -0700
Subject: JDK 13 RFR of JDK-8224012: AnnotatedType implementations of
 hashCode() lead to StackOverflowError
Message-ID: <c4a62b87-703f-1089-e3c1-0b474a511a88@oracle.com>

Hello,

Please review the changes to address:

 ??? JDK-8224012: AnnotatedType implementations of hashCode() lead to 
StackOverflowError
 ??? http://cr.openjdk.java.net/~darcy/8224012.1/

As discussed in the JBS entry, this is a follow-up issue to fix an 
implementation flaw in JDK-8058202: "AnnotatedType implementations don't 
override toString(), equals(), hashCode()".

In brief, the equals/hashCode methods in the AnnotatedTypeBaseImpl 
classes are updated to avoid possible circularities? in their calling 
structure. As described in more detail below, a comparison is made 
against analogous implementation types in the 
sun.reflect.generics.reflectiveObjects package 
(src/java.base/share/classes/sun/reflect/generics/reflectiveObjects).

A brief summary for some additional context, the original core 
reflection had various "getFoo" methods in java.lang.Class and the 
classes in the classes of the java.lang.reflect package. In JDK 5.0, 
many of these methods had a "getGenericFoo" sibling method added to 
preserve behavioral compatibility of the original method while providing 
access to information about generic declarations. In JDK 8, 
"getAnnotatedFoo" methods were added, as new sibling methods to support 
type annotations, alongside the existing getFoo and getGenericFoo 
methods. Semantically, the getAnnotatedfoo methods are 
"getGenericAnnotatedFoo, but (fortunately) that verbose naming 
convention was not chosen. A family of AnnoatedBar classes was also 
added in JDK 8 to allow annotation on interior structures to be modeled, 
such as a method returning "Set<List<@Quux String>>".

Some notes in the implementation, the hierarchy of annotated type 
implementation classes is housed in 
src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java. 
The nested classes are subtypes of AnnotatedTypeBaseImpl. The building 
blocks of equals and hashCode in that parent type examine the underlying 
type, annotations, and (possibly null) owner type.

The four subtypes and the information they examine in their 
equals/hashCode methods:

 ??? AnnotatedArrayType: base information + component type;
 ??? ??? GenericArrayTypeImpl.java compares component type

 ??? AnnotatedParameterizedType: base information + actual type arguments;
 ??? ??? ParameterizedTypeImpl.java compares owner type, raw type, and 
actual type arguments

 ??? AnnotatedTypeVariable: base information (*changed to omit checking 
of bounds*);
 ??? ??? TypeVariableImpl.java compares generic declaration and name

 ??? AnnotatedWildcardType: base information + upper bounds + lower bounds;
 ??? ??? WildcardTypeImpl.java compares upper bounds and lower bounds

The newly added test cases quickly stackoverflow when run against the 
old implementation.

Thanks,

-Joe


From christoph.langer at sap.com  Wed May 29 12:16:09 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 29 May 2019 12:16:09 +0000
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <62a26037-a991-dc31-a972-a82386f63b92@oracle.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <a3e64312-d902-b751-d55d-0af1c4c6e3c5@oracle.com>
 <953449f0913340f6a94ae3d83611fd92@sap.com>
 <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>
 <HE1PR0201MB2266326D98F5119796990BFC8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
 <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <fad24c8f-aa40-821e-fa15-9cbe32b0eb76@oracle.com>
 <DB7PR02MB51937A87EECD7D1E01F71D098A070@DB7PR02MB5193.eurprd02.prod.outlook.com>
 <62a26037-a991-dc31-a972-a82386f63b92@oracle.com>
Message-ID: <AM6PR02MB51924EFF0E6E9A3C3FCB91B98A1F0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Alan,

> The table items in L119-150 look fine, we just need to avoid really long
> lines One minor comment on L123 is that it might be clearer if you drop
> "created" from the sentence.
> 
> L48-78 is a "wall of text" and links that I don't think will be easy for
> most developers to read. Can I provide suggested wording for this part
> of the spec? I'm just thinking that an alternative wording might help
> avoid too much iteration on this.

I have created a new webrev to add some linebreaks and pick up your suggestion to drop the word "created" in L123.

http://cr.openjdk.java.net/~clanger/webrevs/8213031.12/ 

Waiting on your update for the other part.

Thanks
Christoph


From adinn at redhat.com  Wed May 29 12:35:03 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 29 May 2019 13:35:03 +0100
Subject: RFR: 8224974: Implement JEP 352
In-Reply-To: <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@redhat.com>
 <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com>
Message-ID: <61731ea4-eda2-4126-8cc2-9afbfbbd278f@redhat.com>

Hi Alan,

I have created a new JEP implementation JIRA (note change to thread
title) and associated draft CSR


Impl JIRA:  https://bugs.openjdk.java.net/browse/JDK-8224974

CSR JIRA:

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 joel.borggren.franck at gmail.com  Wed May 29 12:37:30 2019
From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=)
Date: Wed, 29 May 2019 14:37:30 +0200
Subject: JDK 13 RFR of JDK-8224012: AnnotatedType implementations of
 hashCode() lead to StackOverflowError
In-Reply-To: <c4a62b87-703f-1089-e3c1-0b474a511a88@oracle.com>
References: <c4a62b87-703f-1089-e3c1-0b474a511a88@oracle.com>
Message-ID: <CAFG0kMat3Ome14GCqM5xGrE_-UfQ7dpKpP3xHxCOATcdqbdM7A@mail.gmail.com>

Hi Joe!

Looks good to me. Looking at the summary by the end of your mail I guess
this is the only subtype that needs fixing?

Cheers
/Joel

On Wed, 29 May 2019 at 07:52, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello,
>
> Please review the changes to address:
>
>      JDK-8224012: AnnotatedType implementations of hashCode() lead to
> StackOverflowError
>      http://cr.openjdk.java.net/~darcy/8224012.1/
>
> As discussed in the JBS entry, this is a follow-up issue to fix an
> implementation flaw in JDK-8058202: "AnnotatedType implementations don't
> override toString(), equals(), hashCode()".
>
> In brief, the equals/hashCode methods in the AnnotatedTypeBaseImpl
> classes are updated to avoid possible circularities  in their calling
> structure. As described in more detail below, a comparison is made
> against analogous implementation types in the
> sun.reflect.generics.reflectiveObjects package
> (src/java.base/share/classes/sun/reflect/generics/reflectiveObjects).
>
> A brief summary for some additional context, the original core
> reflection had various "getFoo" methods in java.lang.Class and the
> classes in the classes of the java.lang.reflect package. In JDK 5.0,
> many of these methods had a "getGenericFoo" sibling method added to
> preserve behavioral compatibility of the original method while providing
> access to information about generic declarations. In JDK 8,
> "getAnnotatedFoo" methods were added, as new sibling methods to support
> type annotations, alongside the existing getFoo and getGenericFoo
> methods. Semantically, the getAnnotatedfoo methods are
> "getGenericAnnotatedFoo, but (fortunately) that verbose naming
> convention was not chosen. A family of AnnoatedBar classes was also
> added in JDK 8 to allow annotation on interior structures to be modeled,
> such as a method returning "Set<List<@Quux String>>".
>
> Some notes in the implementation, the hierarchy of annotated type
> implementation classes is housed in
> src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java.
>
> The nested classes are subtypes of AnnotatedTypeBaseImpl. The building
> blocks of equals and hashCode in that parent type examine the underlying
> type, annotations, and (possibly null) owner type.
>
> The four subtypes and the information they examine in their
> equals/hashCode methods:
>
>      AnnotatedArrayType: base information + component type;
>          GenericArrayTypeImpl.java compares component type
>
>      AnnotatedParameterizedType: base information + actual type arguments;
>          ParameterizedTypeImpl.java compares owner type, raw type, and
> actual type arguments
>
>      AnnotatedTypeVariable: base information (*changed to omit checking
> of bounds*);
>          TypeVariableImpl.java compares generic declaration and name
>
>      AnnotatedWildcardType: base information + upper bounds + lower bounds;
>          WildcardTypeImpl.java compares upper bounds and lower bounds
>
> The newly added test cases quickly stackoverflow when run against the
> old implementation.
>
> Thanks,
>
> -Joe
>
>

From adinn at redhat.com  Wed May 29 12:50:20 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 29 May 2019 13:50:20 +0100
Subject: RFR: 8224974: Implement JEP 352
In-Reply-To: <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@redhat.com>
 <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com>
Message-ID: <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com>

Hi Alan,

Apologies for the previous post which escaped from the lab while Dr
Funkenstein was struggling to push the right buttons (and work out what
happened when he pushed them).

I have created an implementation subtask and associated CSR. I also
updated the last webrev to record the javadoc changes necessitated in
order to complete the CSR. Finally, I set the JEP fix version to 13 and
pressed the big red "target" button.

Impl JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974
CSR JIRA:  https://bugs.openjdk.java.net/browse/JDK-8224975
webrev:    http://cr.openjdk.java.net/~adinn/8224974/webrev.02/

n.b. I have switched to using the subtask JIRA id in $title and in the
cr.openjdk webrev link ...

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  Wed May 29 12:50:57 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 29 May 2019 13:50:57 +0100
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
Message-ID: <75cc9b2b-c366-d845-6f13-ec751b7a908d@oracle.com>

Roger,

On 28/05/2019 21:54, Roger Riggs wrote:
> Hi Aleksey,
> 
> The </p> is always optional (in html5).

The way that the source documentation is structured suggests that a new
paragraph, `<p>`, is missing HERE ( see below ).

  642      * Runs the garbage collector in the Java Virtual Machine.
  643      *
  644      * <HERE> Calling this method suggests that the Java Virtual 
Machine


> The issue with the "when control returns" and "best effort" sentence is 
> that is implies that something has been done
> and that is not necessarily true.? At best, it could say is that the 
> implementation may have done something or done nothing
> and anything in between.

Commenting only on "when control returns".

Whether GC occurs or not is orthogonal to "when control returns". I read
"when control returns" to mean that once the invocation of `gc`
completes successfully ( without throwing ), then there will be no
further side-effects of this method. The suggested wording removes that
restriction. Is that intentional?

-Chris.

> Suggestions welcome.
> 
> Thanks, Roger
> 
> 
> 
> On 05/28/2019 02:06 PM, Aleksey Shipilev wrote:
>> On 5/28/19 7:58 PM, Roger Riggs wrote:
>>> Please review a change to the javadoc of Runtime.gc() and System.gc() 
>>> to clarify
>>> that invoking these methods does not guarantee any specific result or 
>>> timeliness
>>> of completion.
>>>
>>> The revised text is:
>>>
>>> ?????? * Runs the garbage collector in the Java Virtual Machine.
>>> ?????? *
>>> ?????? * Calling this method suggests that the Java Virtual Machine
>>> ?????? * expend effort toward recycling unused objects in order to
>>> ?????? * make the memory they currently occupy available for reuse
>>> ?????? * by the Java Virtual Machine.
>>> ?????? * There is no guarantee that this effort will recycle any 
>>> particular
>>> ?????? * number of unused objects, reclaim any particular amount of 
>>> space,
>>> ?????? * or complete at any particular time, if at all.
>>>
>>> Issue:
>>> ?? https://bugs.openjdk.java.net/browse/JDK-8220238
>>>
>>> CSR:
>>> ?? https://bugs.openjdk.java.net/browse/JDK-8224760
>>>
>>> Webrev:
>>> ?? http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238/index.html
>> Thank you.
>>
>> It feels like <p/> is missing between paragraphs?
>>
>> Also, I don't think it is sensible to drop the blocking behavior 
>> ("When control returns...") -- I
>> think some programs enjoy that property, and certainly many GCs have 
>> special tests to enforce this
>> property, even if GC is fully concurrent.
>>
> 

From Roger.Riggs at oracle.com  Wed May 29 14:27:57 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 29 May 2019 10:27:57 -0400
Subject: RFR 8224789 : Parsing repetition count in regex does not detect
 numeric overflow
In-Reply-To: <7ad74482-a718-e51d-46b9-de0e60547973@oracle.com>
References: <f91a2861-05b7-cc3e-19d7-c92f9514b914@oracle.com>
 <c91b94d9-93b1-59dd-b04e-cc6e6a6b9a53@oracle.com>
 <7ad74482-a718-e51d-46b9-de0e60547973@oracle.com>
Message-ID: <fe0bbeff-5703-4590-b741-a69c38055e7d@oracle.com>

Thanks Ivan,? Looks good.


On 05/28/2019 10:08 PM, Ivan Gerasimov wrote:
> Hi Brent!
>
>
> On 5/28/19 4:06 PM, Brent Christian wrote:
>> Hi, Ivan
>>
>> I agree with Roger that there are more test cases than necessary. 
>> Otherwise I think it looks pretty good.
>>
> Okay.? Then let's make the list of invalid ranges shorter, but add a 
> randomly generated value!
>
> Please find the updated webrev here:
> http://cr.openjdk.java.net/~igerasim/8224789/01/webrev/
>
> With kind regards,
> Ivan
>
>> I find the addExact/multiplyExact code less readable. I'm not sure 
>> what could be done about it - maybe some different indentation:
>>
>> cmin = Math.addExact(
>> ???????????????????? Math.multiplyExact(cmin, 10),
>> ???????????????????? ch - '0');
>>
>> though that makes for some long lines.? Just a thought.
>>
>> Thanks,
>> -Brent
>>
>> On 5/24/19 11:28 PM, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> When Pattern.compile() parses the repetition count in the 
>>> expressions like '.{100}', '.{1,2}' or '.{3,}' it fails to detect 
>>> numeric overflow if the result is still non-negative.
>>>
>>> Could you please help review the patch?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8224789
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8224789/00/webrev/
>>>
>>> Also, reading a char at line 3274 is done with skip(), so the 
>>> exception thrown at 3315 displays the position of the error more 
>>> accurately.
>>>
>>
>


From vicente.romero at oracle.com  Wed May 29 14:49:34 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 29 May 2019 10:49:34 -0400
Subject: RFR: JDK-8224158: assertion related to NPE at
 DynamicCallSiteDesc::withArgs should be reworded
Message-ID: <6e494eea-0f76-ba06-608b-f9356ccd1824@oracle.com>

Please review fix for [1] at [2] and the CSR at [3]. This is a simple 
fix that is just rewording an assertion at method 
java.lang.constant.DynamicCallSiteDesc::withArgs. The fix is simply:

diff -r dd321e3596c0 -r 78f3b29fb255 
src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java
--- 
a/src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java 
Wed May 29 13:58:05 2019 +0100
+++ 
b/src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java 
Wed May 29 09:14:55 2019 -0400
@@ -156,7 +156,7 @@
 ????? *????????????????????? to the bootstrap, that would appear in the
 ????? *????????????????????? {@code BootstrapMethods} attribute
 ????? * @return the nominal descriptor
-???? * @throws NullPointerException if any parameter is null
+???? * @throws NullPointerException if its argument or its contents are 
{@code null}
 ????? */
 ???? public DynamicCallSiteDesc withArgs(ConstantDesc... bootstrapArgs) {
 ???????? return new DynamicCallSiteDesc(bootstrapMethod, 
invocationName, invocationType, bootstrapArgs);

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8224158
[2] http://cr.openjdk.java.net/~vromero/8224158/webrev.00/
[3] https://bugs.openjdk.java.net/browse/JDK-8224985

From Roger.Riggs at oracle.com  Wed May 29 15:06:13 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 29 May 2019 11:06:13 -0400
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
Message-ID: <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>

Hi Hans,

The language is hard to construct, in part because of the innovations in 
gc technology that have
resulted such a wide range of behaviors and timing.

I'll restore the sentence "When control returns"... but I don't think it 
carries any
definite requirement on an implementation. It is benign since 'best 
effort' is undefined
and depends on the unspecified intentions of the implementation(s).

On 05/28/2019 07:36 PM, Hans Boehm wrote:
> I agree with Aleksey's concern.
>
> AFAICT, these methods are usually used for one of two purposes:
>
> 1) Let the implementation know that this would be a good time to 
> garbage collect because the application is likely to remain idle for a 
> while.
"suggests that"...
>
> 2) Ensure that as many references as possible have been enqueued, and 
> traditionally, with runFinalization(), to ensure that as many 
> finalizers as possible have been run. If I run out of some resource 
> managed this way, I may want to try this before giving up.
The behaviors of reference types, including finalization, are described 
elsewhere
and are just as dependent on the particular gc implementation as making 
memory available for reuse.
>
> I don't think this API was ever that well suited to either of these. 
> For (1), I really want a call that says "garbage collect if we're n% 
> of the way to triggering the next GC". For (2), I really want a call 
> that does precisely that but, so long as we still have finalizers, 
> with a better specification of what happens if I hold a lock needed by 
> a finalizer.
>
> I'm a bit concerned that with the watered-down spec, (2) becomes 
> completely unimplementable. (1) was already kind of unimplementable, 
> since it's hard to avoid triggering way too many GCs in a row. In my 
> mind, this raises the question of whether these are actually still useful.
Timely recovery of resources based on gc side effects is a poor 
mechanism (except perhaps for memory), because gc behavior is so varied.

I didn't see this change as watering down the spec but to make it clear 
that it already does not make any guarantees.

Thanks, Roger
>
>
> On Tue, May 28, 2019 at 1:55 PM Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Hi Aleksey,
>
>     The </p> is always optional (in html5).
>
>     The issue with the "when control returns" and "best effort"
>     sentence is
>     that is implies that something has been done
>     and that is not necessarily true.? At best, it could say is that the
>     implementation may have done something or done nothing
>     and anything in between.
>
>     Suggestions welcome.
>
>     Thanks, Roger
>
>
>
>     On 05/28/2019 02:06 PM, Aleksey Shipilev wrote:
>     > On 5/28/19 7:58 PM, Roger Riggs wrote:
>     >> Please review a change to the javadoc of Runtime.gc() and
>     System.gc() to clarify
>     >> that invoking these methods does not guarantee any specific
>     result or timeliness
>     >> of completion.
>     >>
>     >> The revised text is:
>     >>
>     >>? ????? * Runs the garbage collector in the Java Virtual Machine.
>     >>? ????? *
>     >>? ????? * Calling this method suggests that the Java Virtual Machine
>     >>? ????? * expend effort toward recycling unused objects in order to
>     >>? ????? * make the memory they currently occupy available for reuse
>     >>? ????? * by the Java Virtual Machine.
>     >>? ????? * There is no guarantee that this effort will recycle
>     any particular
>     >>? ????? * number of unused objects, reclaim any particular
>     amount of space,
>     >>? ????? * or complete at any particular time, if at all.
>     >>
>     >> Issue:
>     >> https://bugs.openjdk.java.net/browse/JDK-8220238
>     >>
>     >> CSR:
>     >> https://bugs.openjdk.java.net/browse/JDK-8224760
>     >>
>     >> Webrev:
>     >> http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238/index.html
>     <http://cr.openjdk.java.net/%7Erriggs/webrev-gc-8220238/index.html>
>     > Thank you.
>     >
>     > It feels like <p/> is missing between paragraphs?
>     >
>     > Also, I don't think it is sensible to drop the blocking behavior
>     ("When control returns...") -- I
>     > think some programs enjoy that property, and certainly many GCs
>     have special tests to enforce this
>     > property, even if GC is fully concurrent.
>     >
>


From Roger.Riggs at oracle.com  Wed May 29 15:17:59 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 29 May 2019 11:17:59 -0400
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <75cc9b2b-c366-d845-6f13-ec751b7a908d@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <75cc9b2b-c366-d845-6f13-ec751b7a908d@oracle.com>
Message-ID: <4f3d3b70-af0a-9731-20a4-bc902441e455@oracle.com>

Hi Chris,

On 05/29/2019 08:50 AM, Chris Hegarty wrote:
> Roger,
>
> On 28/05/2019 21:54, Roger Riggs wrote:
>> Hi Aleksey,
>>
>> The </p> is always optional (in html5).
>
> The way that the source documentation is structured suggests that a new
> paragraph, `<p>`, is missing HERE ( see below ).
>
> ?642????? * Runs the garbage collector in the Java Virtual Machine.
> ?643????? *
> ?644????? * <HERE> Calling this method suggests that the Java Virtual 
> Machine
>
ok
>
>> The issue with the "when control returns" and "best effort" sentence 
>> is that is implies that something has been done
>> and that is not necessarily true.? At best, it could say is that the 
>> implementation may have done something or done nothing
>> and anything in between.
>
> Commenting only on "when control returns".
>
> Whether GC occurs or not is orthogonal to "when control returns". I read
> "when control returns" to mean that once the invocation of `gc`
> completes successfully ( without throwing ), then there will be no
> further side-effects of this method. The suggested wording removes that
> restriction. Is that intentional?
Reclaiming memory is described in Runtime.gc() "The JVM performs this 
recycling process automatically as needed"
so typically, it is an ongoing process. Nearly all of the behavior of gc 
could not be considered side effects,
clearing WeakReferences, SoftReferences, etc all of which can happen 
asynchronously to the gc() method call.
Other possible 'side-effects' would include the implementation behavior 
of classes that use j.l.r.References to
maintain their own resources such as DirectByteBuffers, etc. that manage 
off-heap memory.
But those effects are not constrained to be synchronous with the gc() 
method invocation.

Thanks, Roger

>
> -Chris.
>
>> Suggestions welcome.
>>
>> Thanks, Roger
>>
>>
>>
>> On 05/28/2019 02:06 PM, Aleksey Shipilev wrote:
>>> On 5/28/19 7:58 PM, Roger Riggs wrote:
>>>> Please review a change to the javadoc of Runtime.gc() and 
>>>> System.gc() to clarify
>>>> that invoking these methods does not guarantee any specific result 
>>>> or timeliness
>>>> of completion.
>>>>
>>>> The revised text is:
>>>>
>>>> ?????? * Runs the garbage collector in the Java Virtual Machine.
>>>> ?????? *
>>>> ?????? * Calling this method suggests that the Java Virtual Machine
>>>> ?????? * expend effort toward recycling unused objects in order to
>>>> ?????? * make the memory they currently occupy available for reuse
>>>> ?????? * by the Java Virtual Machine.
>>>> ?????? * There is no guarantee that this effort will recycle any 
>>>> particular
>>>> ?????? * number of unused objects, reclaim any particular amount of 
>>>> space,
>>>> ?????? * or complete at any particular time, if at all.
>>>>
>>>> Issue:
>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8220238
>>>>
>>>> CSR:
>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8224760
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238/index.html
>>> Thank you.
>>>
>>> It feels like <p/> is missing between paragraphs?
>>>
>>> Also, I don't think it is sensible to drop the blocking behavior 
>>> ("When control returns...") -- I
>>> think some programs enjoy that property, and certainly many GCs have 
>>> special tests to enforce this
>>> property, even if GC is fully concurrent.
>>>
>>


From claes.redestad at oracle.com  Wed May 29 15:36:41 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 29 May 2019 17:36:41 +0200
Subject: RFR: 8224986: (str) optimize StringBuilder.append(CharSequence, int, 
 int) for String arguments
Message-ID: <9a83030f-6199-466a-7034-96c07f9e3535@oracle.com>

Hi,

it's been pointed out[1] that append(string.substring(start, end)) can
outperform append(string, start, end) in some circumstances. In part due
the former being intrinsified, but also I think due it tickling some
string concat optimizations that allow for eliding the StringBuilder
itself completely when there's only one non-constant argument.

While not ruling out intrinsification of append(String, int, int), I was
able to achieve a reasonable speed-up by peeling off String arguments
to append(CharSequence, int, int) and dropping into a routine that uses
System.arraycopy when appropriate.

This seems like a reasonable improvement in the interim, and an
opportunity to incorporate the relevant microbenchmarks.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8224986
Webrev: http://cr.openjdk.java.net/~redestad/8224986/open.00/

I extended and incorporated the microbenchmark provided in [1] to also 
include variants with UTF16 Strings and mixes of arguments, ensuring
speedups on all appendBounds* variants[2].

Thanks!

/Claes

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057834.html
[2]
Baseline:

Benchmark            (length)  Mode  Cnt     Score     Error   Units
appendBounds             1000  avgt   10   576.939 ?  21.125   ns/op
  ?gc.alloc.rate.norm     1000  avgt   10  2144.000 ?   0.001    B/op
appendBoundsMix          1000  avgt   10   855.308 ?  27.071   ns/op
  ?gc.alloc.rate.norm     1000  avgt   10  3160.000 ?   0.001    B/op
appendBoundsUtf16        1000  avgt   10  1424.518 ?  33.319   ns/op
  ?gc.alloc.rate.norm     1000  avgt   10  5192.000 ?   0.001    B/op

Patch:

Benchmark            (length)  Mode  Cnt     Score     Error   Units
appendBounds             1000  avgt   10   466.640 ?  15.069   ns/op
  ?gc.alloc.rate.norm     1000  avgt   10  2120.000 ?   0.001    B/op
appendBoundsMix          1000  avgt   10   758.886 ?  22.983   ns/op
  ?gc.alloc.rate.norm     1000  avgt   10  3160.000 ?   0.001    B/op
appendBoundsUtf16        1000  avgt   10  1320.360 ?  49.097   ns/op
  ?gc.alloc.rate.norm     1000  avgt   10  5192.000 ?   0.001    B/op

From james.laskey at oracle.com  Wed May 29 15:43:18 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Wed, 29 May 2019 12:43:18 -0300
Subject: RFR: 8224986: (str) optimize StringBuilder.append(CharSequence,
 int, int) for String arguments
In-Reply-To: <9a83030f-6199-466a-7034-96c07f9e3535@oracle.com>
References: <9a83030f-6199-466a-7034-96c07f9e3535@oracle.com>
Message-ID: <EEDDE4E8-E65A-49AD-AD19-569458FC061A@oracle.com>

+1

> On May 29, 2019, at 12:36 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> it's been pointed out[1] that append(string.substring(start, end)) can
> outperform append(string, start, end) in some circumstances. In part due
> the former being intrinsified, but also I think due it tickling some
> string concat optimizations that allow for eliding the StringBuilder
> itself completely when there's only one non-constant argument.
> 
> While not ruling out intrinsification of append(String, int, int), I was
> able to achieve a reasonable speed-up by peeling off String arguments
> to append(CharSequence, int, int) and dropping into a routine that uses
> System.arraycopy when appropriate.
> 
> This seems like a reasonable improvement in the interim, and an
> opportunity to incorporate the relevant microbenchmarks.
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8224986
> Webrev: http://cr.openjdk.java.net/~redestad/8224986/open.00/
> 
> I extended and incorporated the microbenchmark provided in [1] to also include variants with UTF16 Strings and mixes of arguments, ensuring
> speedups on all appendBounds* variants[2].
> 
> Thanks!
> 
> /Claes
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057834.html
> [2]
> Baseline:
> 
> Benchmark            (length)  Mode  Cnt     Score     Error   Units
> appendBounds             1000  avgt   10   576.939 ?  21.125   ns/op
> ?gc.alloc.rate.norm     1000  avgt   10  2144.000 ?   0.001    B/op
> appendBoundsMix          1000  avgt   10   855.308 ?  27.071   ns/op
> ?gc.alloc.rate.norm     1000  avgt   10  3160.000 ?   0.001    B/op
> appendBoundsUtf16        1000  avgt   10  1424.518 ?  33.319   ns/op
> ?gc.alloc.rate.norm     1000  avgt   10  5192.000 ?   0.001    B/op
> 
> Patch:
> 
> Benchmark            (length)  Mode  Cnt     Score     Error   Units
> appendBounds             1000  avgt   10   466.640 ?  15.069   ns/op
> ?gc.alloc.rate.norm     1000  avgt   10  2120.000 ?   0.001    B/op
> appendBoundsMix          1000  avgt   10   758.886 ?  22.983   ns/op
> ?gc.alloc.rate.norm     1000  avgt   10  3160.000 ?   0.001    B/op
> appendBoundsUtf16        1000  avgt   10  1320.360 ?  49.097   ns/op
> ?gc.alloc.rate.norm     1000  avgt   10  5192.000 ?   0.001    B/op


From Roger.Riggs at oracle.com  Wed May 29 15:45:28 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 29 May 2019 11:45:28 -0400
Subject: RFR: 8224986: (str) optimize StringBuilder.append(CharSequence,
 int, int) for String arguments
In-Reply-To: <EEDDE4E8-E65A-49AD-AD19-569458FC061A@oracle.com>
References: <9a83030f-6199-466a-7034-96c07f9e3535@oracle.com>
 <EEDDE4E8-E65A-49AD-AD19-569458FC061A@oracle.com>
Message-ID: <c40ebb72-d39d-a3ed-79ed-4f8bed3e0c57@oracle.com>

Hi Claes,

With the use of random, you should log the seed for the possibility to 
repeat a particular case.

Otherwise, looks ok.

Roger


On 05/29/2019 11:43 AM, Jim Laskey wrote:
> +1
>
>> On May 29, 2019, at 12:36 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> it's been pointed out[1] that append(string.substring(start, end)) can
>> outperform append(string, start, end) in some circumstances. In part due
>> the former being intrinsified, but also I think due it tickling some
>> string concat optimizations that allow for eliding the StringBuilder
>> itself completely when there's only one non-constant argument.
>>
>> While not ruling out intrinsification of append(String, int, int), I was
>> able to achieve a reasonable speed-up by peeling off String arguments
>> to append(CharSequence, int, int) and dropping into a routine that uses
>> System.arraycopy when appropriate.
>>
>> This seems like a reasonable improvement in the interim, and an
>> opportunity to incorporate the relevant microbenchmarks.
>>
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8224986
>> Webrev: http://cr.openjdk.java.net/~redestad/8224986/open.00/
>>
>> I extended and incorporated the microbenchmark provided in [1] to also include variants with UTF16 Strings and mixes of arguments, ensuring
>> speedups on all appendBounds* variants[2].
>>
>> Thanks!
>>
>> /Claes
>>
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057834.html
>> [2]
>> Baseline:
>>
>> Benchmark            (length)  Mode  Cnt     Score     Error   Units
>> appendBounds             1000  avgt   10   576.939 ?  21.125   ns/op
>> ?gc.alloc.rate.norm     1000  avgt   10  2144.000 ?   0.001    B/op
>> appendBoundsMix          1000  avgt   10   855.308 ?  27.071   ns/op
>> ?gc.alloc.rate.norm     1000  avgt   10  3160.000 ?   0.001    B/op
>> appendBoundsUtf16        1000  avgt   10  1424.518 ?  33.319   ns/op
>> ?gc.alloc.rate.norm     1000  avgt   10  5192.000 ?   0.001    B/op
>>
>> Patch:
>>
>> Benchmark            (length)  Mode  Cnt     Score     Error   Units
>> appendBounds             1000  avgt   10   466.640 ?  15.069   ns/op
>> ?gc.alloc.rate.norm     1000  avgt   10  2120.000 ?   0.001    B/op
>> appendBoundsMix          1000  avgt   10   758.886 ?  22.983   ns/op
>> ?gc.alloc.rate.norm     1000  avgt   10  3160.000 ?   0.001    B/op
>> appendBoundsUtf16        1000  avgt   10  1320.360 ?  49.097   ns/op
>> ?gc.alloc.rate.norm     1000  avgt   10  5192.000 ?   0.001    B/op


From joe.darcy at oracle.com  Wed May 29 15:51:45 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 29 May 2019 08:51:45 -0700
Subject: JDK 13 RFR of JDK-8224012: AnnotatedType implementations of
 hashCode() lead to StackOverflowError
In-Reply-To: <CAFG0kMat3Ome14GCqM5xGrE_-UfQ7dpKpP3xHxCOATcdqbdM7A@mail.gmail.com>
References: <c4a62b87-703f-1089-e3c1-0b474a511a88@oracle.com>
 <CAFG0kMat3Ome14GCqM5xGrE_-UfQ7dpKpP3xHxCOATcdqbdM7A@mail.gmail.com>
Message-ID: <4eb5c8ea-938d-17e7-bfe3-decc31025646@oracle.com>

Hi Joel,

Yes, as far as I know now, only AnnotatedTypeVariable was susceptible to 
the stack overflow problem.

Thanks,

-Joe

On 5/29/2019 5:37 AM, Joel Borggr?n-Franck wrote:
> Hi Joe!
>
> Looks good to me. Looking at the summary by the end of your mail I 
> guess this is the only subtype that needs fixing?
>
> Cheers
> /Joel
>
> On Wed, 29 May 2019 at 07:52, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Hello,
>
>     Please review the changes to address:
>
>     ???? JDK-8224012: AnnotatedType implementations of hashCode() lead to
>     StackOverflowError
>     http://cr.openjdk.java.net/~darcy/8224012.1/
>
>     As discussed in the JBS entry, this is a follow-up issue to fix an
>     implementation flaw in JDK-8058202: "AnnotatedType implementations
>     don't
>     override toString(), equals(), hashCode()".
>
>     In brief, the equals/hashCode methods in the AnnotatedTypeBaseImpl
>     classes are updated to avoid possible circularities? in their calling
>     structure. As described in more detail below, a comparison is made
>     against analogous implementation types in the
>     sun.reflect.generics.reflectiveObjects package
>     (src/java.base/share/classes/sun/reflect/generics/reflectiveObjects).
>
>     A brief summary for some additional context, the original core
>     reflection had various "getFoo" methods in java.lang.Class and the
>     classes in the classes of the java.lang.reflect package. In JDK 5.0,
>     many of these methods had a "getGenericFoo" sibling method added to
>     preserve behavioral compatibility of the original method while
>     providing
>     access to information about generic declarations. In JDK 8,
>     "getAnnotatedFoo" methods were added, as new sibling methods to
>     support
>     type annotations, alongside the existing getFoo and getGenericFoo
>     methods. Semantically, the getAnnotatedfoo methods are
>     "getGenericAnnotatedFoo, but (fortunately) that verbose naming
>     convention was not chosen. A family of AnnoatedBar classes was also
>     added in JDK 8 to allow annotation on interior structures to be
>     modeled,
>     such as a method returning "Set<List<@Quux String>>".
>
>     Some notes in the implementation, the hierarchy of annotated type
>     implementation classes is housed in
>     src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java.
>
>     The nested classes are subtypes of AnnotatedTypeBaseImpl. The
>     building
>     blocks of equals and hashCode in that parent type examine the
>     underlying
>     type, annotations, and (possibly null) owner type.
>
>     The four subtypes and the information they examine in their
>     equals/hashCode methods:
>
>     ???? AnnotatedArrayType: base information + component type;
>     ???? ??? GenericArrayTypeImpl.java compares component type
>
>     ???? AnnotatedParameterizedType: base information + actual type
>     arguments;
>     ???? ??? ParameterizedTypeImpl.java compares owner type, raw type,
>     and
>     actual type arguments
>
>     ???? AnnotatedTypeVariable: base information (*changed to omit
>     checking
>     of bounds*);
>     ???? ??? TypeVariableImpl.java compares generic declaration and name
>
>     ???? AnnotatedWildcardType: base information + upper bounds +
>     lower bounds;
>     ???? ??? WildcardTypeImpl.java compares upper bounds and lower bounds
>
>     The newly added test cases quickly stackoverflow when run against the
>     old implementation.
>
>     Thanks,
>
>     -Joe
>

From claes.redestad at oracle.com  Wed May 29 16:04:56 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 29 May 2019 18:04:56 +0200
Subject: RFR: 8224986: (str) optimize StringBuilder.append(CharSequence,
 int, int) for String arguments
In-Reply-To: <c40ebb72-d39d-a3ed-79ed-4f8bed3e0c57@oracle.com>
References: <9a83030f-6199-466a-7034-96c07f9e3535@oracle.com>
 <EEDDE4E8-E65A-49AD-AD19-569458FC061A@oracle.com>
 <c40ebb72-d39d-a3ed-79ed-4f8bed3e0c57@oracle.com>
Message-ID: <2ff0bb21-98c3-8eec-4375-acafccfca9f0@oracle.com>

Hi Roger,

On 2019-05-29 17:45, Roger Riggs wrote:
> Hi Claes,
> 
> With the use of random, you should log the seed for the possibility to 
> repeat a particular case.

the randomization isn't essential for this microbenchmark, only to
generate a non-constant String of the given length. I've de-randomized 
the generation and sanity tested that performance appears unaffected.

Updated in-place: http://cr.openjdk.java.net/~redestad/8224986/open.00/

Thanks!

/Claes



From Roger.Riggs at oracle.com  Wed May 29 16:49:02 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 29 May 2019 12:49:02 -0400
Subject: RFR: 8224986: (str) optimize StringBuilder.append(CharSequence,
 int, int) for String arguments
In-Reply-To: <2ff0bb21-98c3-8eec-4375-acafccfca9f0@oracle.com>
References: <9a83030f-6199-466a-7034-96c07f9e3535@oracle.com>
 <EEDDE4E8-E65A-49AD-AD19-569458FC061A@oracle.com>
 <c40ebb72-d39d-a3ed-79ed-4f8bed3e0c57@oracle.com>
 <2ff0bb21-98c3-8eec-4375-acafccfca9f0@oracle.com>
Message-ID: <7c2377b6-1179-8353-f12f-ba4a55608240@oracle.com>

+1

On 05/29/2019 12:04 PM, Claes Redestad wrote:
> Hi Roger,
>
> On 2019-05-29 17:45, Roger Riggs wrote:
>> Hi Claes,
>>
>> With the use of random, you should log the seed for the possibility 
>> to repeat a particular case.
>
> the randomization isn't essential for this microbenchmark, only to
> generate a non-constant String of the given length. I've de-randomized 
> the generation and sanity tested that performance appears unaffected.
>
> Updated in-place: http://cr.openjdk.java.net/~redestad/8224986/open.00/
>
> Thanks!
>
> /Claes
>
>


From Roger.Riggs at oracle.com  Wed May 29 17:05:58 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 29 May 2019 13:05:58 -0400
Subject: RFR: JDK-8224158: assertion related to NPE at
 DynamicCallSiteDesc::withArgs should be reworded
In-Reply-To: <6e494eea-0f76-ba06-608b-f9356ccd1824@oracle.com>
References: <6e494eea-0f76-ba06-608b-f9356ccd1824@oracle.com>
Message-ID: <96a5b65e-ecd1-d1e5-b521-910430e73904@oracle.com>

Hi Vicente,

Why fix just this one method? The other methods of DynamicCallSiteDesc 
do not make the
same claim for bootstrapArgs and the code does not check for the 
contents being null
nor does the constructor that is invoked that clones the array. (Line 81).

The overhead of a change and CSR is high enough to either save them up 
in a single issue
or related issues and handle them all at once or make a pass through the 
whole class
and related classes to clean up the spec for null handling.

Frequently, it is sufficient to make a class or package level 
declaration such as in java.time.package-info.java

"* Unless otherwise noted, passing a null argument to a constructor or 
method in any class or interface * in this package will cause a {@link 
java.lang.NullPointerException NullPointerException} to be thrown."


$.02, Roger



On 05/29/2019 10:49 AM, Vicente Romero wrote:
> Please review fix for [1] at [2] and the CSR at [3]. This is a simple 
> fix that is just rewording an assertion at method 
> java.lang.constant.DynamicCallSiteDesc::withArgs. The fix is simply:
>
> diff -r dd321e3596c0 -r 78f3b29fb255 
> src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java
> --- 
> a/src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java 
> Wed May 29 13:58:05 2019 +0100
> +++ 
> b/src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java 
> Wed May 29 09:14:55 2019 -0400
> @@ -156,7 +156,7 @@
> ????? *????????????????????? to the bootstrap, that would appear in the
> ????? *????????????????????? {@code BootstrapMethods} attribute
> ????? * @return the nominal descriptor
> -???? * @throws NullPointerException if any parameter is null
> +???? * @throws NullPointerException if its argument or its contents 
> are {@code null}
> ????? */
> ???? public DynamicCallSiteDesc withArgs(ConstantDesc... bootstrapArgs) {
> ???????? return new DynamicCallSiteDesc(bootstrapMethod, 
> invocationName, invocationType, bootstrapArgs);
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8224158
> [2] http://cr.openjdk.java.net/~vromero/8224158/webrev.00/
> [3] https://bugs.openjdk.java.net/browse/JDK-8224985


From kim.barrett at oracle.com  Wed May 29 17:24:56 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 29 May 2019 13:24:56 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info
 for subprocesses 
Message-ID: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>

[I?m not completely sure where this RFR should be sent, but core-libs-dev
and hotspot-dev seems likely to get reasonable coverage of those who
might care.]

Please review this change to the test library to add some "logging"
output to tests that spawn a child process to perform the test and
then analyze that child's output.  We are seeing occasional timeouts
in such tests whose cause is hard to pin down.  It's not clear whether
the excess time is in the child or instead some problem in the testing
framework.  The new logging output provides timestamps for (1) the
start of output collection from the child, (2) the start of waiting
for the child to terminate, and (3) the child's termination.  This
should be enough to determine whether the child is taking too long,
and hint at where (e.g. termination or not).

CR:
https://bugs.openjdk.java.net/browse/JDK-8219149

Webrev:
http://cr.openjdk.java.net/~kbarrett/8219149/open.00/

Testing:
Local hs-tier1 and verified the expected logging output is present.
mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
caused by the new logging.  (It seems unlikely, but...)



From shade at redhat.com  Wed May 29 17:38:51 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 29 May 2019 19:38:51 +0200
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
Message-ID: <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>

On 5/29/19 5:06 PM, Roger Riggs wrote:
> The language is hard to construct, in part because of the innovations in gc technology that have
> resulted such a wide range of behaviors and timing.
> 
> I'll restore the sentence "When control returns"... but I don't think it carries any
> definite requirement on an implementation. It is benign since 'best effort' is undefined
> and depends on the unspecified intentions of the implementation(s).

"When control returns" does mean things for me (GC implementor). We specifically handle blocking
callers on System.gc() calls in Shenandoah (and partially in Epsilon). I would not be surprised if
JCK has tests for that as well.

I think "best effort" is orthogonal to blocking behavior.

-Aleksey


From Roger.Riggs at oracle.com  Wed May 29 18:04:55 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 29 May 2019 14:04:55 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
Message-ID: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>

Hi Kim,

In the normal output less output is cleaner.
It would be more useful to have the Duration of the wait and end time of 
the wait.
(It saves the reader doing subtraction of times).

+          Instant start = Instant.now();
+          boolean aborted = true;
+          try {
+              int result = p.waitFor();
+              aborted = false;
+              return result;
+          } finally {
+              Duration dur = Duration.between(start, Instant.now());
+              if (aborted) {
+                  logProgress("Waiting for completion FAILED after: " + dur);
+              } else {
+                  logProgress("Waiting for completion finished after: " + dur);
+              }
+          }

Or something like that.

Roger


On 05/29/2019 01:24 PM, Kim Barrett wrote:
> [I?m not completely sure where this RFR should be sent, but core-libs-dev
> and hotspot-dev seems likely to get reasonable coverage of those who
> might care.]
>
> Please review this change to the test library to add some "logging"
> output to tests that spawn a child process to perform the test and
> then analyze that child's output.  We are seeing occasional timeouts
> in such tests whose cause is hard to pin down.  It's not clear whether
> the excess time is in the child or instead some problem in the testing
> framework.  The new logging output provides timestamps for (1) the
> start of output collection from the child, (2) the start of waiting
> for the child to terminate, and (3) the child's termination.  This
> should be enough to determine whether the child is taking too long,
> and hint at where (e.g. termination or not).
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8219149
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/
>
> Testing:
> Local hs-tier1 and verified the expected logging output is present.
> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
> caused by the new logging.  (It seems unlikely, but...)
>
>


From philip.race at oracle.com  Wed May 29 18:38:17 2019
From: philip.race at oracle.com (Phil Race)
Date: Wed, 29 May 2019 11:38:17 -0700
Subject: <AWT Dev> RFR: 8223271: SplashScreen is still shown if defaulting
 to headless on MacOS
In-Reply-To: <a8c59f97-d1b2-570d-3e9a-a665fdfc9bb9@oracle.com>
References: <a8c59f97-d1b2-570d-3e9a-a665fdfc9bb9@oracle.com>
Message-ID: <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com>

Any takers ?

-phil.

On 5/24/19 9:35 AM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223271
> Webrev : http://cr.openjdk.java.net/~prr/8223271/
>
> Whilst working on removing some inappropriate coupling of the java 
> launcher and the desktop module,
> and testing out the -splash option, I noticed that on MacOS, in the 
> case when we *default* to headless
> mode (which happens when we determine that we are not in a desktop 
> session), the launcher still
> invokes the splash screen code. This could cause an application to 
> completely hang.
>
> The problem is explained in detail in the bug report, but briefly, the 
> launcher isn't aware of this
> defaulting to headless. And the calls the launcher makes to the 
> dynamically loaded splashscreen
> code, don't return any value it can use to be aware of this.
>
> So this fix updates "DoSplashInit()" to return such a code, and in the 
> event of a headful session
> not being available, it can bail out and not try to show the splashscreen.
> That is the gist of the small set of changes in java.c that relate to 
> this fix.
>
> However I also observed a small memory leak.
> There are static variables
>
> static char* splash_jar_entry = NULL; static char* splash_file_entry = 
> NULL;
> which are meant to hold the location of the splash image.
> When everything is done the malloced storage these point to is freed ...
> except that the malloc code looks like this :-
>
> char* splash_file_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_FILE_ENV_ENTRY "=")+JLI_StrLen(splash_file_name)+1);
> char* splash_jar_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_JAR_ENV_ENTRY "=")+JLI_StrLen(splash_jar_name)+1);
>
> So the static vars are never used and the storage pointed to by local 
> variables is never freed.
>
> So I am fixing that too.
>
> The rest of the fix is in the splashscreen code in the desktop module 
> and it implements
> the return of the status code described above.
>
> There was one leak there too - a stream was not closed in a case where 
> the splash could
> not be displayed.
>
> The regression tests for splash screen were run, but testing this is 
> more an environmental issue -
> sshing into a MacOS system and running tests and demos which would try 
> to display a splash
> and verifying they no longer do, so I didn't see a way to add a 
> specific regression test.
>
> -phil.
>
>
>
>
>


From kevin.rushforth at oracle.com  Wed May 29 18:52:26 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 29 May 2019 11:52:26 -0700
Subject: <AWT Dev> RFR: 8223271: SplashScreen is still shown if defaulting
 to headless on MacOS
In-Reply-To: <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com>
References: <a8c59f97-d1b2-570d-3e9a-a665fdfc9bb9@oracle.com>
 <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com>
Message-ID: <2f87c7f8-e9a6-baaf-55be-c681a52bebe2@oracle.com>

Looks good to me (note that I am not a "R"eviewer).

-- Kevin


On 5/29/2019 11:38 AM, Phil Race wrote:
> Any takers ?
>
> -phil.
>
> On 5/24/19 9:35 AM, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223271
>> Webrev : http://cr.openjdk.java.net/~prr/8223271/
>>
>> Whilst working on removing some inappropriate coupling of the java 
>> launcher and the desktop module,
>> and testing out the -splash option, I noticed that on MacOS, in the 
>> case when we *default* to headless
>> mode (which happens when we determine that we are not in a desktop 
>> session), the launcher still
>> invokes the splash screen code. This could cause an application to 
>> completely hang.
>>
>> The problem is explained in detail in the bug report, but briefly, 
>> the launcher isn't aware of this
>> defaulting to headless. And the calls the launcher makes to the 
>> dynamically loaded splashscreen
>> code, don't return any value it can use to be aware of this.
>>
>> So this fix updates "DoSplashInit()" to return such a code, and in 
>> the event of a headful session
>> not being available, it can bail out and not try to show the 
>> splashscreen.
>> That is the gist of the small set of changes in java.c that relate to 
>> this fix.
>>
>> However I also observed a small memory leak.
>> There are static variables
>>
>> static char* splash_jar_entry = NULL; static char* splash_file_entry 
>> = NULL;
>> which are meant to hold the location of the splash image.
>> When everything is done the malloced storage these point to is freed ...
>> except that the malloc code looks like this :-
>>
>> char* splash_file_entry = 
>> JLI_MemAlloc(JLI_StrLen(SPLASH_FILE_ENV_ENTRY 
>> "=")+JLI_StrLen(splash_file_name)+1);
>> char* splash_jar_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_JAR_ENV_ENTRY 
>> "=")+JLI_StrLen(splash_jar_name)+1);
>>
>> So the static vars are never used and the storage pointed to by local 
>> variables is never freed.
>>
>> So I am fixing that too.
>>
>> The rest of the fix is in the splashscreen code in the desktop module 
>> and it implements
>> the return of the status code described above.
>>
>> There was one leak there too - a stream was not closed in a case 
>> where the splash could
>> not be displayed.
>>
>> The regression tests for splash screen were run, but testing this is 
>> more an environmental issue -
>> sshing into a MacOS system and running tests and demos which would 
>> try to display a splash
>> and verifying they no longer do, so I didn't see a way to add a 
>> specific regression test.
>>
>> -phil.
>>
>>
>>
>>
>>
>


From brian.burkhalter at oracle.com  Wed May 29 18:55:03 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 29 May 2019 11:55:03 -0700
Subject: <AWT Dev> RFR: 8223271: SplashScreen is still shown if defaulting
 to headless on MacOS
In-Reply-To: <2f87c7f8-e9a6-baaf-55be-c681a52bebe2@oracle.com>
References: <a8c59f97-d1b2-570d-3e9a-a665fdfc9bb9@oracle.com>
 <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com>
 <2f87c7f8-e9a6-baaf-55be-c681a52bebe2@oracle.com>
Message-ID: <B3806513-295A-429B-8BFC-1C1074E6020C@oracle.com>

Likewise, but I am. +1

Brian

> On May 29, 2019, at 11:52 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> Looks good to me (note that I am not a "R"eviewer).


From Roger.Riggs at oracle.com  Wed May 29 19:25:44 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 29 May 2019 15:25:44 -0400
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
Message-ID: <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>

Hi,

ok, thanks for the comments.

Any other comments on:
"* Runs the garbage collector in the Java Virtual Machine.
* <p>
* Calling this method suggests that the Java Virtual Machine
* expend effort toward recycling unused objects in order to
* make the memory they currently occupy available for reuse
* by the Java Virtual Machine.
* When control returns from the method call, the Java Virtual Machine
* has made a best effort to reclaim space from all discarded objects.
* There is no guarantee that this effort will recycle any particular
* number of unused objects, reclaim any particular amount of space,
* or complete at any particular time, if at all.
"

Issue:
https://bugs.openjdk.java.net/browse/JDK-8220238

CSR:
https://bugs.openjdk.java.net/browse/JDK-8224760

Webrev:
 ? http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238-1/

Thanks, Roger

On 05/29/2019 01:38 PM, Aleksey Shipilev wrote:
> On 5/29/19 5:06 PM, Roger Riggs wrote:
>> The language is hard to construct, in part because of the innovations in gc technology that have
>> resulted such a wide range of behaviors and timing.
>>
>> I'll restore the sentence "When control returns"... but I don't think it carries any
>> definite requirement on an implementation. It is benign since 'best effort' is undefined
>> and depends on the unspecified intentions of the implementation(s).
> "When control returns" does mean things for me (GC implementor). We specifically handle blocking
> callers on System.gc() calls in Shenandoah (and partially in Epsilon). I would not be surprised if
> JCK has tests for that as well.
>
> I think "best effort" is orthogonal to blocking behavior.
>
> -Aleksey
>


From ivan.gerasimov at oracle.com  Wed May 29 19:26:32 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 29 May 2019 12:26:32 -0700
Subject: RFR: 8224986: (str) optimize StringBuilder.append(CharSequence,
 int, int) for String arguments
In-Reply-To: <9a83030f-6199-466a-7034-96c07f9e3535@oracle.com>
References: <9a83030f-6199-466a-7034-96c07f9e3535@oracle.com>
Message-ID: <277dc892-e8d9-a550-f203-b3407194ccf3@oracle.com>

Hi Claes!

It looks like for the cases when this.isLatin1() != s.isLatin1() the 
code is essentially the same as in appendChars(CharSequence, int, int).
So, to save some byte codes (which can actually help with inlining), it 
might have been written as:

private final void appendChars(String s, int off, int end) {
     if (isLatin1() ^ s.isLatin1()) {
         appendChars((CharSequence)s, off, end);
     } else {
         System.arraycopy(s.value(), off << coder, this.value, 
this.count << coder, (end - off) << coder);
         count += end - off;
     }
}

With kind regards,
Ivan

On 5/29/19 8:36 AM, Claes Redestad wrote:
> Hi,
>
> it's been pointed out[1] that append(string.substring(start, end)) can
> outperform append(string, start, end) in some circumstances. In part due
> the former being intrinsified, but also I think due it tickling some
> string concat optimizations that allow for eliding the StringBuilder
> itself completely when there's only one non-constant argument.
>
> While not ruling out intrinsification of append(String, int, int), I was
> able to achieve a reasonable speed-up by peeling off String arguments
> to append(CharSequence, int, int) and dropping into a routine that uses
> System.arraycopy when appropriate.
>
> This seems like a reasonable improvement in the interim, and an
> opportunity to incorporate the relevant microbenchmarks.
>
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8224986
> Webrev: http://cr.openjdk.java.net/~redestad/8224986/open.00/
>
> I extended and incorporated the microbenchmark provided in [1] to also 
> include variants with UTF16 Strings and mixes of arguments, ensuring
> speedups on all appendBounds* variants[2].
>
> Thanks!
>
> /Claes
>
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057834.html
> [2]
> Baseline:
>
> Benchmark            (length)  Mode  Cnt     Score     Error Units
> appendBounds             1000  avgt   10   576.939 ?  21.125 ns/op
>  ?gc.alloc.rate.norm     1000  avgt   10  2144.000 ?   0.001 B/op
> appendBoundsMix          1000  avgt   10   855.308 ?  27.071 ns/op
>  ?gc.alloc.rate.norm     1000  avgt   10  3160.000 ?   0.001 B/op
> appendBoundsUtf16        1000  avgt   10  1424.518 ?  33.319 ns/op
>  ?gc.alloc.rate.norm     1000  avgt   10  5192.000 ?   0.001 B/op
>
> Patch:
>
> Benchmark            (length)  Mode  Cnt     Score     Error Units
> appendBounds             1000  avgt   10   466.640 ?  15.069 ns/op
>  ?gc.alloc.rate.norm     1000  avgt   10  2120.000 ?   0.001 B/op
> appendBoundsMix          1000  avgt   10   758.886 ?  22.983 ns/op
>  ?gc.alloc.rate.norm     1000  avgt   10  3160.000 ?   0.001 B/op
> appendBoundsUtf16        1000  avgt   10  1320.360 ?  49.097 ns/op
>  ?gc.alloc.rate.norm     1000  avgt   10  5192.000 ?   0.001 B/op
>

-- 
With kind regards,
Ivan Gerasimov


From daniel.daugherty at oracle.com  Wed May 29 19:39:54 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 29 May 2019 15:39:54 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
Message-ID: <9939af70-d94e-6f70-f997-76a6ab20084a@oracle.com>

On 5/29/19 1:24 PM, Kim Barrett wrote:
> [I?m not completely sure where this RFR should be sent, but core-libs-dev
> and hotspot-dev seems likely to get reasonable coverage of those who
> might care.]
>
> Please review this change to the test library to add some "logging"
> output to tests that spawn a child process to perform the test and
> then analyze that child's output.  We are seeing occasional timeouts
> in such tests whose cause is hard to pin down.  It's not clear whether
> the excess time is in the child or instead some problem in the testing
> framework.  The new logging output provides timestamps for (1) the
> start of output collection from the child, (2) the start of waiting
> for the child to terminate, and (3) the child's termination.  This
> should be enough to determine whether the child is taking too long,
> and hint at where (e.g. termination or not).
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8219149
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/

test/lib/jdk/test/lib/process/OutputBuffer.java
 ??? Based on the Java doc, it looks like the timestamp portion
 ??? will look something like this:? '2011-12-03T10:15:30Z'

 ??? I like it. Since I've been chasing some of the timeout bugs
 ??? in the CI, I look forward to seeing the new output...

Thumbs up.

Dan


>
> Testing:
> Local hs-tier1 and verified the expected logging output is present.
> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
> caused by the new logging.  (It seems unlikely, but...)
>
>


From vladimir.kozlov at oracle.com  Wed May 29 19:49:46 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 29 May 2019 12:49:46 -0700
Subject: RFR: 8224974: Implement JEP 352
In-Reply-To: <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@redhat.com>
 <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com>
 <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com>
Message-ID: <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com>

Hi, Andrew

I tried to test these changes and build failed on all systems except Linux because:

workspace/open/src/hotspot/share/prims/unsafe.cpp:446:3: error: use of undeclared identifier 'JNU_ThrowRuntimeException'
    JNU_ThrowRuntimeException(env, "writeback is not implemented");
    ^
workspace/open/src/hotspot/share/prims/unsafe.cpp:447:10: error: use of undeclared identifier 'IOS_THROWN'
    return IOS_THROWN;
           ^
workspace/open/src/hotspot/share/prims/unsafe.cpp:473:3: error: use of undeclared identifier 'JNU_ThrowRuntimeException'
    JNU_ThrowRuntimeException(env, "writeback sync is not implemented");
    ^
workspace/open/src/hotspot/share/prims/unsafe.cpp:474:10: error: use of undeclared identifier 'IOS_THROWN'
    return IOS_THROWN;
           ^
workspace/open/src/hotspot/share/prims/unsafe.cpp:488:3: error: use of undeclared identifier 'JNU_ThrowRuntimeException'
    JNU_ThrowRuntimeException(env, "writeback sync is not implemented");
    ^
workspace/open/src/hotspot/share/prims/unsafe.cpp:489:10: error: use of undeclared identifier 'IOS_THROWN'
    return IOS_THROWN;
------------------------------------------------------------
Also Graal test should be fixed for new intrinsics (add them to 'toBeInvestigated' for isJDK13orHigher):

src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java

java.lang.AssertionError: missing Graal intrinsics for:
     jdk/internal/misc/Unsafe.writeback0(J)V
     jdk/internal/misc/Unsafe.writebackPostSync0()V
     jdk/internal/misc/Unsafe.writebackPreSync0()V
	at org.graalvm.compiler.hotspot.test.CheckGraalIntrinsics.test(CheckGraalIntrinsics.java:653)

Regards,
Vladimir

On 5/29/19 5:50 AM, Andrew Dinn wrote:
> Hi Alan,
> 
> Apologies for the previous post which escaped from the lab while Dr
> Funkenstein was struggling to push the right buttons (and work out what
> happened when he pushed them).
> 
> I have created an implementation subtask and associated CSR. I also
> updated the last webrev to record the javadoc changes necessitated in
> order to complete the CSR. Finally, I set the JEP fix version to 13 and
> pressed the big red "target" button.
> 
> Impl JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974
> CSR JIRA:  https://bugs.openjdk.java.net/browse/JDK-8224975
> webrev:    http://cr.openjdk.java.net/~adinn/8224974/webrev.02/
> 
> n.b. I have switched to using the subtask JIRA id in $title and in the
> cr.openjdk webrev link ...
> 
> 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 kim.barrett at oracle.com  Wed May 29 19:53:17 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 29 May 2019 15:53:17 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <9939af70-d94e-6f70-f997-76a6ab20084a@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <9939af70-d94e-6f70-f997-76a6ab20084a@oracle.com>
Message-ID: <381D624B-DEE1-4E67-9142-FD34B716634B@oracle.com>

> On May 29, 2019, at 3:39 PM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
> 
> On 5/29/19 1:24 PM, Kim Barrett wrote:
>> [I?m not completely sure where this RFR should be sent, but core-libs-dev
>> and hotspot-dev seems likely to get reasonable coverage of those who
>> might care.]
>> 
>> Please review this change to the test library to add some "logging"
>> output to tests that spawn a child process to perform the test and
>> then analyze that child's output.  We are seeing occasional timeouts
>> in such tests whose cause is hard to pin down.  It's not clear whether
>> the excess time is in the child or instead some problem in the testing
>> framework.  The new logging output provides timestamps for (1) the
>> start of output collection from the child, (2) the start of waiting
>> for the child to terminate, and (3) the child's termination.  This
>> should be enough to determine whether the child is taking too long,
>> and hint at where (e.g. termination or not).
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8219149
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/
> 
> test/lib/jdk/test/lib/process/OutputBuffer.java
>     Based on the Java doc, it looks like the timestamp portion
>     will look something like this:  '2011-12-03T10:15:30Z?

The timestamp includes trailing ?.microseconds? (at least, it looks like microseconds).

>     I like it. Since I've been chasing some of the timeout bugs
>     in the CI, I look forward to seeing the new output...
> 
> Thumbs up.

Thanks.


From brent.christian at oracle.com  Wed May 29 20:14:22 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 29 May 2019 13:14:22 -0700
Subject: RFR 8224789 : Parsing repetition count in regex does not detect
 numeric overflow
In-Reply-To: <fe0bbeff-5703-4590-b741-a69c38055e7d@oracle.com>
References: <f91a2861-05b7-cc3e-19d7-c92f9514b914@oracle.com>
 <c91b94d9-93b1-59dd-b04e-cc6e6a6b9a53@oracle.com>
 <7ad74482-a718-e51d-46b9-de0e60547973@oracle.com>
 <fe0bbeff-5703-4590-b741-a69c38055e7d@oracle.com>
Message-ID: <c445c69d-4967-3647-bf40-82ed8425e4de@oracle.com>

Looks fine.  Thanks, Ivan.

-Brent

On 5/29/19 7:27 AM, Roger Riggs wrote:
> Thanks Ivan,? Looks good.
> 
> 
> On 05/28/2019 10:08 PM, Ivan Gerasimov wrote:
>> Hi Brent!
>>
>>
>> On 5/28/19 4:06 PM, Brent Christian wrote:
>>> Hi, Ivan
>>>
>>> I agree with Roger that there are more test cases than necessary. 
>>> Otherwise I think it looks pretty good.
>>>
>> Okay.? Then let's make the list of invalid ranges shorter, but add a 
>> randomly generated value!
>>
>> Please find the updated webrev here:
>> http://cr.openjdk.java.net/~igerasim/8224789/01/webrev/
>>
>> With kind regards,
>> Ivan
>>
>>> I find the addExact/multiplyExact code less readable. I'm not sure 
>>> what could be done about it - maybe some different indentation:
>>>
>>> cmin = Math.addExact(
>>> ???????????????????? Math.multiplyExact(cmin, 10),
>>> ???????????????????? ch - '0');
>>>
>>> though that makes for some long lines.? Just a thought.
>>>
>>> Thanks,
>>> -Brent
>>>
>>> On 5/24/19 11:28 PM, Ivan Gerasimov wrote:
>>>> Hello!
>>>>
>>>> When Pattern.compile() parses the repetition count in the 
>>>> expressions like '.{100}', '.{1,2}' or '.{3,}' it fails to detect 
>>>> numeric overflow if the result is still non-negative.
>>>>
>>>> Could you please help review the patch?
>>>>
>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8224789
>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8224789/00/webrev/
>>>>
>>>> Also, reading a char at line 3274 is done with skip(), so the 
>>>> exception thrown at 3315 displays the position of the error more 
>>>> accurately.
>>>>
>>>
>>
> 

From claes.redestad at oracle.com  Wed May 29 20:20:22 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 29 May 2019 22:20:22 +0200
Subject: RFR: 8224986: (str) optimize StringBuilder.append(CharSequence,
 int, int) for String arguments
In-Reply-To: <277dc892-e8d9-a550-f203-b3407194ccf3@oracle.com>
References: <9a83030f-6199-466a-7034-96c07f9e3535@oracle.com>
 <277dc892-e8d9-a550-f203-b3407194ccf3@oracle.com>
Message-ID: <b4a7c6f3-d9ed-ce80-cbce-e552a7727d76@oracle.com>

Hi Ivan,

interesting suggestion. I should try it out.

Also keep in mind that inlining decisions are sensitive to call depth,
and that my current patch peels off String in such a way that
appendChars(CharSequence, int, int) will never see a String argument, 
which... Argh... :-)

/Claes

On 2019-05-29 21:26, Ivan Gerasimov wrote:
> Hi Claes!
> 
> It looks like for the cases when this.isLatin1() != s.isLatin1() the 
> code is essentially the same as in appendChars(CharSequence, int, int).
> So, to save some byte codes (which can actually help with inlining), it 
> might have been written as:
> 
> private final void appendChars(String s, int off, int end) {
>  ??? if (isLatin1() ^ s.isLatin1()) {
>  ??????? appendChars((CharSequence)s, off, end);
>  ??? } else {
>  ??????? System.arraycopy(s.value(), off << coder, this.value, 
> this.count << coder, (end - off) << coder);
>  ??????? count += end - off;
>  ??? }
> }
> 
> With kind regards,
> Ivan
> 
> On 5/29/19 8:36 AM, Claes Redestad wrote:
>> Hi,
>>
>> it's been pointed out[1] that append(string.substring(start, end)) can
>> outperform append(string, start, end) in some circumstances. In part due
>> the former being intrinsified, but also I think due it tickling some
>> string concat optimizations that allow for eliding the StringBuilder
>> itself completely when there's only one non-constant argument.
>>
>> While not ruling out intrinsification of append(String, int, int), I was
>> able to achieve a reasonable speed-up by peeling off String arguments
>> to append(CharSequence, int, int) and dropping into a routine that uses
>> System.arraycopy when appropriate.
>>
>> This seems like a reasonable improvement in the interim, and an
>> opportunity to incorporate the relevant microbenchmarks.
>>
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8224986
>> Webrev: http://cr.openjdk.java.net/~redestad/8224986/open.00/
>>
>> I extended and incorporated the microbenchmark provided in [1] to also 
>> include variants with UTF16 Strings and mixes of arguments, ensuring
>> speedups on all appendBounds* variants[2].
>>
>> Thanks!
>>
>> /Claes
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057834.html 
>>
>> [2]
>> Baseline:
>>
>> Benchmark??????????? (length)? Mode? Cnt???? Score???? Error Units
>> appendBounds???????????? 1000? avgt?? 10?? 576.939 ?? 21.125 ns/op
>> ??gc.alloc.rate.norm???? 1000? avgt?? 10? 2144.000 ??? 0.001 B/op
>> appendBoundsMix????????? 1000? avgt?? 10?? 855.308 ?? 27.071 ns/op
>> ??gc.alloc.rate.norm???? 1000? avgt?? 10? 3160.000 ??? 0.001 B/op
>> appendBoundsUtf16??????? 1000? avgt?? 10? 1424.518 ?? 33.319 ns/op
>> ??gc.alloc.rate.norm???? 1000? avgt?? 10? 5192.000 ??? 0.001 B/op
>>
>> Patch:
>>
>> Benchmark??????????? (length)? Mode? Cnt???? Score???? Error Units
>> appendBounds???????????? 1000? avgt?? 10?? 466.640 ?? 15.069 ns/op
>> ??gc.alloc.rate.norm???? 1000? avgt?? 10? 2120.000 ??? 0.001 B/op
>> appendBoundsMix????????? 1000? avgt?? 10?? 758.886 ?? 22.983 ns/op
>> ??gc.alloc.rate.norm???? 1000? avgt?? 10? 3160.000 ??? 0.001 B/op
>> appendBoundsUtf16??????? 1000? avgt?? 10? 1320.360 ?? 49.097 ns/op
>> ??gc.alloc.rate.norm???? 1000? avgt?? 10? 5192.000 ??? 0.001 B/op
>>
> 

From joe.darcy at oracle.com  Wed May 29 20:58:16 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 29 May 2019 13:58:16 -0700
Subject: RFR 8224789 : Parsing repetition count in regex does not detect
 numeric overflow
In-Reply-To: <c445c69d-4967-3647-bf40-82ed8425e4de@oracle.com>
References: <f91a2861-05b7-cc3e-19d7-c92f9514b914@oracle.com>
 <c91b94d9-93b1-59dd-b04e-cc6e6a6b9a53@oracle.com>
 <7ad74482-a718-e51d-46b9-de0e60547973@oracle.com>
 <fe0bbeff-5703-4590-b741-a69c38055e7d@oracle.com>
 <c445c69d-4967-3647-bf40-82ed8425e4de@oracle.com>
Message-ID: <c7f85790-2bf6-b0a6-57a8-228ec24ae9a9@oracle.com>

As an academic note, note that non-overflowing strings can be recognized 
with a regex :-)

For signed numbers in base 10:

# MAX_VALUE in base 10: 2147483647

((-)?0*((\p{Digit}){1,9})
|([0-1]\p{Digit}{9})
|(20\p{Digit}{8})
|(21[0-3]\p{Digit}{7})
|(214[0-6]\p{Digit}{6})
|(2147[0-3]\p{Digit}{5})
|(21474[0-7]\p{Digit}{4})
|(214748[0-2]\p{Digit}{3})
|(2147483[0-5]\p{Digit}{2})
|(21474836[0-3]\p{Digit}{1})
|(214748364[0-7])
)|
(-0*2147483648)

-Joe

On 5/29/2019 1:14 PM, Brent Christian wrote:
> Looks fine.? Thanks, Ivan.
>
> -Brent
>
> On 5/29/19 7:27 AM, Roger Riggs wrote:
>> Thanks Ivan,? Looks good.
>>
>>
>> On 05/28/2019 10:08 PM, Ivan Gerasimov wrote:
>>> Hi Brent!
>>>
>>>
>>> On 5/28/19 4:06 PM, Brent Christian wrote:
>>>> Hi, Ivan
>>>>
>>>> I agree with Roger that there are more test cases than necessary. 
>>>> Otherwise I think it looks pretty good.
>>>>
>>> Okay.? Then let's make the list of invalid ranges shorter, but add a 
>>> randomly generated value!
>>>
>>> Please find the updated webrev here:
>>> http://cr.openjdk.java.net/~igerasim/8224789/01/webrev/
>>>
>>> With kind regards,
>>> Ivan
>>>
>>>> I find the addExact/multiplyExact code less readable. I'm not sure 
>>>> what could be done about it - maybe some different indentation:
>>>>
>>>> cmin = Math.addExact(
>>>> ???????????????????? Math.multiplyExact(cmin, 10),
>>>> ???????????????????? ch - '0');
>>>>
>>>> though that makes for some long lines.? Just a thought.
>>>>
>>>> Thanks,
>>>> -Brent
>>>>
>>>> On 5/24/19 11:28 PM, Ivan Gerasimov wrote:
>>>>> Hello!
>>>>>
>>>>> When Pattern.compile() parses the repetition count in the 
>>>>> expressions like '.{100}', '.{1,2}' or '.{3,}' it fails to detect 
>>>>> numeric overflow if the result is still non-negative.
>>>>>
>>>>> Could you please help review the patch?
>>>>>
>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8224789
>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8224789/00/webrev/
>>>>>
>>>>> Also, reading a char at line 3274 is done with skip(), so the 
>>>>> exception thrown at 3315 displays the position of the error more 
>>>>> accurately.
>>>>>
>>>>
>>>
>>

From naoto.sato at oracle.com  Wed May 29 21:12:48 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 29 May 2019 14:12:48 -0700
Subject: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on
 Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM
Message-ID: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>

Hi,

Please review the fix for the following issue:

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

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing with 
SMART resolver style to throw a DateTimeParseException. This is a change 
in which an app will start to see an exception with incorrect data, but 
that is what should be in the first place.

Naoto

From lance.andersen at oracle.com  Wed May 29 21:21:11 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 29 May 2019 17:21:11 -0400
Subject: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception
 on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM
In-Reply-To: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
References: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
Message-ID: <440DA6E9-B556-4932-B2A7-BBCC77F8AF48@oracle.com>

Hi Naoto,

This is OK.

Could you please add an @summary as it is missing so that we are consistent with other tests.

No need to spin a webrev again though


Best
Lance
> On May 29, 2019, at 5:12 PM, naoto.sato at oracle.com wrote:
> 
> Hi,
> 
> Please review the fix for the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8223773
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
> 
> Checking the range of HourOfAmPm with the range of AmPmOfDay is apparently incorrect. Fixing it will change the behavior of parsing with SMART resolver style to throw a DateTimeParseException. This is a change in which an app will start to see an exception with incorrect data, but that is what should be in the first place.
> 
> Naoto

 <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  Wed May 29 21:24:47 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 29 May 2019 14:24:47 -0700
Subject: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception
 on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM
In-Reply-To: <440DA6E9-B556-4932-B2A7-BBCC77F8AF48@oracle.com>
References: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
 <440DA6E9-B556-4932-B2A7-BBCC77F8AF48@oracle.com>
Message-ID: <1d1c4f25-c4cb-04a9-e83d-048496ef3c8a@oracle.com>

Thanks, Lance.

Sure, will update the test case with @summary.

Naoto

On 5/29/19 2:21 PM, Lance Andersen wrote:
> Hi Naoto,
> 
> This is OK.
> 
> Could you please add an @summary as it is missing so that we are 
> consistent with other tests.
> 
> No need to spin a webrev again though
> 
> 
> Best
> Lance
>> On May 29, 2019, at 5:12 PM, naoto.sato at oracle.com 
>> <mailto:naoto.sato at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review the fix for the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8223773
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
>>
>> Checking the range of HourOfAmPm with the range of AmPmOfDay is 
>> apparently incorrect. Fixing it will change the behavior of parsing 
>> with SMART resolver style to throw a DateTimeParseException. This is a 
>> change in which an app will start to see an exception with incorrect 
>> data, but that is what should be in the first place.
>>
>> Naoto
> 
> <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 ivan.gerasimov at oracle.com  Wed May 29 21:39:48 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 29 May 2019 14:39:48 -0700
Subject: RFR 8224716 : Javadoc of Int/Long/DoubleSummaryStatistics should
 mention possible overflow of count
Message-ID: <2067b2c4-ba6e-2b00-859c-a34bdd5db8f9@oracle.com>

Hello!

In the implNote section of the javadoc for xxxSummaryStatistics classes 
it is mentioned that the sum is not checked for overflow.
It would be more accurate to add that neither does the implementation 
check the count for overflow.

Would you please help review this doc-only change?

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

-- 
With kind regards,
Ivan Gerasimov


From leonid.mesnik at oracle.com  Wed May 29 21:56:33 2019
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Wed, 29 May 2019 14:56:33 -0700
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
Message-ID: <c4ee5478-5d56-d86a-7a13-740a059678fe@oracle.com>

Looks good.

Leonid

On 5/29/19 10:24 AM, Kim Barrett wrote:
> [I?m not completely sure where this RFR should be sent, but core-libs-dev
> and hotspot-dev seems likely to get reasonable coverage of those who
> might care.]
>
> Please review this change to the test library to add some "logging"
> output to tests that spawn a child process to perform the test and
> then analyze that child's output.  We are seeing occasional timeouts
> in such tests whose cause is hard to pin down.  It's not clear whether
> the excess time is in the child or instead some problem in the testing
> framework.  The new logging output provides timestamps for (1) the
> start of output collection from the child, (2) the start of waiting
> for the child to terminate, and (3) the child's termination.  This
> should be enough to determine whether the child is taking too long,
> and hint at where (e.g. termination or not).
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8219149
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/
>
> Testing:
> Local hs-tier1 and verified the expected logging output is present.
> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
> caused by the new logging.  (It seems unlikely, but...)
>
>

From david.holmes at oracle.com  Wed May 29 22:10:50 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 May 2019 08:10:50 +1000
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
Message-ID: <8ab1effc-5828-4ba1-5ca1-1edc36c4eff0@oracle.com>

Hi Roger,

I think it is important that the "best effort" be kept as per this 
version. It may not be a directly testable property but it does capture 
intent regarding quality-of-implementation IMO.

Thanks,
David

On 30/05/2019 5:25 am, Roger Riggs wrote:
> Hi,
> 
> ok, thanks for the comments.
> 
> Any other comments on:
> "* Runs the garbage collector in the Java Virtual Machine.
> * <p>
> * Calling this method suggests that the Java Virtual Machine
> * expend effort toward recycling unused objects in order to
> * make the memory they currently occupy available for reuse
> * by the Java Virtual Machine.
> * When control returns from the method call, the Java Virtual Machine
> * has made a best effort to reclaim space from all discarded objects.
> * There is no guarantee that this effort will recycle any particular
> * number of unused objects, reclaim any particular amount of space,
> * or complete at any particular time, if at all.
> "
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8220238
> 
> CSR:
> https://bugs.openjdk.java.net/browse/JDK-8224760
> 
> Webrev:
>  ? http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238-1/
> 
> Thanks, Roger
> 
> On 05/29/2019 01:38 PM, Aleksey Shipilev wrote:
>> On 5/29/19 5:06 PM, Roger Riggs wrote:
>>> The language is hard to construct, in part because of the innovations 
>>> in gc technology that have
>>> resulted such a wide range of behaviors and timing.
>>>
>>> I'll restore the sentence "When control returns"... but I don't think 
>>> it carries any
>>> definite requirement on an implementation. It is benign since 'best 
>>> effort' is undefined
>>> and depends on the unspecified intentions of the implementation(s).
>> "When control returns" does mean things for me (GC implementor). We 
>> specifically handle blocking
>> callers on System.gc() calls in Shenandoah (and partially in Epsilon). 
>> I would not be surprised if
>> JCK has tests for that as well.
>>
>> I think "best effort" is orthogonal to blocking behavior.
>>
>> -Aleksey
>>
> 

From Sergey.Bylokhov at oracle.com  Wed May 29 22:22:17 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 29 May 2019 15:22:17 -0700
Subject: <AWT Dev> RFR: 8223271: SplashScreen is still shown if defaulting
 to headless on MacOS
In-Reply-To: <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com>
References: <a8c59f97-d1b2-570d-3e9a-a665fdfc9bb9@oracle.com>
 <22ee90fd-4775-b107-a28b-0c70052b4f7c@oracle.com>
Message-ID: <a4126d1d-e5e8-c0f0-7d2f-aba2c5be7501@oracle.com>

Looks fine.


On 29/05/2019 11:38, Phil Race wrote:
> Any takers ?
> 
> -phil.
> 
> On 5/24/19 9:35 AM, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223271
>> Webrev : http://cr.openjdk.java.net/~prr/8223271/
>>
>> Whilst working on removing some inappropriate coupling of the java launcher and the desktop module,
>> and testing out the -splash option, I noticed that on MacOS, in the case when we *default* to headless
>> mode (which happens when we determine that we are not in a desktop session), the launcher still
>> invokes the splash screen code. This could cause an application to completely hang.
>>
>> The problem is explained in detail in the bug report, but briefly, the launcher isn't aware of this
>> defaulting to headless. And the calls the launcher makes to the dynamically loaded splashscreen
>> code, don't return any value it can use to be aware of this.
>>
>> So this fix updates "DoSplashInit()" to return such a code, and in the event of a headful session
>> not being available, it can bail out and not try to show the splashscreen.
>> That is the gist of the small set of changes in java.c that relate to this fix.
>>
>> However I also observed a small memory leak.
>> There are static variables
>>
>> static char* splash_jar_entry = NULL; static char* splash_file_entry = NULL;
>> which are meant to hold the location of the splash image.
>> When everything is done the malloced storage these point to is freed ...
>> except that the malloc code looks like this :-
>>
>> char* splash_file_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_FILE_ENV_ENTRY "=")+JLI_StrLen(splash_file_name)+1);
>> char* splash_jar_entry = JLI_MemAlloc(JLI_StrLen(SPLASH_JAR_ENV_ENTRY "=")+JLI_StrLen(splash_jar_name)+1);
>>
>> So the static vars are never used and the storage pointed to by local variables is never freed.
>>
>> So I am fixing that too.
>>
>> The rest of the fix is in the splashscreen code in the desktop module and it implements
>> the return of the status code described above.
>>
>> There was one leak there too - a stream was not closed in a case where the splash could
>> not be displayed.
>>
>> The regression tests for splash screen were run, but testing this is more an environmental issue -
>> sshing into a MacOS system and running tests and demos which would try to display a splash
>> and verifying they no longer do, so I didn't see a way to add a specific regression test.
>>
>> -phil.
>>
>>
>>
>>
>>
> 


-- 
Best regards, Sergey.

From hboehm at google.com  Wed May 29 22:36:31 2019
From: hboehm at google.com (Hans Boehm)
Date: Wed, 29 May 2019 15:36:31 -0700
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
Message-ID: <CAMOCf+iv=8yLhaimsR4ojSDv_KinszJ1KSTSEfTbS89hrxFWhA@mail.gmail.com>

Thanks! I like the revision better.

I think ideally it should be possible to provide GC hooks that would allow
somewhat plentiful, but limited, resources like file descriptors to be
managed by the GC. Using References rather than finalizers should help, in
that you no longer have to wait for arbitrary finalizers when opening a
file, which was deadlock-prone.

Hans

On Wed, May 29, 2019 at 8:06 AM Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Hans,
>
> The language is hard to construct, in part because of the innovations in
> gc technology that have
> resulted such a wide range of behaviors and timing.
>
> I'll restore the sentence "When control returns"... but I don't think it
> carries any
> definite requirement on an implementation. It is benign since 'best
> effort' is undefined
> and depends on the unspecified intentions of the implementation(s).
>
> On 05/28/2019 07:36 PM, Hans Boehm wrote:
>
> I agree with Aleksey's concern.
>
> AFAICT, these methods are usually used for one of two purposes:
>
> 1) Let the implementation know that this would be a good time to garbage
> collect because the application is likely to remain idle for a while.
>
> "suggests that"...
>
>
> 2) Ensure that as many references as possible have been enqueued, and
> traditionally, with runFinalization(), to ensure that as many finalizers as
> possible have been run. If I run out of some resource managed this way, I
> may want to try this before giving up.
>
> The behaviors of reference types, including finalization, are described
> elsewhere
> and are just as dependent on the particular gc implementation as making
> memory available for reuse.
>
>
> I don't think this API was ever that well suited to either of these. For
> (1), I really want a call that says "garbage collect if we're n% of the way
> to triggering the next GC". For (2), I really want a call that does
> precisely that but, so long as we still have finalizers, with a better
> specification of what happens if I hold a lock needed by a finalizer.
>
> I'm a bit concerned that with the watered-down spec, (2) becomes
> completely unimplementable. (1) was already kind of unimplementable, since
> it's hard to avoid triggering way too many GCs in a row. In my mind, this
> raises the question of whether these are actually still useful.
>
> Timely recovery of resources based on gc side effects is a poor mechanism
> (except perhaps for memory), because gc behavior is so varied.
>
> I didn't see this change as watering down the spec but to make it clear
> that it already does not make any guarantees.
>
> Thanks, Roger
>
>
>
> On Tue, May 28, 2019 at 1:55 PM Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Hi Aleksey,
>>
>> The </p> is always optional (in html5).
>>
>> The issue with the "when control returns" and "best effort" sentence is
>> that is implies that something has been done
>> and that is not necessarily true.  At best, it could say is that the
>> implementation may have done something or done nothing
>> and anything in between.
>>
>> Suggestions welcome.
>>
>> Thanks, Roger
>>
>>
>>
>> On 05/28/2019 02:06 PM, Aleksey Shipilev wrote:
>> > On 5/28/19 7:58 PM, Roger Riggs wrote:
>> >> Please review a change to the javadoc of Runtime.gc() and System.gc()
>> to clarify
>> >> that invoking these methods does not guarantee any specific result or
>> timeliness
>> >> of completion.
>> >>
>> >> The revised text is:
>> >>
>> >>        * Runs the garbage collector in the Java Virtual Machine.
>> >>        *
>> >>        * Calling this method suggests that the Java Virtual Machine
>> >>        * expend effort toward recycling unused objects in order to
>> >>        * make the memory they currently occupy available for reuse
>> >>        * by the Java Virtual Machine.
>> >>        * There is no guarantee that this effort will recycle any
>> particular
>> >>        * number of unused objects, reclaim any particular amount of
>> space,
>> >>        * or complete at any particular time, if at all.
>> >>
>> >> Issue:
>> >>    https://bugs.openjdk.java.net/browse/JDK-8220238
>> >>
>> >> CSR:
>> >>    https://bugs.openjdk.java.net/browse/JDK-8224760
>> >>
>> >> Webrev:
>> >>    http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238/index.html
>> > Thank you.
>> >
>> > It feels like <p/> is missing between paragraphs?
>> >
>> > Also, I don't think it is sensible to drop the blocking behavior ("When
>> control returns...") -- I
>> > think some programs enjoy that property, and certainly many GCs have
>> special tests to enforce this
>> > property, even if GC is fully concurrent.
>> >
>>
>>
>

From joe.darcy at oracle.com  Wed May 29 22:51:05 2019
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 29 May 2019 15:51:05 -0700
Subject: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception
 on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM
In-Reply-To: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
References: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
Message-ID: <5CEF0CD9.1020007@oracle.com>

Hi Naoto,

Should this bug get a CSR for the behavioral change?

Cheers,

-Joe

On 5/29/2019 2:12 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8223773
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
>
> Checking the range of HourOfAmPm with the range of AmPmOfDay is 
> apparently incorrect. Fixing it will change the behavior of parsing 
> with SMART resolver style to throw a DateTimeParseException. This is a 
> change in which an app will start to see an exception with incorrect 
> data, but that is what should be in the first place.
>
> Naoto


From naoto.sato at oracle.com  Wed May 29 22:55:25 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 29 May 2019 15:55:25 -0700
Subject: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception
 on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM
In-Reply-To: <5CEF0CD9.1020007@oracle.com>
References: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
 <5CEF0CD9.1020007@oracle.com>
Message-ID: <606b31aa-86b5-d862-5b8e-51da87d30659@oracle.com>

Hi Joe,

Right, I will file a corresponding CSR.

Naoto

On 5/29/19 3:51 PM, Joseph D. Darcy wrote:
> Hi Naoto,
> 
> Should this bug get a CSR for the behavioral change?
> 
> Cheers,
> 
> -Joe
> 
> On 5/29/2019 2:12 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix for the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8223773
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
>>
>> Checking the range of HourOfAmPm with the range of AmPmOfDay is 
>> apparently incorrect. Fixing it will change the behavior of parsing 
>> with SMART resolver style to throw a DateTimeParseException. This is a 
>> change in which an app will start to see an exception with incorrect 
>> data, but that is what should be in the first place.
>>
>> Naoto
> 

From kim.barrett at oracle.com  Wed May 29 22:59:53 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 29 May 2019 18:59:53 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <c4ee5478-5d56-d86a-7a13-740a059678fe@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <c4ee5478-5d56-d86a-7a13-740a059678fe@oracle.com>
Message-ID: <72F8035F-A14C-4419-81BA-6FB38385CBFB@oracle.com>

> On May 29, 2019, at 5:56 PM, Leonid Mesnik <leonid.mesnik at oracle.com> wrote:
> 
> Looks good.

Thanks.

> 
> Leonid
> 
> On 5/29/19 10:24 AM, Kim Barrett wrote:
>> [I?m not completely sure where this RFR should be sent, but core-libs-dev
>> and hotspot-dev seems likely to get reasonable coverage of those who
>> might care.]
>> 
>> Please review this change to the test library to add some "logging"
>> output to tests that spawn a child process to perform the test and
>> then analyze that child's output.  We are seeing occasional timeouts
>> in such tests whose cause is hard to pin down.  It's not clear whether
>> the excess time is in the child or instead some problem in the testing
>> framework.  The new logging output provides timestamps for (1) the
>> start of output collection from the child, (2) the start of waiting
>> for the child to terminate, and (3) the child's termination.  This
>> should be enough to determine whether the child is taking too long,
>> and hint at where (e.g. termination or not).
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8219149
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/
>> 
>> Testing:
>> Local hs-tier1 and verified the expected logging output is present.
>> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
>> caused by the new logging.  (It seems unlikely, but...)



From mandy.chung at oracle.com  Wed May 29 23:24:00 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 29 May 2019 16:24:00 -0700
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
Message-ID: <2f8803cd-fbd8-6ccc-2407-a2f51ffb6073@oracle.com>



On 5/30/19 3:25 AM, Roger Riggs wrote:
> Hi,
>
> ok, thanks for the comments.
>
> Any other comments on:
> "* Runs the garbage collector in the Java Virtual Machine.
> * <p>
> * Calling this method suggests that the Java Virtual Machine
> * expend effort toward recycling unused objects in order to
> * make the memory they currently occupy available for reuse
> * by the Java Virtual Machine.
> * When control returns from the method call, the Java Virtual Machine
> * has made a best effort to reclaim space from all discarded objects.
> * There is no guarantee that this effort will recycle any particular
> * number of unused objects, reclaim any particular amount of space,
> * or complete at any particular time, if at all.
> "
>

This version looks good.? Nit: It may read better to say "reclaim space 
from unused objects" as described in the following sentence.

> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8220238
>
> CSR:
> https://bugs.openjdk.java.net/browse/JDK-8224760
>

Reviewed.

> Webrev:
> ? http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238-1/
>

Mandy

From david.holmes at oracle.com  Thu May 30 04:42:32 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 May 2019 14:42:32 +1000
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
Message-ID: <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>

Adding back hotspot-dev. I don't think Kim saw this.

David

On 30/05/2019 4:04 am, Roger Riggs wrote:
> Hi Kim,
> 
> In the normal output less output is cleaner.
> It would be more useful to have the Duration of the wait and end time of 
> the wait.
> (It saves the reader doing subtraction of times).
> 
> +????????? Instant start = Instant.now();
> +????????? boolean aborted = true;
> +????????? try {
> +????????????? int result = p.waitFor();
> +????????????? aborted = false;
> +????????????? return result;
> +????????? } finally {
> +????????????? Duration dur = Duration.between(start, Instant.now());
> +????????????? if (aborted) {
> +????????????????? logProgress("Waiting for completion FAILED after: " + 
> dur);
> +????????????? } else {
> +????????????????? logProgress("Waiting for completion finished after: " 
> + dur);
> +????????????? }
> +????????? }
> 
> Or something like that.
> 
> Roger
> 
> 
> On 05/29/2019 01:24 PM, Kim Barrett wrote:
>> [I?m not completely sure where this RFR should be sent, but core-libs-dev
>> and hotspot-dev seems likely to get reasonable coverage of those who
>> might care.]
>>
>> Please review this change to the test library to add some "logging"
>> output to tests that spawn a child process to perform the test and
>> then analyze that child's output.? We are seeing occasional timeouts
>> in such tests whose cause is hard to pin down.? It's not clear whether
>> the excess time is in the child or instead some problem in the testing
>> framework.? The new logging output provides timestamps for (1) the
>> start of output collection from the child, (2) the start of waiting
>> for the child to terminate, and (3) the child's termination.? This
>> should be enough to determine whether the child is taking too long,
>> and hint at where (e.g. termination or not).
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8219149
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/
>>
>> Testing:
>> Local hs-tier1 and verified the expected logging output is present.
>> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
>> caused by the new logging.? (It seems unlikely, but...)
>>
>>
> 

From david.holmes at oracle.com  Thu May 30 05:39:19 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 May 2019 15:39:19 +1000
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <874l5ktb26.fsf@oldenburg2.str.redhat.com>
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <46688d0d-1e7d-6c9e-0783-3adaec26c037@oracle.com>
 <874l5ktb26.fsf@oldenburg2.str.redhat.com>
Message-ID: <f9f6d75b-8ef0-7018-b6d8-db2a0a59733e@oracle.com>

Hi Florian,

On 24/05/2019 8:13 pm, Florian Weimer wrote:
> * David Holmes:
> 
>> My thoughts haven't really changed since 2015 - and sadly neither has
>> there been any change in glibc in that time. Nor, to my recollection,
>> have there been any other reported issues with this.
> 
> The issue gets occasionally reported by people who use small stacks with
> large initial-exec TLS consumers (such as jemalloc).  On the glibc side,
> we aren't entirely sure what to do about this.  We have recently tweaked
> the stack size computation, so that in many cases, threads now receive
> an additional page.  This was necessary to work around a kernel/hardware
> change where context switches started to push substantially more data on
> the stack than before, and minimal stack sizes did not work anymore on
> x86-64 (leading to ntpd crashing during startup, among other things).
> 
> The main concern is that for workloads with carefully tuned stack sizes,
> revamping the stack size computation so that TLS is no longer
> effectively allocated on the stack might result in address space
> exhaustion.  (This should only be a concern on 32-bit architectures.)
> 
> Even if we changed this today (or had changed it in 2015), it would take
> a long time for the change to end up with end users, so it's unclear how
> much help it would be.

If it had been fixed in 2012 it wouldn't be an issue today. If it gets 
fixed today then it may not be an issue in 2025. If it is not fixed then 
it will always be an issue. Stealing the TLS space out of the stack 
requested by the user is just not a reasonable thing to do IMHO.

> Maybe OpenJDK can add a property specifying a stack size reserve, and
> htis number is added to all stack size requests?  This will at least
> allow users to work around the issue locally.

This would be a low-impact workaround, though as Jiangli points out it 
is a bit hard on the end-user as they first have to hit the problem, 
then recognize what it is, then realize there's a potential solution and 
then determine the right magic number to use. Better than nothing but 
not ideal.

Further follow up coming in response to your later email.

Cheers,
David
-----

> 
> If we change the accounting in glibc, we will have to add a similar
> tunable on the glibc side, too.
> 
> Thanks,
> Florian
> 

From david.holmes at oracle.com  Thu May 30 05:42:25 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 May 2019 15:42:25 +1000
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <87y32vmvaq.fsf@oldenburg2.str.redhat.com>
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <87ftp4tcas.fsf@oldenburg2.str.redhat.com>
 <CALrW1jxB2A9iV-i4vuip2xriH4ZVfHy6-M2eYhrhoOOBYbdY6w@mail.gmail.com>
 <87y32vmvaq.fsf@oldenburg2.str.redhat.com>
Message-ID: <15ebac14-1e15-3b1c-79a8-175760939b50@oracle.com>

Hi Florian,

On 25/05/2019 6:50 am, Florian Weimer wrote:
> * Jiangli Zhou:
> 
>> Hi Florian,
>>
>> On Fri, May 24, 2019 at 2:46 AM Florian Weimer <fweimer at redhat.com> wrote:
>>>
>>> * Jiangli Zhou:
>>>
>>>> [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
>>>> (contributed by Jeremy Manson)
>>>
>>> _dl_get_tls_static_info is an internal symbol (it carries a
>>> GLIBC_PRIVATE symbol version).  Its implementation can change at any
>>> time.  Please do not do this.
>>
>> Point taken. Thanks.
>>
>> It appears that asan is already carrying the same type of fix:
>>
>> https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
>>
>> As the issue has not been able to be addressed in the glibc layer, all
>> the others have to workaround it (and possibly by using the glibc
>> private APIs, _dl_get_tls_static_info or __pthread_get_minstack). That
>> would cause more dependencies on the private APIs.
> 
> _dl_get_tls_static_info changed ABI on i386 in glibc 2.27 already, so
> you really don't want to use that (in case someone backported that
> cleanup to an earlier version, although that might be bit unlikely).
> 
> The sanitizers are special and have a much shorter shelf life than the
> OpenJDK binaries.
> 
>> One alternative (besides fixing glibc) may be making
>> _dl_get_tls_static_info public. Would that be possible?
> 
> For __pthread_get_minstack, I can add a comment to the glibc sources
> that if the ABI changes (or if TLS allocations are no longer considered
> part of the stack), we should rename the function.  Then, as long as you
> use a weak reference or dlsym (the latter is preferable for the sack of
> RPM-based distributions which require special steps to reference
> GLIBC_PRIVATE symbols directly), old binaries would keep working if we
> make further changes.
> 
> Since _dl_get_tls_static_info already changed ABI once, I really can't
> recommend its use.  Especially if you can work with
> __pthread_get_minstack instead.

Can you explain for me what value this __pthread_get_minstack is defined 
to return? Will it accommodate any required TLS plus some other glibc 
specific overhead? How much memory are we talking about?

> The value of PTHREAD_STACK_MIN is rather problematic on x86-64 (for the
> reasons I explained earlier), but it's not likely we are going to change
> the value of the constant any time soon.  It's more likely that we are
> going to work around the AVX-512 register file issue by providing
> exactly four usable stack pages with PTHREAD_STACK_MIN, and not less
> than two as we did until recently.  So you can assume that it's indeed
> possible to use PTHREAD_STACK_MIN and sysconf (_SC_PAGESIZE) to compute
> the static TLS area size.

Sorry can you elaborate on that calculation please?

Thanks,
David
-----

> Thanks,
> Florian
> 

From peter.levart at gmail.com  Thu May 30 05:50:43 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 May 2019 07:50:43 +0200
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
Message-ID: <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>

Hi,

On 5/29/19 9:25 PM, Roger Riggs wrote:
> Any other comments on:
> "* Runs the garbage collector in the Java Virtual Machine.
> * <p>
> * Calling this method suggests that the Java Virtual Machine
> * expend effort toward recycling unused objects in order to
> * make the memory they currently occupy available for reuse
> * by the Java Virtual Machine.

The following two statements...

1st:
> * When control returns from the method call, the Java Virtual Machine
> * has made a best effort to reclaim space from all discarded objects.

2nd:
> * There is no guarantee that this effort will recycle any particular
> * number of unused objects, reclaim any particular amount of space,
> * *or complete* at any particular time, if *at all*.
> " 

...makes one think that it is OK (by the spec) for System.gc() to never 
complete.

Could it rather be specified that System.gc() eventually completes?

Regards, Peter


From scolebourne at joda.org  Thu May 30 07:36:59 2019
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 30 May 2019 08:36:59 +0100
Subject: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception
 on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM
In-Reply-To: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
References: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
Message-ID: <CACzrW9Aosq8vTdfcjypieH7=a6+akY8huj2y7N=+bA4EKghv-g@mail.gmail.com>

+1

On Wed, 29 May 2019, 22:13 , <naoto.sato at oracle.com> wrote:

> Hi,
>
> Please review the fix for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8223773
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
>
> Checking the range of HourOfAmPm with the range of AmPmOfDay is
> apparently incorrect. Fixing it will change the behavior of parsing with
> SMART resolver style to throw a DateTimeParseException. This is a change
> in which an app will start to see an exception with incorrect data, but
> that is what should be in the first place.
>
> Naoto
>

From rkennke at redhat.com  Thu May 30 10:27:58 2019
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 30 May 2019 12:27:58 +0200
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
 <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>
Message-ID: <449aa33b-39e2-8f8f-90f2-ffcb04c7e6a0@redhat.com>



>> Any other comments on:
>> "* Runs the garbage collector in the Java Virtual Machine.
>> * <p>
>> * Calling this method suggests that the Java Virtual Machine
>> * expend effort toward recycling unused objects in order to
>> * make the memory they currently occupy available for reuse
>> * by the Java Virtual Machine.
> 
> The following two statements...
> 
> 1st:
>> * When control returns from the method call, the Java Virtual Machine
>> * has made a best effort to reclaim space from all discarded objects.
> 
> 2nd:
>> * There is no guarantee that this effort will recycle any particular
>> * number of unused objects, reclaim any particular amount of space,
>> * *or complete* at any particular time, if *at all*.
>> " 
> 
> ...makes one think that it is OK (by the spec) for System.gc() to never
> complete.
> 
> Could it rather be specified that System.gc() eventually completes?
> 

+1 I was thinking the same.

I think the intention is that GC may never actually complete, but
System.gc() must be guaranteed to eventually return.

Roman


From sundararajan.athijegannathan at oracle.com  Thu May 30 10:55:35 2019
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 30 May 2019 16:25:35 +0530
Subject: RFR 8224946: jrtfs URI to Path and Path to URI conversions are wrong
Message-ID: <5CEFB6A7.60008@oracle.com>

Please review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8224946
Webrev: https://cr.openjdk.java.net/~sundar/8224946/webrev.00/

Earlier attempt for the fix of the same bug resulted in test failures 
and so the fix was reverted. The current webrev has the same fix - but 
fixes 2 jlink tests that used wrong jrt: URI. With this change, internal 
mach5 test run is fine.

Related email threads of earlier fix attempt & reversal:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060434.html
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060459.html

Thanks,
-Sundar

From Alan.Bateman at oracle.com  Thu May 30 10:51:31 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 May 2019 11:51:31 +0100
Subject: RFR 8224946: jrtfs URI to Path and Path to URI conversions are
 wrong
In-Reply-To: <5CEFB6A7.60008@oracle.com>
References: <5CEFB6A7.60008@oracle.com>
Message-ID: <6a59c895-ac3d-91fa-2092-ceb2d33409df@oracle.com>

On 30/05/2019 11:55, Sundararajan Athijegannathan wrote:
> Please review.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8224946
> Webrev: https://cr.openjdk.java.net/~sundar/8224946/webrev.00/
>
> Earlier attempt for the fix of the same bug resulted in test failures 
> and so the fix was reverted. The current webrev has the same fix - but 
> fixes 2 jlink tests that used wrong jrt: URI. With this change, 
> internal mach5 test run is fine.
The update to the two jlink tests missed in the original push looks fine.

-Alan

From Andrew.Auclair at G2TCG.COM  Thu May 30 13:40:41 2019
From: Andrew.Auclair at G2TCG.COM (Andrew Auclair)
Date: Thu, 30 May 2019 13:40:41 +0000
Subject: jpackage EA Build Question Followup
Message-ID: <13c00f7502ea4e6cad0e8d2a9146141d@G2TCG.COM>

Hi,

I had sent in a question in January about the jpackage (see below link and email). Due to issues with our email filtering service I did not see the response and wandered upon it last night. So apologies in advance for such a long time between messages, I am now a subscriber and hopefully the email filtering issue is fixed properly by IT.

I'm experimenting with build 49 of jpackage in the JDK 13 EA. I'm still not sure if what I want to do is currently possible. I would like to execute "jpackage create-app-image" with all my info for a non-modular application image (input, output, name, icon, jar, main class). I would then like to move the cfg and jar up one directory so that the applauncher.dll, cfg, exe, ico and jar are all in the same folder. Then rename the cfg and exe, we have a standard exe name that I don't want to be used by windows as the app name (this all works fine as is as long as the cfg and exe names match). If I'm able to reorder the generated files from create-app-image, I can install our native 64 bit C++ apps in the same folder and share the 64 bit dll's between all the C++ and Java applications. Lots of moving parts, hopefully the layout is clear in my initial message, I've had a hell of a time explaining this to my coworkers.

One thing I wanted to clarify from the previous thread is that we do not use the installer portion of javapackager, we use a different installer, with javapackager we just use the "-native image" option. I would like to also note that we have a fairly large install which has about 50 executables that are installed, including 6 java applications, so minimizing duplication helps save space and install time.

We are also in the process of porting several dozen more of these applications to 64 bit which makes that issue a little more important to sort out.

Previous thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057775.html



Thanks again for any help, much appreciated!



interesting ...



I would think I would want to do this by first building the app image,

then moving the pieces around before building the installer.



But that doesn't work:



1.) the installer expects to find a "runtime" sub-directory of the

app-image directory.  This could be considered a bug, and I will fix it,

but it can be worked around by creating an extra empty "runtime" subdir

in the app image.



2.) the installer needs to find the app itself (for installing shortcuts

to it).  When using an app-image it determines the app name by looking

for a cfg file in the "app" sub-directory of the app-image.  Then given

the name, it looks for executable and ico of that name in the top level

app-image directory.



I suspect I could work around even that by using drop-in resources with

the new --resource-dir arg but not sure.  I will look into it and get

back to you. (this is significantly different since JDK-8215515

<https://bugs.openjdk.java.net/browse/JDK-8215515> , so even if I can

work around this in that way - you would have to wait for the next EA drop).



The bigger question is should there be some way to express the install

root differently from the app root ?



/Andy

Original Email Below
--------------------------------

We are currently using JDK 10 with javapackager and have looked at the Early Access build available for the jpackage enhancement. We have a question about an issue we are currently experiencing with javapackager, which appears to have the same behavior in jpackage.

Background:

In our install we have several 32 bit C++ applications, some 64 bit C++ applications and 64 bit JDK 10 Java applications. The 64 bit C++ and Java applications both use a set of C++ DLLs. This has forced us to place the 64 bit C++ applications in the app folder that the javapackager creates. Jpackage appears to create the same app folder.

Our folder structure is outlined below. The executable generated by javapackager appears to be hardcoded to use the app/*.cfg files. We would like the ability to place the contents of the app folder directly in our bin64 folder along with the exe and ico that are generated.

Install / bin64 / app / native64.dll
Install / bin64 / app / cpp64bitapp.exe
Install / bin64 / app / javaapp.jar
Install / bin64 / app / javaapp.cfg
Install / bin64 / javaapp.exe
Install / bin64 / runtime <-- JRE 10 runtime
Install / native.dll
Install / cpp32bitapp.exe

Question:
Is it possible for us to rename or change the app folder, or to place the contents of the app folder in the parent directory?


Andrew Auclair
Software Engineer
Tactical Communications Group
A Curtiss-Wright Company
2 Highwood Drive, Building 2, Suite 200
Tewksbury, MA  01876-1157

Direct: 978-654-4849   Fax: 978-654-4801
www.g2tcg.com<http://www.g2tcg.com/>


From Roger.Riggs at oracle.com  Thu May 30 13:50:22 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 30 May 2019 09:50:22 -0400
Subject: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception
 on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM
In-Reply-To: <606b31aa-86b5-d862-5b8e-51da87d30659@oracle.com>
References: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
 <5CEF0CD9.1020007@oracle.com>
 <606b31aa-86b5-d862-5b8e-51da87d30659@oracle.com>
Message-ID: <52fe078a-0400-4179-c556-14307b141672@oracle.com>

Hi,

The behavior is within the spec and seems more just like a bug in the 
implementation.
Also, an exception was thrown but it was for the wrong reason.

$.02, Roger


On 05/29/2019 06:55 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> Right, I will file a corresponding CSR.
>
> Naoto
>
> On 5/29/19 3:51 PM, Joseph D. Darcy wrote:
>> Hi Naoto,
>>
>> Should this bug get a CSR for the behavioral change?
>>
>> Cheers,
>>
>> -Joe
>>
>> On 5/29/2019 2:12 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix for the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8223773
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
>>>
>>> Checking the range of HourOfAmPm with the range of AmPmOfDay is 
>>> apparently incorrect. Fixing it will change the behavior of parsing 
>>> with SMART resolver style to throw a DateTimeParseException. This is 
>>> a change in which an app will start to see an exception with 
>>> incorrect data, but that is what should be in the first place.
>>>
>>> Naoto
>>


From Roger.Riggs at oracle.com  Thu May 30 13:55:22 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 30 May 2019 09:55:22 -0400
Subject: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception
 on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM
In-Reply-To: <440DA6E9-B556-4932-B2A7-BBCC77F8AF48@oracle.com>
References: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
 <440DA6E9-B556-4932-B2A7-BBCC77F8AF48@oracle.com>
Message-ID: <afaf31da-4163-b32e-6469-e9fe34a41c2d@oracle.com>

Hi Naoto,

This looks ok.
Typically, it is not necessary to check the exception message text.

Thanks, Roger

On 05/29/2019 05:21 PM, Lance Andersen wrote:
> Hi Naoto,
>
> This is OK.
>
> Could you please add an @summary as it is missing so that we are consistent with other tests.
>
> No need to spin a webrev again though
>
>
> Best
> Lance
>> On May 29, 2019, at 5:12 PM, naoto.sato at oracle.com wrote:
>>
>> Hi,
>>
>> Please review the fix for the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8223773
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
>>
>> Checking the range of HourOfAmPm with the range of AmPmOfDay is apparently incorrect. Fixing it will change the behavior of parsing with SMART resolver style to throw a DateTimeParseException. This is a change in which an app will start to see an exception with incorrect data, but that is what should be in the first place.
>>
>> Naoto
>   <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 Roger.Riggs at oracle.com  Thu May 30 14:42:03 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 30 May 2019 10:42:03 -0400
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <449aa33b-39e2-8f8f-90f2-ffcb04c7e6a0@redhat.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
 <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>
 <449aa33b-39e2-8f8f-90f2-ffcb04c7e6a0@redhat.com>
Message-ID: <f936f160-2627-4b6e-43b2-d7bed38cd04c@oracle.com>

Hi,

Though I see your point about gc() eventually returns, the spec 
typically does not
guarantee than any method eventually returns.? That's more a quality of 
service attribute.
The sentence refers to the effort to reclaim space, not the method call.

Would it clarify the case to add a qualification to the end of the sentence:
" before the method returns or ever."

As a whole:

 ???? * Runs the garbage collector in the Java Virtual Machine.
 ???? * <p>
 ???? * Calling this method suggests that the Java Virtual Machine
 ???? * expend effort toward recycling unused objects in order to
 ???? * make the memory they currently occupy available for reuse
 ???? * by the Java Virtual Machine.
 ???? * When control returns from the method call, the Java Virtual Machine
 ???? * has made a best effort to reclaim space from all unused objects.
 ???? * There is no guarantee that this effort will recycle any particular
 ???? * number of unused objects, reclaim any particular amount of space,
 ???? * or complete at any particular time, if at all <b>before the 
method returns or ever</b>.

Thanks, Roger

On 05/30/2019 06:27 AM, Roman Kennke wrote:
>
>>> Any other comments on:
>>> "* Runs the garbage collector in the Java Virtual Machine.
>>> * <p>
>>> * Calling this method suggests that the Java Virtual Machine
>>> * expend effort toward recycling unused objects in order to
>>> * make the memory they currently occupy available for reuse
>>> * by the Java Virtual Machine.
>> The following two statements...
>>
>> 1st:
>>> * When control returns from the method call, the Java Virtual Machine
>>> * has made a best effort to reclaim space from all discarded objects.
>> 2nd:
>>> * There is no guarantee that this effort will recycle any particular
>>> * number of unused objects, reclaim any particular amount of space,
>>> * *or complete* at any particular time, if *at all*.
>>> "
>> ...makes one think that it is OK (by the spec) for System.gc() to never
>> complete.
>>
>> Could it rather be specified that System.gc() eventually completes?
>>
> +1 I was thinking the same.
>
> I think the intention is that GC may never actually complete, but
> System.gc() must be guaranteed to eventually return.
>
> Roman
>


From naoto.sato at oracle.com  Thu May 30 14:56:58 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 30 May 2019 07:56:58 -0700
Subject: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception
 on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM
In-Reply-To: <afaf31da-4163-b32e-6469-e9fe34a41c2d@oracle.com>
References: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
 <440DA6E9-B556-4932-B2A7-BBCC77F8AF48@oracle.com>
 <afaf31da-4163-b32e-6469-e9fe34a41c2d@oracle.com>
Message-ID: <6164ab5f-2f4b-5cd0-991f-0642daa52ffe@oracle.com>

Thanks, Roger.

On 5/30/19 6:55 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> This looks ok.
> Typically, it is not necessary to check the exception message text.

I just wanted to make sure that the thrown DateTimeParseException is 
none other than the exception that is expected. There seems no other way 
to check that.

Naoto

> 
> Thanks, Roger
> 
> On 05/29/2019 05:21 PM, Lance Andersen wrote:
>> Hi Naoto,
>>
>> This is OK.
>>
>> Could you please add an @summary as it is missing so that we are 
>> consistent with other tests.
>>
>> No need to spin a webrev again though
>>
>>
>> Best
>> Lance
>>> On May 29, 2019, at 5:12 PM, naoto.sato at oracle.com wrote:
>>>
>>> Hi,
>>>
>>> Please review the fix for the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8223773
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
>>>
>>> Checking the range of HourOfAmPm with the range of AmPmOfDay is 
>>> apparently incorrect. Fixing it will change the behavior of parsing 
>>> with SMART resolver style to throw a DateTimeParseException. This is 
>>> a change in which an app will start to see an exception with 
>>> incorrect data, but that is what should be in the first place.
>>>
>>> Naoto
>> ? <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 Roger.Riggs at oracle.com  Thu May 30 15:20:29 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 30 May 2019 11:20:29 -0400
Subject: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception
 on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM
In-Reply-To: <52fe078a-0400-4179-c556-14307b141672@oracle.com>
References: <a401fc2f-4677-f000-2860-64c3b50378c8@oracle.com>
 <5CEF0CD9.1020007@oracle.com>
 <606b31aa-86b5-d862-5b8e-51da87d30659@oracle.com>
 <52fe078a-0400-4179-c556-14307b141672@oracle.com>
Message-ID: <454c4188-b73b-3844-f190-634ae1eee176@oracle.com>

Hi,

A release note would be a good idea to explain the change in behavior of 
SMART mode,
I added label "release-note=yes"

Regards, Roger

On 05/30/2019 09:50 AM, Roger Riggs wrote:
> Hi,
>
> The behavior is within the spec and seems more just like a bug in the 
> implementation.
> Also, an exception was thrown but it was for the wrong reason.
>
> $.02, Roger
>
>
> On 05/29/2019 06:55 PM, naoto.sato at oracle.com wrote:
>> Hi Joe,
>>
>> Right, I will file a corresponding CSR.
>>
>> Naoto
>>
>> On 5/29/19 3:51 PM, Joseph D. Darcy wrote:
>>> Hi Naoto,
>>>
>>> Should this bug get a CSR for the behavioral change?
>>>
>>> Cheers,
>>>
>>> -Joe
>>>
>>> On 5/29/2019 2:12 PM, naoto.sato at oracle.com wrote:
>>>> Hi,
>>>>
>>>> Please review the fix for the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8223773
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
>>>>
>>>> Checking the range of HourOfAmPm with the range of AmPmOfDay is 
>>>> apparently incorrect. Fixing it will change the behavior of parsing 
>>>> with SMART resolver style to throw a DateTimeParseException. This 
>>>> is a change in which an app will start to see an exception with 
>>>> incorrect data, but that is what should be in the first place.
>>>>
>>>> Naoto
>>>
>


From jianglizhou at google.com  Thu May 30 15:23:12 2019
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 30 May 2019 08:23:12 -0700
Subject: Thread stack size issue related to glibc TLS bug
In-Reply-To: <15ebac14-1e15-3b1c-79a8-175760939b50@oracle.com>
References: <CALrW1jzT24Osv0BS5UwcwRfbtvLvdZWmBFEo6ftgioUd6R8tEQ@mail.gmail.com>
 <87ftp4tcas.fsf@oldenburg2.str.redhat.com>
 <CALrW1jxB2A9iV-i4vuip2xriH4ZVfHy6-M2eYhrhoOOBYbdY6w@mail.gmail.com>
 <87y32vmvaq.fsf@oldenburg2.str.redhat.com>
 <15ebac14-1e15-3b1c-79a8-175760939b50@oracle.com>
Message-ID: <CALrW1jxO1yKLgJjO0QiuA8rinmJXOrdRLK4cdVPGe3-FNjfH6w@mail.gmail.com>

Hi David,

This is a link to __pthread_get_minstack that I find in the public
domain: https://code.woboq.org/userspace/glibc/nptl/nptl-init.c.html.
It has copyright of 2002-2019, so it's probably the latest version.

size_t
__pthread_get_minstack (const pthread_attr_t *attr)
{
 return GLRO(dl_pagesize) + __static_tls_size + PTHREAD_STACK_MIN;
}

The PTHREAD_STACK_MIN appears to be 4-pages for the glibc version
(2.24) that I'm linking with. The dl_pagesize is 1-page.

We could go with the suggestion that you brought up earlier by only
adding the min_stack_size to the current thread stack size if it is
certain percent of the stack size. With the added dl_pagesize and
PTHREAD_STACK_MIN, 25% probably is reasonable? I've made changes
(including the percent suggestion) on top the existing patch and also
added a jtreg test based on the test case attached in JDK-8130425. On
JDK 13, the test could fail with different symptoms (segfault or hang)
depending on the TLS sizes without the fix.

BTW, I noticed that Florian had already made the comment change in
glibc for __pthread_get_minstack. Thanks!

Best regards,
Jiangli

On Wed, May 29, 2019 at 10:42 PM David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Florian,
>
> On 25/05/2019 6:50 am, Florian Weimer wrote:
> > * Jiangli Zhou:
> >
> >> Hi Florian,
> >>
> >> On Fri, May 24, 2019 at 2:46 AM Florian Weimer <fweimer at redhat.com> wrote:
> >>>
> >>> * Jiangli Zhou:
> >>>
> >>>> [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
> >>>> (contributed by Jeremy Manson)
> >>>
> >>> _dl_get_tls_static_info is an internal symbol (it carries a
> >>> GLIBC_PRIVATE symbol version).  Its implementation can change at any
> >>> time.  Please do not do this.
> >>
> >> Point taken. Thanks.
> >>
> >> It appears that asan is already carrying the same type of fix:
> >>
> >> https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
> >>
> >> As the issue has not been able to be addressed in the glibc layer, all
> >> the others have to workaround it (and possibly by using the glibc
> >> private APIs, _dl_get_tls_static_info or __pthread_get_minstack). That
> >> would cause more dependencies on the private APIs.
> >
> > _dl_get_tls_static_info changed ABI on i386 in glibc 2.27 already, so
> > you really don't want to use that (in case someone backported that
> > cleanup to an earlier version, although that might be bit unlikely).
> >
> > The sanitizers are special and have a much shorter shelf life than the
> > OpenJDK binaries.
> >
> >> One alternative (besides fixing glibc) may be making
> >> _dl_get_tls_static_info public. Would that be possible?
> >
> > For __pthread_get_minstack, I can add a comment to the glibc sources
> > that if the ABI changes (or if TLS allocations are no longer considered
> > part of the stack), we should rename the function.  Then, as long as you
> > use a weak reference or dlsym (the latter is preferable for the sack of
> > RPM-based distributions which require special steps to reference
> > GLIBC_PRIVATE symbols directly), old binaries would keep working if we
> > make further changes.
> >
> > Since _dl_get_tls_static_info already changed ABI once, I really can't
> > recommend its use.  Especially if you can work with
> > __pthread_get_minstack instead.
>
> Can you explain for me what value this __pthread_get_minstack is defined
> to return? Will it accommodate any required TLS plus some other glibc
> specific overhead? How much memory are we talking about?
>
> > The value of PTHREAD_STACK_MIN is rather problematic on x86-64 (for the
> > reasons I explained earlier), but it's not likely we are going to change
> > the value of the constant any time soon.  It's more likely that we are
> > going to work around the AVX-512 register file issue by providing
> > exactly four usable stack pages with PTHREAD_STACK_MIN, and not less
> > than two as we did until recently.  So you can assume that it's indeed
> > possible to use PTHREAD_STACK_MIN and sysconf (_SC_PAGESIZE) to compute
> > the static TLS area size.
>
> Sorry can you elaborate on that calculation please?
>
> Thanks,
> David
> -----
>
> > Thanks,
> > Florian
> >

From peter.levart at gmail.com  Thu May 30 15:55:00 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 May 2019 17:55:00 +0200
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <f936f160-2627-4b6e-43b2-d7bed38cd04c@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
 <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>
 <449aa33b-39e2-8f8f-90f2-ffcb04c7e6a0@redhat.com>
 <f936f160-2627-4b6e-43b2-d7bed38cd04c@oracle.com>
Message-ID: <b9bf8346-e5f5-9c01-ad29-70659185ebbc@gmail.com>

Yes Roger, this sounds better to me.

Maybe even easier:

"There is no guarantee that this effort will recycle any particular 
number of unused objects, reclaim any particular amount of space, or 
complete before the method returns (or ever)."

So, hypothetically, the effort triggered by System.gc() may never 
complete although the method will eventually return. Is this what was 
meant to be said?

Is it necessary to have this (or ever) at the end? What's the purpose of 
it? If the method returns before the attempt completes, there's no way 
to track the attempt to its completion and doesn't matter if it 
eventually completes or not. The completion is already out of bounds for 
this method when it says: "there is not guarantee that the attempt 
completes before the method returns"...

Regards, Peter

On 5/30/19 4:42 PM, Roger Riggs wrote:
> Hi,
>
> Though I see your point about gc() eventually returns, the spec 
> typically does not
> guarantee than any method eventually returns.? That's more a quality 
> of service attribute.
> The sentence refers to the effort to reclaim space, not the method call.
>
> Would it clarify the case to add a qualification to the end of the 
> sentence:
> " before the method returns or ever."
>
> As a whole:
>
> ???? * Runs the garbage collector in the Java Virtual Machine.
> ???? * <p>
> ???? * Calling this method suggests that the Java Virtual Machine
> ???? * expend effort toward recycling unused objects in order to
> ???? * make the memory they currently occupy available for reuse
> ???? * by the Java Virtual Machine.
> ???? * When control returns from the method call, the Java Virtual Machine
> ???? * has made a best effort to reclaim space from all unused objects.
> ???? * There is no guarantee that this effort will recycle any particular
> ???? * number of unused objects, reclaim any particular amount of space,
> ???? * or complete at any particular time, if at all <b>before the 
> method returns or ever</b>.
>
> Thanks, Roger
>
> On 05/30/2019 06:27 AM, Roman Kennke wrote:
>>>> Any other comments on:
>>>> "* Runs the garbage collector in the Java Virtual Machine.
>>>> * <p>
>>>> * Calling this method suggests that the Java Virtual Machine
>>>> * expend effort toward recycling unused objects in order to
>>>> * make the memory they currently occupy available for reuse
>>>> * by the Java Virtual Machine.
>>> The following two statements...
>>>
>>> 1st:
>>>> * When control returns from the method call, the Java Virtual Machine
>>>> * has made a best effort to reclaim space from all discarded objects.
>>> 2nd:
>>>> * There is no guarantee that this effort will recycle any particular
>>>> * number of unused objects, reclaim any particular amount of space,
>>>> * *or complete* at any particular time, if *at all*.
>>>> "
>>> ...makes one think that it is OK (by the spec) for System.gc() to never
>>> complete.
>>>
>>> Could it rather be specified that System.gc() eventually completes?
>>>
>> +1 I was thinking the same.
>>
>> I think the intention is that GC may never actually complete, but
>> System.gc() must be guaranteed to eventually return.
>>
>> Roman
>>
>


From adinn at redhat.com  Thu May 30 16:08:02 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 30 May 2019 17:08:02 +0100
Subject: RFR: 8224974: Implement JEP 352
In-Reply-To: <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@redhat.com>
 <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com>
 <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com>
 <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com>
Message-ID: <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com>

HI Vladimir,

Thank you for reviewing the patch.

On 29/05/2019 20:49, Vladimir Kozlov wrote:
> I tried to test these changes and build failed on all systems except
> Linux because:
> 
> workspace/open/src/hotspot/share/prims/unsafe.cpp:446:3: error: use of
> undeclared identifier 'JNU_ThrowRuntimeException'
> ?? JNU_ThrowRuntimeException(env, "writeback is not implemented");
> ?? ^

Apologies for that. I forgot to test this via the submit repo after
cut-and-pasting the checks for OS and CPU support from the map0 native
method to the Unsafe writeback method.

I had to make some tweaks to this code anyway in order to spot an issue
Alan noticed when checking the CSR (the map code was not distinguishing
the precise cases where IOException and UnsupportedOperationException
needed to be thrown and would sometimes have replaced the latter with
the former on Windows/x86_64).

I have uploaded a new webrev which attempts to address the problem.

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

The test to see whether writeback is enabled on the current cpu_os
combination is now performed in Java from methods Unsafe.writebackMemory
and FileChannelImpl.map, using a call to Unsafe.isWritebackEnabled()

There are also 'belt and braces' checks in the corresponding native
implementation methods:

Unsafe asserts that VM_Version::supports_data_cache_line_writeback()
returns true. The result of this method indicates whether support is
available on both CPU and OS. It returns a value computed using a call
to a new OS-specific method os::supports_map_sync() and, on hardware for
which that is true (AArch64 and x86_64), a test of the relevant CPU
status bits.

FileChannelImpl still relies on conditional compilation to reject calls
on invalid OS/CPU combinations (the VM_VERSION method is not available
for it to call). In the branch for !LINUX || !(AArch64 || amd64) it
throws an InternalError as this path not be reached.

Unfortunately, this latest webrev still fails when uploaded to the
submit repo. The problem seems to be specific to Windows/x86_64 builds.
The branch that failed is JDK-8224974-03. The returned text is appended
after my signature. Would you be able to provide some details about the
errors?

> ------------------------------------------------------------
> Also Graal test should be fixed for new intrinsics (add them to
> 'toBeInvestigated' for isJDK13orHigher):
> 
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
That has been fixed in the webrev mentioned above.

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


----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---

BuildId: 2019-05-30-1509485.adinn.source
No failed tests
Tasks Summary

    UNABLE_TO_RUN: 18
    NOTHING_TO_RUN: 0
    KILLED: 0
    EXECUTED_WITH_FAILURE: 4
    FAILED: 0
    HARNESS_ERROR: 0
    NA: 0
    PASSED: 55
    Build

        1 Unable to run
            windows-x64-install-windows-x64-build-19 Dependency task
failed: mach5...1512-2804499-windows-x64-windows-x64-build-12
        4 Executed with failure
            windows-x64-windows-x64-build-12 error while building,
return value: 2
            windows-x64-debug-windows-x64-build-13 error while building,
return value: 2
            windows-x64-open-windows-x64-build-14 error while building,
return value: 2
            windows-x64-open-debug-windows-x64-build-15 error while
building, return value: 2

    Test

        17 Unable to run

tier1-product-open_test_hotspot_jtreg_tier1_common-windows-x64-22
Dependency task failed:
mach5...1512-2804499-windows-x64-windows-x64-build-12

tier1-debug-open_test_hotspot_jtreg_tier1_common-windows-x64-debug-28
Dependency task failed:
mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_compiler_1-windows-x64-debug-31 Dependency
task failed: mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-debug-34 Dependency
task failed: mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_compiler_3-windows-x64-debug-37 Dependency
task failed: mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_compiler_not_xcomp-windows-x64-debug-40
Dependency task failed:
mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_gc_1-windows-x64-debug-43
Dependency task failed:
mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_gc_2-windows-x64-debug-46
Dependency task failed:
mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-product-open_test_hotspot_jtreg_tier1_gc_gcbasher-windows-x64-25
Dependency task failed:
mach5...1512-2804499-windows-x64-windows-x64-build-12

tier1-debug-open_test_hotspot_jtreg_tier1_gc_gcbasher-windows-x64-debug-49
Dependency task failed:
mach5...804499-windows-x64-debug-windows-x64-build-13
            See all 17...

From mandy.chung at oracle.com  Thu May 30 16:11:12 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 30 May 2019 09:11:12 -0700
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <b9bf8346-e5f5-9c01-ad29-70659185ebbc@gmail.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
 <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>
 <449aa33b-39e2-8f8f-90f2-ffcb04c7e6a0@redhat.com>
 <f936f160-2627-4b6e-43b2-d7bed38cd04c@oracle.com>
 <b9bf8346-e5f5-9c01-ad29-70659185ebbc@gmail.com>
Message-ID: <bd68bf7e-727f-13ec-dc75-12502bd666b1@oracle.com>


On 5/30/19 8:55 AM, Peter Levart wrote:
> Yes Roger, this sounds better to me.
>
> Maybe even easier:
>
> "There is no guarantee that this effort will recycle any particular 
> number of unused objects, reclaim any particular amount of space, or 
> complete before the method returns (or ever)."
>

+1 and take out "(or ever)"

I agree that this is simpler and clear that there is no guarantee of GC 
completion when this method returns.

Mandy

> So, hypothetically, the effort triggered by System.gc() may never 
> complete although the method will eventually return. Is this what was 
> meant to be said?
>
> Is it necessary to have this (or ever) at the end? What's the purpose 
> of it? If the method returns before the attempt completes, there's no 
> way to track the attempt to its completion and doesn't matter if it 
> eventually completes or not. The completion is already out of bounds 
> for this method when it says: "there is not guarantee that the attempt 
> completes before the method returns"...
>
> Regards, Peter
>
> On 5/30/19 4:42 PM, Roger Riggs wrote:
>> Hi,
>>
>> Though I see your point about gc() eventually returns, the spec 
>> typically does not
>> guarantee than any method eventually returns.? That's more a quality 
>> of service attribute.
>> The sentence refers to the effort to reclaim space, not the method call.
>>
>> Would it clarify the case to add a qualification to the end of the 
>> sentence:
>> " before the method returns or ever."
>>
>> As a whole:
>>
>> ???? * Runs the garbage collector in the Java Virtual Machine.
>> ???? * <p>
>> ???? * Calling this method suggests that the Java Virtual Machine
>> ???? * expend effort toward recycling unused objects in order to
>> ???? * make the memory they currently occupy available for reuse
>> ???? * by the Java Virtual Machine.
>> ???? * When control returns from the method call, the Java Virtual 
>> Machine
>> ???? * has made a best effort to reclaim space from all unused objects.
>> ???? * There is no guarantee that this effort will recycle any 
>> particular
>> ???? * number of unused objects, reclaim any particular amount of space,
>> ???? * or complete at any particular time, if at all <b>before the 
>> method returns or ever</b>.
>>
>> Thanks, Roger
>>
>> On 05/30/2019 06:27 AM, Roman Kennke wrote:
>>>>> Any other comments on:
>>>>> "* Runs the garbage collector in the Java Virtual Machine.
>>>>> * <p>
>>>>> * Calling this method suggests that the Java Virtual Machine
>>>>> * expend effort toward recycling unused objects in order to
>>>>> * make the memory they currently occupy available for reuse
>>>>> * by the Java Virtual Machine.
>>>> The following two statements...
>>>>
>>>> 1st:
>>>>> * When control returns from the method call, the Java Virtual Machine
>>>>> * has made a best effort to reclaim space from all discarded objects.
>>>> 2nd:
>>>>> * There is no guarantee that this effort will recycle any particular
>>>>> * number of unused objects, reclaim any particular amount of space,
>>>>> * *or complete* at any particular time, if *at all*.
>>>>> "
>>>> ...makes one think that it is OK (by the spec) for System.gc() to 
>>>> never
>>>> complete.
>>>>
>>>> Could it rather be specified that System.gc() eventually completes?
>>>>
>>> +1 I was thinking the same.
>>>
>>> I think the intention is that GC may never actually complete, but
>>> System.gc() must be guaranteed to eventually return.
>>>
>>> Roman
>>>
>>
>


From lance.andersen at oracle.com  Thu May 30 16:21:01 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 30 May 2019 12:21:01 -0400
Subject: RFR 8212807:  tools/jar/multiRelease/Basic.java times out
Message-ID: <85FC45D1-E44F-4A18-8630-0CC8E6524AB9@oracle.com>

Hi all,

The following fix addresses an issue with an occasional timeout for tools/jar/multiRelease/Basic.java.

The webrev can be found at: http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html>


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 Roger.Riggs at oracle.com  Thu May 30 16:40:58 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 30 May 2019 12:40:58 -0400
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <bd68bf7e-727f-13ec-dc75-12502bd666b1@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
 <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>
 <449aa33b-39e2-8f8f-90f2-ffcb04c7e6a0@redhat.com>
 <f936f160-2627-4b6e-43b2-d7bed38cd04c@oracle.com>
 <b9bf8346-e5f5-9c01-ad29-70659185ebbc@gmail.com>
 <bd68bf7e-727f-13ec-dc75-12502bd666b1@oracle.com>
Message-ID: <ee2b1d91-e588-4e3b-7127-99611873c77a@oracle.com>

Hi Mandy,

Yes, the method returns and something may have happened.

But "or even" is a essential element, because there can be no guarantee that
any reclamation will ever happen, whether or not the method returns.
For example, EpilsonGC.

Thanks, Roger

On 05/30/2019 12:11 PM, Mandy Chung wrote:
>
> On 5/30/19 8:55 AM, Peter Levart wrote:
>> Yes Roger, this sounds better to me.
>>
>> Maybe even easier:
>>
>> "There is no guarantee that this effort will recycle any particular 
>> number of unused objects, reclaim any particular amount of space, or 
>> complete before the method returns (or ever)."
>>
>
> +1 and take out "(or ever)"
>
> I agree that this is simpler and clear that there is no guarantee of 
> GC completion when this method returns.
>
> Mandy
>
>> So, hypothetically, the effort triggered by System.gc() may never 
>> complete although the method will eventually return. Is this what was 
>> meant to be said?
>>
>> Is it necessary to have this (or ever) at the end? What's the purpose 
>> of it? If the method returns before the attempt completes, there's no 
>> way to track the attempt to its completion and doesn't matter if it 
>> eventually completes or not. The completion is already out of bounds 
>> for this method when it says: "there is not guarantee that the 
>> attempt completes before the method returns"...
>>
>> Regards, Peter
>>
>> On 5/30/19 4:42 PM, Roger Riggs wrote:
>>> Hi,
>>>
>>> Though I see your point about gc() eventually returns, the spec 
>>> typically does not
>>> guarantee than any method eventually returns.? That's more a quality 
>>> of service attribute.
>>> The sentence refers to the effort to reclaim space, not the method 
>>> call.
>>>
>>> Would it clarify the case to add a qualification to the end of the 
>>> sentence:
>>> " before the method returns or ever."
>>>
>>> As a whole:
>>>
>>> ???? * Runs the garbage collector in the Java Virtual Machine.
>>> ???? * <p>
>>> ???? * Calling this method suggests that the Java Virtual Machine
>>> ???? * expend effort toward recycling unused objects in order to
>>> ???? * make the memory they currently occupy available for reuse
>>> ???? * by the Java Virtual Machine.
>>> ???? * When control returns from the method call, the Java Virtual 
>>> Machine
>>> ???? * has made a best effort to reclaim space from all unused objects.
>>> ???? * There is no guarantee that this effort will recycle any 
>>> particular
>>> ???? * number of unused objects, reclaim any particular amount of 
>>> space,
>>> ???? * or complete at any particular time, if at all <b>before the 
>>> method returns or ever</b>.
>>>
>>> Thanks, Roger
>>>
>>> On 05/30/2019 06:27 AM, Roman Kennke wrote:
>>>>>> Any other comments on:
>>>>>> "* Runs the garbage collector in the Java Virtual Machine.
>>>>>> * <p>
>>>>>> * Calling this method suggests that the Java Virtual Machine
>>>>>> * expend effort toward recycling unused objects in order to
>>>>>> * make the memory they currently occupy available for reuse
>>>>>> * by the Java Virtual Machine.
>>>>> The following two statements...
>>>>>
>>>>> 1st:
>>>>>> * When control returns from the method call, the Java Virtual 
>>>>>> Machine
>>>>>> * has made a best effort to reclaim space from all discarded 
>>>>>> objects.
>>>>> 2nd:
>>>>>> * There is no guarantee that this effort will recycle any particular
>>>>>> * number of unused objects, reclaim any particular amount of space,
>>>>>> * *or complete* at any particular time, if *at all*.
>>>>>> "
>>>>> ...makes one think that it is OK (by the spec) for System.gc() to 
>>>>> never
>>>>> complete.
>>>>>
>>>>> Could it rather be specified that System.gc() eventually completes?
>>>>>
>>>> +1 I was thinking the same.
>>>>
>>>> I think the intention is that GC may never actually complete, but
>>>> System.gc() must be guaranteed to eventually return.
>>>>
>>>> Roman
>>>>
>>>
>>
>


From Roger.Riggs at oracle.com  Thu May 30 16:48:54 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 30 May 2019 12:48:54 -0400
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <b9bf8346-e5f5-9c01-ad29-70659185ebbc@gmail.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
 <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>
 <449aa33b-39e2-8f8f-90f2-ffcb04c7e6a0@redhat.com>
 <f936f160-2627-4b6e-43b2-d7bed38cd04c@oracle.com>
 <b9bf8346-e5f5-9c01-ad29-70659185ebbc@gmail.com>
Message-ID: <a91fe0f8-6b28-92d2-6e78-13813081e751@oracle.com>

Hi Peter,

There are several ways to monitor the progress/"completion" of gc,
including visible affects on WeakReference, etc., 
Runtime.availableMemory, etc.
Without the ("or ever"), the case can be made that eventually some kind 
of completion
should be/must be visible directly or indirectly.

Roger


On 05/30/2019 11:55 AM, Peter Levart wrote:
> Yes Roger, this sounds better to me.
>
> Maybe even easier:
>
> "There is no guarantee that this effort will recycle any particular 
> number of unused objects, reclaim any particular amount of space, or 
> complete before the method returns (or ever)."
>
> So, hypothetically, the effort triggered by System.gc() may never 
> complete although the method will eventually return. Is this what was 
> meant to be said?
yes
>
> Is it necessary to have this (or ever) at the end? What's the purpose 
> of it? If the method returns before the attempt completes, there's no 
> way to track the attempt to its completion and doesn't matter if it 
> eventually completes or not. The completion is already out of bounds 
> for this method when it says: "there is not guarantee that the attempt 
> completes before the method returns"...
>
> Regards, Peter
>
> On 5/30/19 4:42 PM, Roger Riggs wrote:
>> Hi,
>>
>> Though I see your point about gc() eventually returns, the spec 
>> typically does not
>> guarantee than any method eventually returns.? That's more a quality 
>> of service attribute.
>> The sentence refers to the effort to reclaim space, not the method call.
>>
>> Would it clarify the case to add a qualification to the end of the 
>> sentence:
>> " before the method returns or ever."
>>
>> As a whole:
>>
>> ???? * Runs the garbage collector in the Java Virtual Machine.
>> ???? * <p>
>> ???? * Calling this method suggests that the Java Virtual Machine
>> ???? * expend effort toward recycling unused objects in order to
>> ???? * make the memory they currently occupy available for reuse
>> ???? * by the Java Virtual Machine.
>> ???? * When control returns from the method call, the Java Virtual 
>> Machine
>> ???? * has made a best effort to reclaim space from all unused objects.
>> ???? * There is no guarantee that this effort will recycle any particular
>> ???? * number of unused objects, reclaim any particular amount of space,
>> ???? * or complete at any particular time, if at all <b>before the 
>> method returns or ever</b>.
>>
>> Thanks, Roger
>>
>> On 05/30/2019 06:27 AM, Roman Kennke wrote:
>>>>> Any other comments on:
>>>>> "* Runs the garbage collector in the Java Virtual Machine.
>>>>> * <p>
>>>>> * Calling this method suggests that the Java Virtual Machine
>>>>> * expend effort toward recycling unused objects in order to
>>>>> * make the memory they currently occupy available for reuse
>>>>> * by the Java Virtual Machine.
>>>> The following two statements...
>>>>
>>>> 1st:
>>>>> * When control returns from the method call, the Java Virtual Machine
>>>>> * has made a best effort to reclaim space from all discarded objects.
>>>> 2nd:
>>>>> * There is no guarantee that this effort will recycle any particular
>>>>> * number of unused objects, reclaim any particular amount of space,
>>>>> * *or complete* at any particular time, if *at all*.
>>>>> "
>>>> ...makes one think that it is OK (by the spec) for System.gc() to never
>>>> complete.
>>>>
>>>> Could it rather be specified that System.gc() eventually completes?
>>>>
>>> +1 I was thinking the same.
>>>
>>> I think the intention is that GC may never actually complete, but
>>> System.gc() must be guaranteed to eventually return.
>>>
>>> Roman
>>>
>>
>


From shade at redhat.com  Thu May 30 16:54:32 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 30 May 2019 18:54:32 +0200
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <a91fe0f8-6b28-92d2-6e78-13813081e751@oracle.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
 <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>
 <449aa33b-39e2-8f8f-90f2-ffcb04c7e6a0@redhat.com>
 <f936f160-2627-4b6e-43b2-d7bed38cd04c@oracle.com>
 <b9bf8346-e5f5-9c01-ad29-70659185ebbc@gmail.com>
 <a91fe0f8-6b28-92d2-6e78-13813081e751@oracle.com>
Message-ID: <47be64b7-f88b-8125-ac55-8fb65cfd0cbc@redhat.com>

On 5/30/19 6:48 PM, Roger Riggs wrote:
> There are several ways to monitor the progress/"completion" of gc,
> including visible affects on WeakReference, etc., Runtime.availableMemory, etc.
> Without the ("or ever"), the case can be made that eventually some kind of completion
> should be/must be visible directly or indirectly.

Yes. I had implemented that code several times before, and it sucked every time. That was before I
discovered System.gc() is actually blocking by the virtue of "When control from the method call,
...". If we are relaxing that, can we at least provide the implementation note that some
implementations choose to block, for users' convenience?

-Aleksey


From vladimir.kozlov at oracle.com  Thu May 30 16:58:49 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 30 May 2019 09:58:49 -0700
Subject: RFR: 8224974: Implement JEP 352
In-Reply-To: <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com>
References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com>
 <506d2bee-9376-52f7-731c-4d872c944847@oracle.com>
 <f77da070-529b-d1d4-4b34-7f0c02794c39@redhat.com>
 <607e2f32-1f01-e45f-42e8-a645fa374cf7@oracle.com>
 <06ef3b25-9e34-f6f3-e4c4-319adea52ae7@redhat.com>
 <2153cb8e-b4c1-d3c5-4c28-3e32d50db2ea@oracle.com>
 <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com>
Message-ID: <f42e0407-c4b1-4d69-5233-2e2b5c11a4cc@oracle.com>

On 5/30/19 9:08 AM, Andrew Dinn wrote:
> HI Vladimir,
> 
> Thank you for reviewing the patch.
> 
> On 29/05/2019 20:49, Vladimir Kozlov wrote:
>> I tried to test these changes and build failed on all systems except
>> Linux because:
>>
>> workspace/open/src/hotspot/share/prims/unsafe.cpp:446:3: error: use of
>> undeclared identifier 'JNU_ThrowRuntimeException'
>>  ?? JNU_ThrowRuntimeException(env, "writeback is not implemented");
>>  ?? ^
> 
> Apologies for that. I forgot to test this via the submit repo after
> cut-and-pasting the checks for OS and CPU support from the map0 native
> method to the Unsafe writeback method.
> 
> I had to make some tweaks to this code anyway in order to spot an issue
> Alan noticed when checking the CSR (the map code was not distinguishing
> the precise cases where IOException and UnsupportedOperationException
> needed to be thrown and would sometimes have replaced the latter with
> the former on Windows/x86_64).

Okay.

> 
> I have uploaded a new webrev which attempts to address the problem.
> 
>    http://cr.openjdk.java.net/~adinn/8224974/webrev.03

I looked only on HotSpot code.

stubGenerator_x86_64.cpp - in generate_data_cache_writeback() next are not used:

+    bool optimized = VM_Version::supports_clflushopt();
+    bool no_evict = VM_Version::supports_clwb();

vm_version_x86.hpp it should check CPUID flag in 32-bit:

+#else
+  static bool supports_clflush() { return true; }


We don't check has_match_rule() in LibraryCallKit any more.
In .ad files you need to add predicate to new insrtructions:

   predicate(VM_Version::supports_data_cache_line_flush());

Also add this check to Matcher::match_rule_supported() which you can use then in C2Compiler::is_intrinsic_supported().
DISABLE_UNSAFE_WRITEBACK_INTRINSIC should be checked much early may be together with os::supports_map_sync() when you 
set _data_cache_line_flush_size.

> 
> The test to see whether writeback is enabled on the current cpu_os
> combination is now performed in Java from methods Unsafe.writebackMemory
> and FileChannelImpl.map, using a call to Unsafe.isWritebackEnabled()
> 
> There are also 'belt and braces' checks in the corresponding native
> implementation methods:
> 
> Unsafe asserts that VM_Version::supports_data_cache_line_writeback()
> returns true. The result of this method indicates whether support is
> available on both CPU and OS. It returns a value computed using a call
> to a new OS-specific method os::supports_map_sync() and, on hardware for
> which that is true (AArch64 and x86_64), a test of the relevant CPU
> status bits.
> 
> FileChannelImpl still relies on conditional compilation to reject calls
> on invalid OS/CPU combinations (the VM_VERSION method is not available
> for it to call). In the branch for !LINUX || !(AArch64 || amd64) it
> throws an InternalError as this path not be reached.
> 
> Unfortunately, this latest webrev still fails when uploaded to the
> submit repo. The problem seems to be specific to Windows/x86_64 builds.
> The branch that failed is JDK-8224974-03. The returned text is appended
> after my signature. Would you be able to provide some details about the
> errors
  t:/workspace/open/src/java.base/windows/native/libnio/ch/FileChannelImpl.c(64): error C2220: warning treated as error 
- no 'object' file generated
  t:/workspace/open/src/java.base/windows/native/libnio/ch/FileChannelImpl.c(64): warning C4029: declared formal 
parameter list different from definition

> 
>> ------------------------------------------------------------
>> Also Graal test should be fixed for new intrinsics (add them to
>> 'toBeInvestigated' for isJDK13orHigher):
>>
>> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
> That has been fixed in the webrev mentioned above.

Good.

Thanks,
Vladimir

> 
> 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
> 
> 
> ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
> 
> BuildId: 2019-05-30-1509485.adinn.source
> No failed tests
> Tasks Summary
> 
>      UNABLE_TO_RUN: 18
>      NOTHING_TO_RUN: 0
>      KILLED: 0
>      EXECUTED_WITH_FAILURE: 4
>      FAILED: 0
>      HARNESS_ERROR: 0
>      NA: 0
>      PASSED: 55
>      Build
> 
>          1 Unable to run
>              windows-x64-install-windows-x64-build-19 Dependency task
> failed: mach5...1512-2804499-windows-x64-windows-x64-build-12
>          4 Executed with failure
>              windows-x64-windows-x64-build-12 error while building,
> return value: 2
>              windows-x64-debug-windows-x64-build-13 error while building,
> return value: 2
>              windows-x64-open-windows-x64-build-14 error while building,
> return value: 2
>              windows-x64-open-debug-windows-x64-build-15 error while
> building, return value: 2
> 
>      Test
> 
>          17 Unable to run
> 
> tier1-product-open_test_hotspot_jtreg_tier1_common-windows-x64-22
> Dependency task failed:
> mach5...1512-2804499-windows-x64-windows-x64-build-12
> 
> tier1-debug-open_test_hotspot_jtreg_tier1_common-windows-x64-debug-28
> Dependency task failed:
> mach5...804499-windows-x64-debug-windows-x64-build-13
> 
> tier1-debug-open_test_hotspot_jtreg_tier1_compiler_1-windows-x64-debug-31 Dependency
> task failed: mach5...804499-windows-x64-debug-windows-x64-build-13
> 
> tier1-debug-open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-debug-34 Dependency
> task failed: mach5...804499-windows-x64-debug-windows-x64-build-13
> 
> tier1-debug-open_test_hotspot_jtreg_tier1_compiler_3-windows-x64-debug-37 Dependency
> task failed: mach5...804499-windows-x64-debug-windows-x64-build-13
> 
> tier1-debug-open_test_hotspot_jtreg_tier1_compiler_not_xcomp-windows-x64-debug-40
> Dependency task failed:
> mach5...804499-windows-x64-debug-windows-x64-build-13
> 
> tier1-debug-open_test_hotspot_jtreg_tier1_gc_1-windows-x64-debug-43
> Dependency task failed:
> mach5...804499-windows-x64-debug-windows-x64-build-13
> 
> tier1-debug-open_test_hotspot_jtreg_tier1_gc_2-windows-x64-debug-46
> Dependency task failed:
> mach5...804499-windows-x64-debug-windows-x64-build-13
> 
> tier1-product-open_test_hotspot_jtreg_tier1_gc_gcbasher-windows-x64-25
> Dependency task failed:
> mach5...1512-2804499-windows-x64-windows-x64-build-12
> 
> tier1-debug-open_test_hotspot_jtreg_tier1_gc_gcbasher-windows-x64-debug-49
> Dependency task failed:
> mach5...804499-windows-x64-debug-windows-x64-build-13
>              See all 17...
> 

From martinrb at google.com  Thu May 30 17:30:47 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 30 May 2019 10:30:47 -0700
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <47be64b7-f88b-8125-ac55-8fb65cfd0cbc@redhat.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
 <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>
 <449aa33b-39e2-8f8f-90f2-ffcb04c7e6a0@redhat.com>
 <f936f160-2627-4b6e-43b2-d7bed38cd04c@oracle.com>
 <b9bf8346-e5f5-9c01-ad29-70659185ebbc@gmail.com>
 <a91fe0f8-6b28-92d2-6e78-13813081e751@oracle.com>
 <47be64b7-f88b-8125-ac55-8fb65cfd0cbc@redhat.com>
Message-ID: <CA+kOe0_pBgXHuCtetYd7cur1-1ridnvJZWhDEt_k_=9cWZPVSQ@mail.gmail.com>

If you are calling System.gc() for correctness (e.g. in a test), it is
probably because some sort of finalization is being triggered.  And that
happens in some Java thread (e.g. Reference Handler) that System.gc() has
no control over.  So in practice, users need to call System.gc() and then
wait for subsequent reference processing somehow.

From Roger.Riggs at oracle.com  Thu May 30 19:58:15 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 30 May 2019 15:58:15 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
 <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
Message-ID: <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com>

Hi Kim,

To ensure you see some messages in the case of timeouts, it would be
useful to call System.out.flush() after printing the message in 
logProcess().

I'm ok with the timestamps, as is, though the Duration might be useful in
some cases.

+1, Roger


On 05/30/2019 12:42 AM, David Holmes wrote:
> Adding back hotspot-dev. I don't think Kim saw this.
>
> David
>
> On 30/05/2019 4:04 am, Roger Riggs wrote:
>> Hi Kim,
>>
>> In the normal output less output is cleaner.
>> It would be more useful to have the Duration of the wait and end time 
>> of the wait.
>> (It saves the reader doing subtraction of times).
>>
>> +????????? Instant start = Instant.now();
>> +????????? boolean aborted = true;
>> +????????? try {
>> +????????????? int result = p.waitFor();
>> +????????????? aborted = false;
>> +????????????? return result;
>> +????????? } finally {
>> +????????????? Duration dur = Duration.between(start, Instant.now());
>> +????????????? if (aborted) {
>> +????????????????? logProgress("Waiting for completion FAILED after: 
>> " + dur);
>> +????????????? } else {
>> +????????????????? logProgress("Waiting for completion finished 
>> after: " + dur);
>> +????????????? }
>> +????????? }
>>
>> Or something like that.
>>
>> Roger
>>
>>
>> On 05/29/2019 01:24 PM, Kim Barrett wrote:
>>> [I?m not completely sure where this RFR should be sent, but 
>>> core-libs-dev
>>> and hotspot-dev seems likely to get reasonable coverage of those who
>>> might care.]
>>>
>>> Please review this change to the test library to add some "logging"
>>> output to tests that spawn a child process to perform the test and
>>> then analyze that child's output.? We are seeing occasional timeouts
>>> in such tests whose cause is hard to pin down.? It's not clear whether
>>> the excess time is in the child or instead some problem in the testing
>>> framework.? The new logging output provides timestamps for (1) the
>>> start of output collection from the child, (2) the start of waiting
>>> for the child to terminate, and (3) the child's termination. This
>>> should be enough to determine whether the child is taking too long,
>>> and hint at where (e.g. termination or not).
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8219149
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/
>>>
>>> Testing:
>>> Local hs-tier1 and verified the expected logging output is present.
>>> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
>>> caused by the new logging.? (It seems unlikely, but...)
>>>
>>>
>>


From brent.christian at oracle.com  Thu May 30 20:02:30 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 30 May 2019 13:02:30 -0700
Subject: RFR 8212807: tools/jar/multiRelease/Basic.java times out
In-Reply-To: <85FC45D1-E44F-4A18-8630-0CC8E6524AB9@oracle.com>
References: <85FC45D1-E44F-4A18-8630-0CC8E6524AB9@oracle.com>
Message-ID: <e9c593bc-2c97-eb22-3c42-ca7a0ef11ba5@oracle.com>

Hi, Lance

This change is to collect more information in case this happens again, yes?

Looks pretty good - just a couple comments:


test/jdk/tools/jar/multiRelease/Basic.java

  536         jar("ufm", jarfile, manifest.toString(),

Is there a reason not to convert this to call jarTool() ?

--

test/jdk/tools/jar/multiRelease/MRTestBase.java


L146-L152

indentation looks off-by-one


Thanks,
-Brent

On 5/30/19 9:21 AM, Lance Andersen wrote:
> Hi all,
> 
> The following fix addresses an issue with an occasional timeout for tools/jar/multiRelease/Basic.java.
> 
> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html>
> 
> 
> 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 kim.barrett at oracle.com  Thu May 30 20:02:56 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 30 May 2019 16:02:56 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
 <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
Message-ID: <87386B38-4633-4164-AF27-E99FDF201A4D@oracle.com>

> On May 30, 2019, at 12:42 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Adding back hotspot-dev. I don't think Kim saw this.

I did see it, though nearly missed, and not spotted until late evening.  Thanks for making sure?

> 
> David
> 
> On 30/05/2019 4:04 am, Roger Riggs wrote:
>> Hi Kim,
>> In the normal output less output is cleaner.
>> It would be more useful to have the Duration of the wait and end time of the wait.
>> (It saves the reader doing subtraction of times).
>> +          Instant start = Instant.now();
>> +          boolean aborted = true;
>> +          try {
>> +              int result = p.waitFor();
>> +              aborted = false;
>> +              return result;
>> +          } finally {
>> +              Duration dur = Duration.between(start, Instant.now());
>> +              if (aborted) {
>> +                  logProgress("Waiting for completion FAILED after: " + dur);
>> +              } else {
>> +                  logProgress("Waiting for completion finished after: " + dur);
>> +              }
>> +          }
>> Or something like that.
>> Roger
>> On 05/29/2019 01:24 PM, Kim Barrett wrote:
>>> [I?m not completely sure where this RFR should be sent, but core-libs-dev
>>> and hotspot-dev seems likely to get reasonable coverage of those who
>>> might care.]
>>> 
>>> Please review this change to the test library to add some "logging"
>>> output to tests that spawn a child process to perform the test and
>>> then analyze that child's output.  We are seeing occasional timeouts
>>> in such tests whose cause is hard to pin down.  It's not clear whether
>>> the excess time is in the child or instead some problem in the testing
>>> framework.  The new logging output provides timestamps for (1) the
>>> start of output collection from the child, (2) the start of waiting
>>> for the child to terminate, and (3) the child's termination.  This
>>> should be enough to determine whether the child is taking too long,
>>> and hint at where (e.g. termination or not).
>>> 
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8219149
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/
>>> 
>>> Testing:
>>> Local hs-tier1 and verified the expected logging output is present.
>>> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
>>> caused by the new logging.  (It seems unlikely, but...)



From lance.andersen at oracle.com  Thu May 30 20:29:28 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 30 May 2019 16:29:28 -0400
Subject: RFR 8212807: tools/jar/multiRelease/Basic.java times out
In-Reply-To: <e9c593bc-2c97-eb22-3c42-ca7a0ef11ba5@oracle.com>
References: <85FC45D1-E44F-4A18-8630-0CC8E6524AB9@oracle.com>
 <e9c593bc-2c97-eb22-3c42-ca7a0ef11ba5@oracle.com>
Message-ID: <418C0273-EF97-43AE-A910-1A588C366469@oracle.com>

Hi Brent,
> On May 30, 2019, at 4:02 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Hi, Lance

Thank you for the review.

> 
> This change is to collect more information in case this happens again, yes?

This changes reduces the use of ProcessBuilder resulting in much improved test runs similar to what I did for:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059471.html <https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059471.html>

I took out the timing output from the tests after verifying the reduction in the test runs (which I ran 100 on the failing systems via mach 5 comparing before/after times)

Using ToolProvider is much more efficient than ProcessBuilder as I found out from the previous issue.  The reduction in time was in line with the previous issue :-) 
> 
> Looks pretty good - just a couple comments:
> 
> 
> test/jdk/tools/jar/multiRelease/Basic.java
> 
> 536         jar("ufm", jarfile, manifest.toString(),
> 
> Is there a reason not to convert this to call jarTool() ?

Yes,  java.util.jar.Attributes uses java.util.Logging to emit a warning for some reason which makes it a bit more difficult to deal with in this specific test.  So I left this one test for now.  At some point I want to go back through the other tests which use MRTestBase  and convert the tests to also use ToolProvider and I can look to  revisit the issue then.

Right now I am trying to cut down on the noise of some of the random timeouts :-)
> 
> --
> 
> test/jdk/tools/jar/multiRelease/MRTestBase.java
> 
> 
> L146-L152
> 
> indentation looks off-by-one
> 

Thank you for catching this,  I updated the webrev : http://cr.openjdk.java.net/~lancea/8212807/webrev.01/ <http://cr.openjdk.java.net/~lancea/8212807/webrev.01/>

Best
Lance
> 
> Thanks,
> -Brent
> 
> On 5/30/19 9:21 AM, Lance Andersen wrote:
>> Hi all,
>> The following fix addresses an issue with an occasional timeout for tools/jar/multiRelease/Basic.java.
>> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html>
>> 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>

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




From jonathan.gibbons at oracle.com  Thu May 30 20:32:27 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 30 May 2019 13:32:27 -0700
Subject: RFR: [XS,doc] JDK-8225077: fix references to broken link in
 java.compiler module
Message-ID: <b41fd5cc-7bf4-d060-bc10-ec893a0a229b@oracle.com>

Please review a one line change to fix a 404 link in 
javax/annotation/processing/Filer.java
With this fix, DocCheck finds no errors in the java.compiler module.

JBS: https://bugs.openjdk.java.net/browse/JDK-8225077

-- Jon


Patch inline:

$ hg diff -R open
diff -r a0d4e61acb6b 
src/java.compiler/share/classes/javax/annotation/processing/Filer.java
--- 
a/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
Thu May 30 12:45:02 2019 -0700
+++ 
b/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
Thu May 30 13:27:15 2019 -0700
@@ -60,7 +60,7 @@
 ? * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path
 ? * segments.? A valid relative name must match the
 ? * &quot;path-rootless&quot; rule of <a
- * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986</a>, section
+ * href="http://www.ietf.org/rfc/rfc3986.txt">RFC&nbsp;3986</a>, section
 ? * 3.3.
 ? *
 ? * <p>The file creation methods take a variable number of arguments to


From joe.darcy at oracle.com  Thu May 30 20:34:18 2019
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 30 May 2019 13:34:18 -0700
Subject: RFR: [XS,
 doc] JDK-8225077: fix references to broken link in java.compiler
 module
In-Reply-To: <b41fd5cc-7bf4-d060-bc10-ec893a0a229b@oracle.com>
References: <b41fd5cc-7bf4-d060-bc10-ec893a0a229b@oracle.com>
Message-ID: <5CF03E4A.5090409@oracle.com>

+1

Thanks Jon,

-Joe

On 5/30/2019 1:32 PM, Jonathan Gibbons wrote:
> Please review a one line change to fix a 404 link in 
> javax/annotation/processing/Filer.java
> With this fix, DocCheck finds no errors in the java.compiler module.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8225077
>
> -- Jon
>
>
> Patch inline:
>
> $ hg diff -R open
> diff -r a0d4e61acb6b 
> src/java.compiler/share/classes/javax/annotation/processing/Filer.java
> --- 
> a/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
> Thu May 30 12:45:02 2019 -0700
> +++ 
> b/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
> Thu May 30 13:27:15 2019 -0700
> @@ -60,7 +60,7 @@
>   * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path
>   * segments.  A valid relative name must match the
>   * &quot;path-rootless&quot; rule of <a
> - * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986</a>, section
> + * href="http://www.ietf.org/rfc/rfc3986.txt">RFC&nbsp;3986</a>, section
>   * 3.3.
>   *
>   * <p>The file creation methods take a variable number of arguments to
>


From lance.andersen at oracle.com  Thu May 30 20:34:42 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 30 May 2019 16:34:42 -0400
Subject: RFR: [XS,doc] JDK-8225077: fix references to broken link in
 java.compiler module
In-Reply-To: <b41fd5cc-7bf4-d060-bc10-ec893a0a229b@oracle.com>
References: <b41fd5cc-7bf4-d060-bc10-ec893a0a229b@oracle.com>
Message-ID: <57483BAC-9491-4832-BD26-B56147E12A7A@oracle.com>

+1

> On May 30, 2019, at 4:32 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Please review a one line change to fix a 404 link in javax/annotation/processing/Filer.java
> With this fix, DocCheck finds no errors in the java.compiler module.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8225077
> 
> -- Jon
> 
> 
> Patch inline:
> 
> $ hg diff -R open
> diff -r a0d4e61acb6b src/java.compiler/share/classes/javax/annotation/processing/Filer.java
> --- a/src/java.compiler/share/classes/javax/annotation/processing/Filer.java Thu May 30 12:45:02 2019 -0700
> +++ b/src/java.compiler/share/classes/javax/annotation/processing/Filer.java Thu May 30 13:27:15 2019 -0700
> @@ -60,7 +60,7 @@
>   * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path
>   * segments.  A valid relative name must match the
>   * &quot;path-rootless&quot; rule of <a
> - * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986</a>, section
> + * href="http://www.ietf.org/rfc/rfc3986.txt">RFC&nbsp;3986</a>, section
>   * 3.3.
>   *
>   * <p>The file creation methods take a variable number of arguments to
> 

 <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 kim.barrett at oracle.com  Thu May 30 21:04:16 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 30 May 2019 17:04:16 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
 <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
 <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com>
Message-ID: <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com>

> On May 30, 2019, at 3:58 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Hi Kim,
> 
> To ensure you see some messages in the case of timeouts, it would be
> useful to call System.out.flush() after printing the message in logProcess().

Good idea; added.

full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/
incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/

> I'm ok with the timestamps, as is, though the Duration might be useful in
> some cases.

As I discussed with Roger, I want to keep the change simple for now,
as we're not yet sure where to expend effort looking deeper.  I think
comparing timestamps in just a few cases will tell us a lot (possibly
that we're looking in entirely the wrong place, in which case we might
just undo this change).



From brent.christian at oracle.com  Thu May 30 21:18:45 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 30 May 2019 14:18:45 -0700
Subject: RFR 8212807: tools/jar/multiRelease/Basic.java times out
In-Reply-To: <418C0273-EF97-43AE-A910-1A588C366469@oracle.com>
References: <85FC45D1-E44F-4A18-8630-0CC8E6524AB9@oracle.com>
 <e9c593bc-2c97-eb22-3c42-ca7a0ef11ba5@oracle.com>
 <418C0273-EF97-43AE-A910-1A588C366469@oracle.com>
Message-ID: <39d7dbe7-98a0-f69c-c7b0-35dd4d724021@oracle.com>

Thank you for elaborating.  The new version looks good.

-Brent

On 5/30/19 1:29 PM, Lance Andersen wrote:
> Hi Brent,
>> On May 30, 2019, at 4:02 PM, Brent Christian 
>> <brent.christian at oracle.com <mailto:brent.christian at oracle.com>> wrote:
>>
>> Hi, Lance
> 
> Thank you for the review.
> 
>>
>> This change is to collect more information in case this happens again, 
>> yes?
> 
> This changes reduces the use of ProcessBuilder resulting in much 
> improved test runs similar to what I did for:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059471.html
> 
> I took out the timing output from the tests after verifying the 
> reduction in the test runs (which I ran 100 on the failing systems via 
> mach 5 comparing before/after times)
> 
> Using ToolProvider is much more efficient than ProcessBuilder as I found 
> out from the previous issue. ?The reduction in time was in line with the 
> previous issue :-)
>>
>> Looks pretty good - just a couple comments:
>>
>>
>> test/jdk/tools/jar/multiRelease/Basic.java
>>
>> 536 ????????jar("ufm", jarfile, manifest.toString(),
>>
>> Is there a reason not to convert this to call jarTool() ?
> 
> Yes, ?java.util.jar.Attributes uses java.util.Logging to emit a warning 
> for some reason which makes it a bit more difficult to deal with in this 
> specific test. ?So I left this one test for now. ?At some point I want 
> to go back through the other tests which use MRTestBase ?and convert the 
> tests to also use ToolProvider and I can look to ?revisit the issue then.
> 
> Right now I am trying to cut down on the noise of some of the random 
> timeouts :-)
>>
>> --
>>
>> test/jdk/tools/jar/multiRelease/MRTestBase.java
>>
>>
>> L146-L152
>>
>> indentation looks off-by-one
>>
> 
> Thank you for catching this, ?I updated the webrev : 
> http://cr.openjdk.java.net/~lancea/8212807/webrev.01/
> 
> Best
> Lance
>>
>> Thanks,
>> -Brent
>>
>> On 5/30/19 9:21 AM, Lance Andersen wrote:
>>> Hi all,
>>> The following fix addresses an issue with an occasional timeout for 
>>> tools/jar/multiRelease/Basic.java.
>>> The webrev can be found at: 
>>> http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html 
>>> <http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html>
>>> 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> 
>>> <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 jonathan.gibbons at oracle.com  Thu May 30 23:53:24 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 30 May 2019 16:53:24 -0700
Subject: RFR: docs/accessibility: JDK-8220251: fix headings in java.management
Message-ID: <748b5074-ed79-b0e1-6eb0-c3f3c07ef4c1@oracle.com>

Please review a conceptually simple fix to adjust the rank of the 
headings in the following files in 4 management-related modules:

src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html
src/java.management/share/classes/java/lang/management/LockInfo.java
src/java.management/share/classes/java/lang/management/ManagementFactory.java
src/java.management/share/classes/java/lang/management/MemoryMXBean.java
src/java.management/share/classes/java/lang/management/MemoryPoolMXBean.java
src/java.management/share/classes/java/lang/management/MemoryUsage.java
src/java.management/share/classes/java/lang/management/MonitorInfo.java
src/java.management/share/classes/java/lang/management/ThreadInfo.java
src/java.management/share/classes/java/lang/management/ThreadMXBean.java
src/java.management/share/classes/java/lang/management/package.html
src/java.management/share/classes/javax/management/MXBean.java
src/java.management/share/classes/javax/management/NotificationBroadcaster.java
src/java.management/share/classes/javax/management/NotificationEmitter.java
src/java.management/share/classes/javax/management/remote/package.html
src/jdk.management.jfr/share/classes/jdk/management/jfr/FlightRecorderMXBean.java
src/jdk.management/share/classes/com/sun/management/GcInfo.java

In most files, the headings are simply adjusted "up" to close up "gaps" 
in the sequence of headings. In a couple of files, the headings were 
inconsistent and have been updated as seems best. To help understand the 
changes, I've attached the output of a script that shows the lines 
containing headings before and after the change.

-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8220251
Webrev: http://cr.openjdk.java.net/~jjg/8220251/webrev.00/webrev/index.html
Docs: http://cr.openjdk.java.net/~jjg/8220251/docs/api/index.html

-------------- next part --------------
>>> open/src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html
BEFORE:
    <h3>Creating an RMI connector server</h3>
    <h4>Choosing the RMI transport</h4>
    <h4><a id="servergen">Connector addresses generated by the
	server</a></h4>
    <h4><a id="directory">Connector addresses based on directory
	entries</a></h4>
    <h4>Connector server attributes</h4>
    <h3>Creating an RMI connector client</h3>
    <h3>Dynamic code downloading</h3>

AFTER:
    <h2>Creating an RMI connector server</h2>
    <h3>Choosing the RMI transport</h3>
    <h3><a id="servergen">Connector addresses generated by the
	server</a></h3>
    <h3><a id="directory">Connector addresses based on directory
	entries</a></h3>
    <h3>Connector server attributes</h3>
    <h2>Creating an RMI connector client</h2>
    <h2>Dynamic code downloading</h2>


>>> open/src/java.management/share/classes/java/lang/management/LockInfo.java
BEFORE:
 * <h3><a id="MappedType">MXBean Mapping</a></h3>

AFTER:
 * <h2><a id="MappedType">MXBean Mapping</a></h2>


>>> open/src/java.management/share/classes/java/lang/management/ManagementFactory.java
BEFORE:
 * <h3><a id="MXBean">Platform MXBeans</a></h3>
 * <h4>1. Direct access to an MXBean interface</h4>
 * <h4>2. Indirect access to an MXBean interface via MBeanServer</h4>

AFTER:
 * <h2><a id="MXBean">Platform MXBeans</a></h2>
 * <h3>1. Direct access to an MXBean interface</h3>
 * <h3>2. Indirect access to an MXBean interface via MBeanServer</h3>


>>> open/src/java.management/share/classes/java/lang/management/MemoryMXBean.java
BEFORE:
 * <h3> Memory </h3>
 * <h3> 1. Heap </h3>
 * <h3> 2. Non-Heap Memory</h3>
 * <h3>Memory Pools and Memory Managers</h3>
 * <h3>Memory Usage Monitoring</h3>
 * <h3>Notifications</h3>
 * <h3>NotificationEmitter</h3>

AFTER:
 * <h2> Memory </h2>
 * <h3> 1. Heap </h3>
 * <h3> 2. Non-Heap Memory</h3>
 * <h2>Memory Pools and Memory Managers</h2>
 * <h2>Memory Usage Monitoring</h2>
 * <h2>Notifications</h2>
 * <h2>NotificationEmitter</h2>


>>> open/src/java.management/share/classes/java/lang/management/MemoryPoolMXBean.java
BEFORE:
 * <h3>Memory Type</h3>
 * <h3>Memory Usage Monitoring</h3>
 * <h3><a id="Usage">1. Memory Usage</a></h3>
 * <h3><a id="PeakUsage">2. Peak Memory Usage</a></h3>
 * <h3><a id="UsageThreshold">3. Usage Threshold</a></h3>
 * <h3><a id="CollectionThreshold">4. Collection Usage Threshold</a></h3>

AFTER:
 * <h2>Memory Type</h2>
 * <h2>Memory Usage Monitoring</h2>
 * <h3><a id="Usage">1. Memory Usage</a></h3>
 * <h3><a id="PeakUsage">2. Peak Memory Usage</a></h3>
 * <h3><a id="UsageThreshold">3. Usage Threshold</a></h3>
 * <h3><a id="CollectionThreshold">4. Collection Usage Threshold</a></h3>


>>> open/src/java.management/share/classes/java/lang/management/MemoryUsage.java
BEFORE:
 * <h3>MXBean Mapping</h3>

AFTER:
 * <h2>MXBean Mapping</h2>


>>> open/src/java.management/share/classes/java/lang/management/MonitorInfo.java
BEFORE:
 * <h3>MXBean Mapping</h3>

AFTER:
 * <h2>MXBean Mapping</h2>


>>> open/src/java.management/share/classes/java/lang/management/ThreadInfo.java
BEFORE:
 * <h3>General thread information</h3>
 * <h3>Execution information</h3>
 * <h4><a id="SyncStats">Synchronization Statistics</a></h4>
 * <h4>MXBean Mapping</h4>

AFTER:
 * <h2>General thread information</h2>
 * <h2>Execution information</h2>
 * <h3><a id="SyncStats">Synchronization Statistics</a></h3>
 * <h3>MXBean Mapping</h3>


>>> open/src/java.management/share/classes/java/lang/management/ThreadMXBean.java
BEFORE:
 * <h3>Thread ID</h3>
 * <h3>Thread CPU time</h3>
 * <h3>Thread Contention Monitoring</h3>
 * <h3>Synchronization Information and Deadlock Detection</h3>

AFTER:
 * <h2>Thread ID</h2>
 * <h2>Thread CPU time</h2>
 * <h2>Thread Contention Monitoring</h2>
 * <h2>Synchronization Information and Deadlock Detection</h2>


>>> open/src/java.management/share/classes/java/lang/management/package.html
BEFORE:
<h3><a id="MXBean">Platform MXBean</a></h3>
<h3>ManagementFactory</h3>
<h3>Interoperability</h3>
<h3><a id="examples">Ways to Access MXBeans</a></h3>
<h3><a id="extension">Platform Extension</a></h3>

AFTER:
<h2><a id="MXBean">Platform MXBean</a></h2>
<h2>ManagementFactory</h2>
<h2>Interoperability</h2>
<h2><a id="examples">Ways to Access MXBeans</a></h2>
<h2><a id="extension">Platform Extension</a></h2>


>>> open/src/java.management/share/classes/javax/management/MXBean.java
BEFORE:
    <h3 id="MXBean-spec">MXBean specification</h3>
        <h4>Standard MBean</h4>
        <h4>MXBean</h4>
        <h4>Standard MBean</h4>
        <h4>MXBean</h4>
        <h4>Standard MBean</h4>
        <h4>MXBean</h4>
        <h4>Standard MBean</h4>
        <h4>MXBean</h4>
        <h4>Standard MBean</h4>
        <h4>MXBean</h4>
        <h4>Standard MBean</h4>
        <h4>MXBean</h4>
    <h2 id="mxbean-def">Definition of an MXBean</h2>
    <h2 id="naming-conv">Naming conventions</h2>
    <h2 id="mapping-rules">Type mapping rules</h2>
    <h3>Mappings for primitive types</h3>
    <h3>Mappings for collections ({@code List<}<em>E</em>{@code >} etc)</h3>
    <h3>Mappings for maps ({@code Map<}<em>K</em>,<em>V</em>{@code >} etc)</h3>
    <h3 id="mxbean-map">Mappings for MXBean interfaces</h3>
    <h3 id="composite-map">Mappings for other types</h3>
    <h4>Reconstructing an instance of Java type <em>J</em> from
      a {@code CompositeData}</h4>
    <h3>Recursive types</h3>
    <h3>MBeanInfo contents for an MXBean</h3>
    <h3 id="type-names">Type Names</h3>
    <h3>Exceptions</h3>

AFTER:
    <h2 id="MXBean-spec">MXBean specification</h2>
        <h3>Standard MBean</h3>
        <h3>MXBean</h3>
        <h3>Standard MBean</h3>
        <h3>MXBean</h3>
        <h3>Standard MBean</h3>
        <h3>MXBean</h3>
        <h3>Standard MBean</h3>
        <h3>MXBean</h3>
        <h3>Standard MBean</h3>
        <h3>MXBean</h3>
        <h3>Standard MBean</h3>
        <h3>MXBean</h3>
    <h2 id="mxbean-def">Definition of an MXBean</h2>
    <h2 id="naming-conv">Naming conventions</h2>
    <h2 id="mapping-rules">Type mapping rules</h2>
    <h3>Mappings for primitive types</h3>
    <h3>Mappings for collections ({@code List<}<em>E</em>{@code >} etc)</h3>
    <h3>Mappings for maps ({@code Map<}<em>K</em>,<em>V</em>{@code >} etc)</h3>
    <h3 id="mxbean-map">Mappings for MXBean interfaces</h3>
    <h3 id="composite-map">Mappings for other types</h3>
    <h4>Reconstructing an instance of Java type <em>J</em> from
      a {@code CompositeData}</h4>
    <h3>Recursive types</h3>
    <h3>MBeanInfo contents for an MXBean</h3>
    <h3 id="type-names">Type Names</h3>
    <h3>Exceptions</h3>


>>> open/src/java.management/share/classes/javax/management/NotificationBroadcaster.java
BEFORE:
 * <h3>Notification dispatch</h3>

AFTER:
 * <h2>Notification dispatch</h2>


>>> open/src/java.management/share/classes/javax/management/NotificationEmitter.java
BEFORE:
 * <h3>Notification dispatch</h3>

AFTER:
 * <h2>Notification dispatch</h2>


>>> open/src/java.management/share/classes/javax/management/remote/package.html
BEFORE:
      <h3>Connector addresses</h3>
      <h3>Creating a connector server</h3>
      <h3>Creating a connector client</h3>
      <h3>Additional client or server parameters</h3>
      <h3>Connection identifiers</h3>

AFTER:
      <h2>Connector addresses</h2>
      <h2>Creating a connector server</h2>
      <h2>Creating a connector client</h2>
      <h2>Additional client or server parameters</h2>
      <h2>Connection identifiers</h2>


>>> open/src/jdk.management.jfr/share/classes/jdk/management/jfr/FlightRecorderMXBean.java
BEFORE:
 * <h3>Recording options</h3>

AFTER:
 * <h2>Recording options</h2>


>>> open/src/jdk.management/share/classes/com/sun/management/GcInfo.java
BEFORE:
 * <h3>MXBean Mapping</h3>

AFTER:
 * <h2>MXBean Mapping</h2>



From lance.andersen at oracle.com  Fri May 31 00:14:30 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 30 May 2019 20:14:30 -0400
Subject: RFR: docs/accessibility: JDK-8220251: fix headings in
 java.management
In-Reply-To: <748b5074-ed79-b0e1-6eb0-c3f3c07ef4c1@oracle.com>
References: <748b5074-ed79-b0e1-6eb0-c3f3c07ef4c1@oracle.com>
Message-ID: <3693FD02-8AEE-4B3E-B56C-035211DE4B2E@oracle.com>

looks ok Jon

> On May 30, 2019, at 7:53 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Please review a conceptually simple fix to adjust the rank of the headings in the following files in 4 management-related modules:
> 
> src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html
> src/java.management/share/classes/java/lang/management/LockInfo.java
> src/java.management/share/classes/java/lang/management/ManagementFactory.java
> src/java.management/share/classes/java/lang/management/MemoryMXBean.java
> src/java.management/share/classes/java/lang/management/MemoryPoolMXBean.java
> src/java.management/share/classes/java/lang/management/MemoryUsage.java
> src/java.management/share/classes/java/lang/management/MonitorInfo.java
> src/java.management/share/classes/java/lang/management/ThreadInfo.java
> src/java.management/share/classes/java/lang/management/ThreadMXBean.java
> src/java.management/share/classes/java/lang/management/package.html
> src/java.management/share/classes/javax/management/MXBean.java
> src/java.management/share/classes/javax/management/NotificationBroadcaster.java
> src/java.management/share/classes/javax/management/NotificationEmitter.java
> src/java.management/share/classes/javax/management/remote/package.html
> src/jdk.management.jfr/share/classes/jdk/management/jfr/FlightRecorderMXBean.java
> src/jdk.management/share/classes/com/sun/management/GcInfo.java
> 
> In most files, the headings are simply adjusted "up" to close up "gaps" in the sequence of headings. In a couple of files, the headings were inconsistent and have been updated as seems best. To help understand the changes, I've attached the output of a script that shows the lines containing headings before and after the change.
> 
> -- Jon
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8220251
> Webrev: http://cr.openjdk.java.net/~jjg/8220251/webrev.00/webrev/index.html
> Docs: http://cr.openjdk.java.net/~jjg/8220251/docs/api/index.html
> 
> <diff.log.txt>

 <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 May 31 01:10:25 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 30 May 2019 18:10:25 -0700
Subject: RFR (s): 8217412 deprecate rmic for removal
Message-ID: <70189b16-b9d7-1690-597e-0deed6a62b21@oracle.com>

Hi all,

Please review this patch and CSR request for upgrading the deprecation status of 
the rmic to from ordinary to terminal (i.e., conceptually set forRemoval=true, 
though there are no actual annotations involved here).

There are no code changes, just documentation changes and changes to the warning 
message that rmic emits when run.

Webrev:

     http://cr.openjdk.java.net/~smarks/reviews/8217412/webrev.0/

     (Sorry, the long lines in these files make most of the webrev output
     unreadable. It might be easiest to look directly at the patch.)

JIRA bug:

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

Also please review this CSR request:

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

If you review the CSR, please edit its JIRA issue and add yourself to the 
"Reviewed By" field.

Thanks,

s'marks

From jonathan.gibbons at oracle.com  Fri May 31 01:07:15 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 30 May 2019 18:07:15 -0700
Subject: RFR [XS/docs] JDK-8225094: Fix minor HTML issues in jdk.zipfs
Message-ID: <cb4cdf38-a9e0-d915-c36e-5c5cdd4a9725@oracle.com>

Please review a simple docs fix for jdk.zipfs module-info.java.

The ranks of the headings are updated to close up the gaps, and a couple 
of superfluous <p> are removed.

Webrev link below, but the patch is small enough to read inline if you want.

-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8225094
Webrev: http://cr.openjdk.java.net/~jjg/8225094/webrev.00/webrev/index.html


--- old/src/jdk.zipfs/share/classes/module-info.java	2019-05-30 17:57:05.203832090 -0700
+++ new/src/jdk.zipfs/share/classes/module-info.java	2019-05-30 17:57:04.991832098 -0700
@@ -26,9 +26,8 @@
  /**
   * Provides the implementation of the Zip file system provider.
   * The Zip file system provider treats the contents of a Zip or JAR file as a file system.
- * <p>
   *
- * <h3>Accessing a Zip File System</h3>
+ * <h2>Accessing a Zip File System</h2>
   *
   * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem}
   * static factory methods can be used to:
@@ -41,11 +40,10 @@
   *
   * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP file system is {@code jar}.
   *
- * <h3>Zip File System Properties</h3>
+ * <h2>Zip File System Properties</h2>
   *
   * The following properties may be specified when creating a Zip
   * file system:
- * <p>
   * <table class="striped">
   * <caption style="display:none">
   *     Configurable properties that may be specified when creating
@@ -82,7 +80,7 @@
   * </tbody>
   * </table>
   *
- * <h3>Examples:</h3>
+ * <h2>Examples:</h2>
   *
   * Construct a new Zip file system that is identified by a URI.  If the Zip file does not exist,
   * it will be created:


From mandy.chung at oracle.com  Fri May 31 01:37:16 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 30 May 2019 18:37:16 -0700
Subject: RFR [XS/docs] JDK-8225094: Fix minor HTML issues in jdk.zipfs
In-Reply-To: <cb4cdf38-a9e0-d915-c36e-5c5cdd4a9725@oracle.com>
References: <cb4cdf38-a9e0-d915-c36e-5c5cdd4a9725@oracle.com>
Message-ID: <4d3d9715-951e-311d-fab5-ba7a19c6aa4f@oracle.com>

+1

Mandy

On 5/30/19 6:07 PM, Jonathan Gibbons wrote:
> Please review a simple docs fix for jdk.zipfs module-info.java.
>
> The ranks of the headings are updated to close up the gaps, and a 
> couple of superfluous <p> are removed.
>
> Webrev link below, but the patch is small enough to read inline if you 
> want.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8225094
> Webrev: 
> http://cr.openjdk.java.net/~jjg/8225094/webrev.00/webrev/index.html
>
>
> --- old/src/jdk.zipfs/share/classes/module-info.java??? 2019-05-30 
> 17:57:05.203832090 -0700
> +++ new/src/jdk.zipfs/share/classes/module-info.java??? 2019-05-30 
> 17:57:04.991832098 -0700
> @@ -26,9 +26,8 @@
> ?/**
> ? * Provides the implementation of the Zip file system provider.
> ? * The Zip file system provider treats the contents of a Zip or JAR 
> file as a file system.
> - * <p>
> ? *
> - * <h3>Accessing a Zip File System</h3>
> + * <h2>Accessing a Zip File System</h2>
> ? *
> ? * The {@linkplain java.nio.file.FileSystems FileSystems} {@code 
> newFileSystem}
> ? * static factory methods can be used to:
> @@ -41,11 +40,10 @@
> ? *
> ? * The URI {@link java.net.URI#getScheme scheme} that identifies the 
> ZIP file system is {@code jar}.
> ? *
> - * <h3>Zip File System Properties</h3>
> + * <h2>Zip File System Properties</h2>
> ? *
> ? * The following properties may be specified when creating a Zip
> ? * file system:
> - * <p>
> ? * <table class="striped">
> ? * <caption style="display:none">
> ? *???? Configurable properties that may be specified when creating
> @@ -82,7 +80,7 @@
> ? * </tbody>
> ? * </table>
> ? *
> - * <h3>Examples:</h3>
> + * <h2>Examples:</h2>
> ? *
> ? * Construct a new Zip file system that is identified by a URI. If 
> the Zip file does not exist,
> ? * it will be created:
>


From sundararajan.athijegannathan at oracle.com  Fri May 31 02:06:51 2019
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 31 May 2019 07:36:51 +0530
Subject: RFR (s): 8217412 deprecate rmic for removal
In-Reply-To: <70189b16-b9d7-1690-597e-0deed6a62b21@oracle.com>
References: <70189b16-b9d7-1690-597e-0deed6a62b21@oracle.com>
Message-ID: <5CF08C3B.3090307@oracle.com>

Looks good.

-Sundar

On 31/05/19, 6:40 AM, Stuart Marks wrote:
> Hi all,
>
> Please review this patch and CSR request for upgrading the deprecation 
> status of the rmic to from ordinary to terminal (i.e., conceptually 
> set forRemoval=true, though there are no actual annotations involved 
> here).
>
> There are no code changes, just documentation changes and changes to 
> the warning message that rmic emits when run.
>
> Webrev:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8217412/webrev.0/
>
>     (Sorry, the long lines in these files make most of the webrev output
>     unreadable. It might be easiest to look directly at the patch.)
>
> JIRA bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8217412
>
> Also please review this CSR request:
>
>     https://bugs.openjdk.java.net/browse/JDK-8225025
>
> If you review the CSR, please edit its JIRA issue and add yourself to 
> the "Reviewed By" field.
>
> Thanks,
>
> s'marks

From david.holmes at oracle.com  Fri May 31 06:19:06 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 31 May 2019 16:19:06 +1000
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
 <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
 <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com>
 <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com>
Message-ID: <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com>

Hi Kim,

This seems reasonable to me.

Thanks,
David

On 31/05/2019 7:04 am, Kim Barrett wrote:
>> On May 30, 2019, at 3:58 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> To ensure you see some messages in the case of timeouts, it would be
>> useful to call System.out.flush() after printing the message in logProcess().
> 
> Good idea; added.
> 
> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/
> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/
> 
>> I'm ok with the timestamps, as is, though the Duration might be useful in
>> some cases.
> 
> As I discussed with Roger, I want to keep the change simple for now,
> as we're not yet sure where to expend effort looking deeper.  I think
> comparing timestamps in just a few cases will tell us a lot (possibly
> that we're looking in entirely the wrong place, in which case we might
> just undo this change).
> 
> 

From martin.doerr at sap.com  Fri May 31 09:51:10 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 31 May 2019 09:51:10 +0000
Subject: [11u] RFR (Backport): 8223553: Fix code constructs that do not
 compile with the Eclipse Java Compiler
In-Reply-To: <AM6PR02MB5192152E7B11FE72DF083BEC8A020@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192152E7B11FE72DF083BEC8A020@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4788A93CC4FB0342242804E09A190@AM6PR02MB4788.eurprd02.prod.outlook.com>

Hi Christoph,

backport looks good.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Freitag, 24. Mai 2019 09:52
> To: jdk-updates-dev at openjdk.java.net
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: [11u] RFR (Backport): 8223553: Fix code constructs that
> do not compile with the Eclipse Java Compiler
> 
> Hi,
> 
> I'd like to bring this fix down to jdk11 updates. Unfortunately, the webrev did
> not apply cleanly in the imports section of
> src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java, so
> I had to resolve this part manually. I also updated the copyright year. Please
> check.
> 
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.11u/
> 
> Thanks
> Christoph


From adinn at redhat.com  Fri May 31 10:35:54 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 31 May 2019 11:35:54 +0100
Subject: RFR: 8224975: CSR: Implement JEP 352
Message-ID: <dbfc976e-c1e3-83b3-cf4c-072be243b6a9@redhat.com>

Could I please have reviews for the following CSR which details the
changes needed for the JEP 352 implementation task:

  CSR JIRA: https://bugs.openjdk.java.net/browse/JDK-8224975

I'm still hoping to target this for JDK13. The OpenJDK Project Lead
explained that this CSR needs to be reviewed with at least provisional
agreement before that can happen. Also, the JEP still needs endorsing by
at least one relevant Group or Area Lead (I think that probably means
Alan, Brian or Vladimir).

regards,


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

From lance.andersen at oracle.com  Fri May 31 10:53:15 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 31 May 2019 06:53:15 -0400
Subject: RFR [XS/docs] JDK-8225094: Fix minor HTML issues in jdk.zipfs
In-Reply-To: <cb4cdf38-a9e0-d915-c36e-5c5cdd4a9725@oracle.com>
References: <cb4cdf38-a9e0-d915-c36e-5c5cdd4a9725@oracle.com>
Message-ID: <36605C78-1864-4E42-BE24-EAF9315EEAFE@oracle.com>

looks OK Jon
> On May 30, 2019, at 9:07 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Please review a simple docs fix for jdk.zipfs module-info.java.
> 
> The ranks of the headings are updated to close up the gaps, and a couple of superfluous <p> are removed.
> 
> Webrev link below, but the patch is small enough to read inline if you want.
> 
> -- Jon
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8225094
> Webrev: http://cr.openjdk.java.net/~jjg/8225094/webrev.00/webrev/index.html
> 
> 
> --- old/src/jdk.zipfs/share/classes/module-info.java	2019-05-30 17:57:05.203832090 -0700
> +++ new/src/jdk.zipfs/share/classes/module-info.java	2019-05-30 17:57:04.991832098 -0700
> @@ -26,9 +26,8 @@
> /**
>  * Provides the implementation of the Zip file system provider.
>  * The Zip file system provider treats the contents of a Zip or JAR file as a file system.
> - * <p>
>  *
> - * <h3>Accessing a Zip File System</h3>
> + * <h2>Accessing a Zip File System</h2>
>  *
>  * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem}
>  * static factory methods can be used to:
> @@ -41,11 +40,10 @@
>  *
>  * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP file system is {@code jar}.
>  *
> - * <h3>Zip File System Properties</h3>
> + * <h2>Zip File System Properties</h2>
>  *
>  * The following properties may be specified when creating a Zip
>  * file system:
> - * <p>
>  * <table class="striped">
>  * <caption style="display:none">
>  *     Configurable properties that may be specified when creating
> @@ -82,7 +80,7 @@
>  * </tbody>
>  * </table>
>  *
> - * <h3>Examples:</h3>
> + * <h2>Examples:</h2>
>  *
>  * Construct a new Zip file system that is identified by a URI.  If the Zip file does not exist,
>  * it will be created:
> 

 <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 roger.riggs at oracle.com  Fri May 31 12:02:50 2019
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 31 May 2019 08:02:50 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
 <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
 <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com>
 <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com>
 <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com>
Message-ID: <fde51a92-22a6-5cee-aea3-d193b2548277@oracle.com>

+1

On 5/31/19 2:19 AM, David Holmes wrote:
> Hi Kim,
>
> This seems reasonable to me.
>
> Thanks,
> David
>
> On 31/05/2019 7:04 am, Kim Barrett wrote:
>>> On May 30, 2019, at 3:58 PM, Roger Riggs <Roger.Riggs at oracle.com> 
>>> wrote:
>>>
>>> Hi Kim,
>>>
>>> To ensure you see some messages in the case of timeouts, it would be
>>> useful to call System.out.flush() after printing the message in 
>>> logProcess().
>>
>> Good idea; added.
>>
>> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/
>> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/
>>
>>> I'm ok with the timestamps, as is, though the Duration might be 
>>> useful in
>>> some cases.
>>
>> As I discussed with Roger, I want to keep the change simple for now,
>> as we're not yet sure where to expend effort looking deeper.? I think
>> comparing timestamps in just a few cases will tell us a lot (possibly
>> that we're looking in entirely the wrong place, in which case we might
>> just undo this change).
>>
>>


From daniel.daugherty at oracle.com  Fri May 31 13:33:09 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 31 May 2019 09:33:09 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <fde51a92-22a6-5cee-aea3-d193b2548277@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
 <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
 <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com>
 <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com>
 <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com>
 <fde51a92-22a6-5cee-aea3-d193b2548277@oracle.com>
Message-ID: <f354b7b3-479e-d097-42dd-1e40d1dcc187@oracle.com>

Thumbs up.

Dan


On 5/31/19 8:02 AM, Roger Riggs wrote:
> +1
>
> On 5/31/19 2:19 AM, David Holmes wrote:
>> Hi Kim,
>>
>> This seems reasonable to me.
>>
>> Thanks,
>> David
>>
>> On 31/05/2019 7:04 am, Kim Barrett wrote:
>>>> On May 30, 2019, at 3:58 PM, Roger Riggs <Roger.Riggs at oracle.com> 
>>>> wrote:
>>>>
>>>> Hi Kim,
>>>>
>>>> To ensure you see some messages in the case of timeouts, it would be
>>>> useful to call System.out.flush() after printing the message in 
>>>> logProcess().
>>>
>>> Good idea; added.
>>>
>>> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/
>>> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/
>>>
>>>> I'm ok with the timestamps, as is, though the Duration might be 
>>>> useful in
>>>> some cases.
>>>
>>> As I discussed with Roger, I want to keep the change simple for now,
>>> as we're not yet sure where to expend effort looking deeper. I think
>>> comparing timestamps in just a few cases will tell us a lot (possibly
>>> that we're looking in entirely the wrong place, in which case we might
>>> just undo this change).
>>>
>>>
>


From Roger.Riggs at oracle.com  Fri May 31 15:14:01 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 31 May 2019 11:14:01 -0400
Subject: RFR (s): 8217412 deprecate rmic for removal
In-Reply-To: <70189b16-b9d7-1690-597e-0deed6a62b21@oracle.com>
References: <70189b16-b9d7-1690-597e-0deed6a62b21@oracle.com>
Message-ID: <83ca7045-0e78-86c3-2be9-66b268e31af9@oracle.com>

+1

On 05/30/2019 09:10 PM, Stuart Marks wrote:
> Hi all,
>
> Please review this patch and CSR request for upgrading the deprecation 
> status of the rmic to from ordinary to terminal (i.e., conceptually 
> set forRemoval=true, though there are no actual annotations involved 
> here).
>
> There are no code changes, just documentation changes and changes to 
> the warning message that rmic emits when run.
>
> Webrev:
>
> ??? http://cr.openjdk.java.net/~smarks/reviews/8217412/webrev.0/
>
> ??? (Sorry, the long lines in these files make most of the webrev output
> ??? unreadable. It might be easiest to look directly at the patch.)
>
> JIRA bug:
>
> ??? https://bugs.openjdk.java.net/browse/JDK-8217412
>
> Also please review this CSR request:
>
> ??? https://bugs.openjdk.java.net/browse/JDK-8225025
>
> If you review the CSR, please edit its JIRA issue and add yourself to 
> the "Reviewed By" field.
>
> Thanks,
>
> s'marks


From christoph.langer at sap.com  Fri May 31 15:15:56 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 31 May 2019 15:15:56 +0000
Subject: RFR [XS/docs] JDK-8225094: Fix minor HTML issues in jdk.zipfs
In-Reply-To: <cb4cdf38-a9e0-d915-c36e-5c5cdd4a9725@oracle.com>
References: <cb4cdf38-a9e0-d915-c36e-5c5cdd4a9725@oracle.com>
Message-ID: <DB7PR02MB5193E13B90CC0256DB1260728A190@DB7PR02MB5193.eurprd02.prod.outlook.com>

+1

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Jonathan Gibbons
> Sent: Freitag, 31. Mai 2019 03:07
> To: core-libs-dev at openjdk.java.net
> Subject: RFR [XS/docs] JDK-8225094: Fix minor HTML issues in jdk.zipfs
> 
> Please review a simple docs fix for jdk.zipfs module-info.java.
> 
> The ranks of the headings are updated to close up the gaps, and a couple
> of superfluous <p> are removed.
> 
> Webrev link below, but the patch is small enough to read inline if you want.
> 
> -- Jon
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8225094
> Webrev:
> http://cr.openjdk.java.net/~jjg/8225094/webrev.00/webrev/index.html
> 
> 
> --- old/src/jdk.zipfs/share/classes/module-info.java	2019-05-30
> 17:57:05.203832090 -0700
> +++ new/src/jdk.zipfs/share/classes/module-info.java	2019-05-30
> 17:57:04.991832098 -0700
> @@ -26,9 +26,8 @@
>   /**
>    * Provides the implementation of the Zip file system provider.
>    * The Zip file system provider treats the contents of a Zip or JAR file as a file
> system.
> - * <p>
>    *
> - * <h3>Accessing a Zip File System</h3>
> + * <h2>Accessing a Zip File System</h2>
>    *
>    * The {@linkplain java.nio.file.FileSystems FileSystems} {@code
> newFileSystem}
>    * static factory methods can be used to:
> @@ -41,11 +40,10 @@
>    *
>    * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP
> file system is {@code jar}.
>    *
> - * <h3>Zip File System Properties</h3>
> + * <h2>Zip File System Properties</h2>
>    *
>    * The following properties may be specified when creating a Zip
>    * file system:
> - * <p>
>    * <table class="striped">
>    * <caption style="display:none">
>    *     Configurable properties that may be specified when creating
> @@ -82,7 +80,7 @@
>    * </tbody>
>    * </table>
>    *
> - * <h3>Examples:</h3>
> + * <h2>Examples:</h2>
>    *
>    * Construct a new Zip file system that is identified by a URI.  If the Zip file
> does not exist,
>    * it will be created:


From brian.burkhalter at oracle.com  Fri May 31 15:33:24 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 31 May 2019 08:33:24 -0700
Subject: 8225117: java/math/BigInteger/SymmetricRangeTests.java fails with
 ParseException
Message-ID: <DD6D7CB7-6BF6-4087-AD37-EBFF09CE9DAB@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8225117 <https://bugs.openjdk.java.net/browse/JDK-8225117>

For SymmetricRangeTests the @ignore action tag needs to be after @library but before @run.

For StringConstructorOverflow the test is OK as is, but move the @ignore to just before @run for consistency.

Thanks,

Brian

--- a/test/jdk/java/math/BigInteger/StringConstructorOverflow.java
+++ b/test/jdk/java/math/BigInteger/StringConstructorOverflow.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2013, 2019, 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
@@ -23,9 +23,9 @@
 
 /*
  * @test
- * @ignore This test has huge memory requirements
  * @bug 8021204
  * @summary Test constructor BigInteger(String val, int radix) on very long string
+ * @ignore This test has huge memory requirements
  * @run main/othervm -Xshare:off -Xmx8g StringConstructorOverflow
  * @author Dmitry Nadezhin
  */

--- a/test/jdk/java/math/BigInteger/SymmetricRangeTests.java
+++ b/test/jdk/java/math/BigInteger/SymmetricRangeTests.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2013, 2017, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2013, 2019, 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
@@ -23,8 +23,8 @@
 
 /*
  * @test
+ * @library /test/lib
  * @ignore This test has huge memory requirements
- * @library /test/lib
  * @run main/timeout=180/othervm -Xmx8g SymmetricRangeTests
  * @bug 6910473 8021204 8021203 9005933 8074460 8078672
  * @summary Test range of BigInteger values (use -Dseed=X to set PRNG seed)


From darknaviroguez2 at gmail.com  Thu May 30 21:44:38 2019
From: darknaviroguez2 at gmail.com (Jake Hikari)
Date: Thu, 30 May 2019 14:44:38 -0700
Subject: jpackage https://jdk.java.net/jpackage/ page error
Message-ID: <CAPGQoxdPCF3wY=QpUCK-O6iRP4ax23fo3NdJ4u5YHRQ_8ER0SQ@mail.gmail.com>

Incorrect link to https://bugs.openjdk.java.net/browse/JDK-8205991 "Cannot
start application (WinLauncher) if path contains non-ascii character" in
notes section
Link to https://bugs.openjdk.java.net/browse/JDK-8204991 "PPC64: Fix jtreg
RTM tests after "8203305: Improve TM detection for enabling RTM on Linux /
POWER9"" given instead

From Alan.Bateman at oracle.com  Fri May 31 16:32:53 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 31 May 2019 17:32:53 +0100
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <AM6PR02MB51924EFF0E6E9A3C3FCB91B98A1F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <a3e64312-d902-b751-d55d-0af1c4c6e3c5@oracle.com>
 <953449f0913340f6a94ae3d83611fd92@sap.com>
 <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>
 <HE1PR0201MB2266326D98F5119796990BFC8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
 <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <fad24c8f-aa40-821e-fa15-9cbe32b0eb76@oracle.com>
 <DB7PR02MB51937A87EECD7D1E01F71D098A070@DB7PR02MB5193.eurprd02.prod.outlook.com>
 <62a26037-a991-dc31-a972-a82386f63b92@oracle.com>
 <AM6PR02MB51924EFF0E6E9A3C3FCB91B98A1F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <9806f4b1-9b55-d1d8-4511-5db0ef6786a5@oracle.com>

On 29/05/2019 13:16, Langer, Christoph wrote:
> Hi Alan,
>
>> The table items in L119-150 look fine, we just need to avoid really long
>> lines One minor comment on L123 is that it might be clearer if you drop
>> "created" from the sentence.
>>
>> L48-78 is a "wall of text" and links that I don't think will be easy for
>> most developers to read. Can I provide suggested wording for this part
>> of the spec? I'm just thinking that an alternative wording might help
>> avoid too much iteration on this.
> I have created a new webrev to add some linebreaks and pick up your suggestion to drop the word "created" in L123.
>
> http://cr.openjdk.java.net/~clanger/webrevs/8213031.12/
>
> Waiting on your update for the other part.
Attached is alternative wording for the "Support for POSIX file 
permissions" section. My concern with the proposed in webrev.12 is that 
it's dense and not easy to read. It also misses a few things - one 
important one is that access permissions aren't enforced.

So overall I think you've got this feature into reasonable shape (I 
realize it has taken 7 months to get here, this is perhaps a good 
example of something that needs a lot of up front discussion before 
going near the code).

-Alan


import java.nio.file.Files;
import java.nio.file.LinkOption;
import java.nio.file.Path;
import java.nio.file.attribute.FileAttributeView;
import java.nio.file.attribute.PosixFileAttributes;
import java.nio.file.attribute.PosixFilePermission;
import java.nio.file.attribute.PosixFileAttributeView;
import java.util.Set;


 ?* <h2> POSIX file attributes </h2>
 ?*
 ?* <p> A Zip file system supports a file attribute {@link 
FileAttributeView view}
 ?* named "{@code zip}" that defines the following file attribute:
 ?*
 ?* <blockquote>
 ?* <table class="striped">
 ?* <caption style="display:none">Supported attributes</caption>
 ?* <thead>
 ?*?? <tr>
 ?*???? <th scope="col"> Name </th>
 ?*???? <th scope="col"> Type </th>
 ?*?? </tr>
 ?* </thead>
 ?* <tbody>
 ?*? <tr>
 ?*???? <th scope="row"> permissions </th>
 ?*???? <td> {@link Set}&lt;{@link PosixFilePermission}&gt; </td>
 ?*?? </tr>
 ?* </tbody>
 ?* </table>
 ?* </blockquote>
 ?*
 ?* The "permissions" attribute is the set of access permissions that 
are optionally
 ?* stored for entries in a Zip file. The value of the attribute is 
{@code null}
 ?* for entries that do not have access permissions. Zip file systems do not
 ?* enforce access permissions.
 ?*
 ?* <p> The "permissions" attribute can be read and set using the
 ?* {@linkplain Files#getAttribute(Path, String, LinkOption...) 
Files.getAttribute} and
 ?* {@linkplain Files#setAttribute(Path, String, Object, LinkOption...) 
Files.setAttribute}
 ?* methods. The following example uses these methods to read and set 
the attribute:
 ?* <pre> {@code
 ?*???? Set<PosixFilePermission> perms = Files.getAttribute(entry, 
"zip:permissions");
 ?*???? if (perms == null) {
 ?*???????? perms = PosixFilePermissions.fromString("rw-rw-rw-");
 ?*???????? Files.setAttribute(entry, "zip:permissions", perms);
 ?*???? }
 ?* } </pre>
 ?*
 ?* <p> In addition to the "{@code zip}" view, a Zip file system 
optionally supports
 ?* the {@link PosixFileAttributeView POSIX file attribute view} 
("{@code posix}").
 ?* This view extends the "{@code basic}" view with type safe access to the
 ?* {@link PosixFileAttributes#owner() owner}, {@link 
PosixFileAttributes#group() group-owner},
 ?* and {@link PosixFileAttributes#permissions() permissions} 
attributes. The
 ?* "{@code posix}" view is only supported when the Zip file system is 
created with
 ?* the provider property "{@code enablePosixFileAttributes}" set to 
"{@code true}".
 ?* The following creates a file system with this property and reads the 
access
 ?* permissions of a file:
 ?* <pre> {@code
 ?*???? var env = Map.of("enablePosixFileAttributes", "true");
 ?*???? try (FileSystem fs = FileSystems.newFileSystem(file, env) {
 ?*???????? Path entry = fs.getPath("entry");
 ?*???????? Set<PosixFilePermission> perms = 
Files.getPosixFilePermissions(entry);
 ?*???? }
 ?* } </pre>
 ?*
 ?* <p> The file owner and group owner attributes are not persisted, 
meaning they are
 ?* not stored in the zip file. The "{@code defaultOwner}" and "{@code 
defaultGroup}"
 ?* provider properties (listed below) can be used to configure the 
default values
 ?* for these attributes. If these properties are not set then the file 
owner
 ?* defaults to the owner of the zip file, and the group owner defaults 
to the
 ?* zip file's group owner (or the file owner on platforms that don't 
support a
 ?* group owner).
 ?*
 ?* <p> The "{@code permissions}" attribute is not optional in the 
"{@code posix}"
 ?* view so a default of set of permissions are used for entries that do 
not have
 ?* access permissions stored in the Zip file. The default set of 
permissions
 ?* is {@link PosixFilePermission#OWNER_READ OWNER_READ}, {@link 
PosixFilePermission#OWNER_WRITE
 ?* OWNER_WRITE} and {@link PosixFilePermission#GROUP_READ GROUP_READ}. 
The default
 ?* permissions can be configured with the "{@code defaultPermissions}" 
property
 ?* described below.


From joe.darcy at oracle.com  Fri May 31 16:40:45 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 31 May 2019 09:40:45 -0700
Subject: 8225117: java/math/BigInteger/SymmetricRangeTests.java fails with
 ParseException
In-Reply-To: <DD6D7CB7-6BF6-4087-AD37-EBFF09CE9DAB@oracle.com>
References: <DD6D7CB7-6BF6-4087-AD37-EBFF09CE9DAB@oracle.com>
Message-ID: <55f9fbc6-96b1-4bfc-c2bb-9cc08013a7be@oracle.com>

Look fine Brian; cheers,

-Joe

On 5/31/2019 8:33 AM, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8225117 <https://bugs.openjdk.java.net/browse/JDK-8225117>
>
> For SymmetricRangeTests the @ignore action tag needs to be after @library but before @run.
>
> For StringConstructorOverflow the test is OK as is, but move the @ignore to just before @run for consistency.
>
> Thanks,
>
> Brian
>
> --- a/test/jdk/java/math/BigInteger/StringConstructorOverflow.java
> +++ b/test/jdk/java/math/BigInteger/StringConstructorOverflow.java
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2013, 2019, 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
> @@ -23,9 +23,9 @@
>   
>   /*
>    * @test
> - * @ignore This test has huge memory requirements
>    * @bug 8021204
>    * @summary Test constructor BigInteger(String val, int radix) on very long string
> + * @ignore This test has huge memory requirements
>    * @run main/othervm -Xshare:off -Xmx8g StringConstructorOverflow
>    * @author Dmitry Nadezhin
>    */
>
> --- a/test/jdk/java/math/BigInteger/SymmetricRangeTests.java
> +++ b/test/jdk/java/math/BigInteger/SymmetricRangeTests.java
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2013, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2013, 2019, 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
> @@ -23,8 +23,8 @@
>   
>   /*
>    * @test
> + * @library /test/lib
>    * @ignore This test has huge memory requirements
> - * @library /test/lib
>    * @run main/timeout=180/othervm -Xmx8g SymmetricRangeTests
>    * @bug 6910473 8021204 8021203 9005933 8074460 8078672
>    * @summary Test range of BigInteger values (use -Dseed=X to set PRNG seed)
>

From Roger.Riggs at oracle.com  Fri May 31 17:24:19 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 31 May 2019 13:24:19 -0400
Subject: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with
 an explicit 'no guarantee' statement
In-Reply-To: <CA+kOe0_pBgXHuCtetYd7cur1-1ridnvJZWhDEt_k_=9cWZPVSQ@mail.gmail.com>
References: <0f7c965f-e07b-67d4-2d37-ba911ca0c66e@oracle.com>
 <8ce9af61-98a2-3497-d59e-6daa00d951a4@redhat.com>
 <ad752c55-e10c-ef8c-5514-7c98d72cb8c0@oracle.com>
 <CAMOCf+gNhqqF-Oe8r4ixSp-o3BG8-KbWp-XF5ca_Wb=f4zStQA@mail.gmail.com>
 <c6946d95-dcf9-179f-371f-2fdfbfda3365@oracle.com>
 <939dc43a-2080-c055-51a7-f7f66bd44e2c@redhat.com>
 <61a8908b-1b5f-40d0-8f01-feef59f27d52@oracle.com>
 <f00f5c51-b316-f135-38b6-f570df237a3e@gmail.com>
 <449aa33b-39e2-8f8f-90f2-ffcb04c7e6a0@redhat.com>
 <f936f160-2627-4b6e-43b2-d7bed38cd04c@oracle.com>
 <b9bf8346-e5f5-9c01-ad29-70659185ebbc@gmail.com>
 <a91fe0f8-6b28-92d2-6e78-13813081e751@oracle.com>
 <47be64b7-f88b-8125-ac55-8fb65cfd0cbc@redhat.com>
 <CA+kOe0_pBgXHuCtetYd7cur1-1ridnvJZWhDEt_k_=9cWZPVSQ@mail.gmail.com>
Message-ID: <99120787-64db-449b-1df2-9e69c14efb03@oracle.com>

Hi Martin,

True, calling System.gc() and then checking for its hoped-for/expected 
side-effects is the norm.
But its robustness depends on a combination of gc implementation 
behavior and
the particular side-effect expected: allocation, reference processing, etc.

Roger

On 05/30/2019 01:30 PM, Martin Buchholz wrote:
> If you are calling System.gc() for correctness (e.g. in a test), it is 
> probably because some sort of finalization is being triggered.? And 
> that happens in some Java thread (e.g. Reference Handler) that 
> System.gc() has no control over.? So in practice, users need to call 
> System.gc() and then wait for subsequent reference processing somehow.


From jonathan.gibbons at oracle.com  Fri May 31 17:37:07 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 31 May 2019 10:37:07 -0700
Subject: RFR [XS,docs] JDK-8225129: Fix minor HTML issues in java.naming
Message-ID: <9f2fa9e5-3dfd-edc6-03d3-88c740a94811@oracle.com>

Please review another round of fixes for HTML issues, this time in 
java.naming.

As with the management APIs, there were some inconsistencies in the 
ranks for the headings, which have been addressed.? The log with the 
simplified diff listing is attached.

-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8225129
Webrev: http://cr.openjdk.java.net/~jjg/8225129/webrev.00/webrev/index.html



-------------- next part --------------
>>> open/src/java.naming/share/classes/javax/naming/directory/package.html
BEFORE:
<h3>The Directory Context</h3>
<h4>Searches</h4>
<h2>Package Specification</h2>

AFTER:
<h2>The Directory Context</h2>
<h3>Searches</h3>
<h2>Package Specification</h2>


>>> open/src/java.naming/share/classes/javax/naming/event/package.html
BEFORE:
<h3>Naming Events</h3>
<h4>Threading Issues</h4>
<h4>Exception Handling</h4>
<h2>Package Specification</h2>

AFTER:
<h2>Naming Events</h2>
<h3>Threading Issues</h3>
<h3>Exception Handling</h3>
<h2>Package Specification</h2>


>>> open/src/java.naming/share/classes/javax/naming/ldap/InitialLdapContext.java
BEFORE:
  * <h1>Request Controls</h1>

AFTER:
  * <h2>Request Controls</h2>


>>> open/src/java.naming/share/classes/javax/naming/ldap/package.html
BEFORE:
<h3>Extended Operations</h3>
<h3>Controls</h3>
<h2>Package Specification</h2>

AFTER:
<h2>Extended Operations</h2>
<h2>Controls</h2>
<h2>Package Specification</h2>


>>> open/src/java.naming/share/classes/javax/naming/package.html
BEFORE:
<h3>Context</h3>
<h3>Names</h3>
<h3>Bindings</h3>
<h3>References</h3>
<h3>The Initial Context</h3>
<h3>Exceptions</h3>
<h2>Package Specification</h2>

AFTER:
<h2>Context</h2>
<h2>Names</h2>
<h2>Bindings</h2>
<h2>References</h2>
<h2>The Initial Context</h2>
<h2>Exceptions</h2>
<h2>Package Specification</h2>


>>> open/src/java.naming/share/classes/javax/naming/spi/package.html
BEFORE:
<h3>Plug-in Architecture</h3>
<h3>Java Object Support</h3>
<h3>Multiple Naming Systems (Federation)</h3>
<h2>Package Specification</h2>

AFTER:
<h2>Plug-in Architecture</h2>
<h2>Java Object Support</h2>
<h2>Multiple Naming Systems (Federation)</h2>
<h2>Package Specification</h2>



From lance.andersen at oracle.com  Fri May 31 17:52:43 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 31 May 2019 13:52:43 -0400
Subject: RFR [XS,docs] JDK-8225129: Fix minor HTML issues in java.naming
In-Reply-To: <9f2fa9e5-3dfd-edc6-03d3-88c740a94811@oracle.com>
References: <9f2fa9e5-3dfd-edc6-03d3-88c740a94811@oracle.com>
Message-ID: <44D9A8BE-B3BE-4828-8121-2E06B66902F4@oracle.com>

+1
> On May 31, 2019, at 1:37 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> <diff.log.txt>

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




From mandy.chung at oracle.com  Fri May 31 17:53:21 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 31 May 2019 10:53:21 -0700
Subject: RFR [XS,docs] JDK-8225129: Fix minor HTML issues in java.naming
In-Reply-To: <9f2fa9e5-3dfd-edc6-03d3-88c740a94811@oracle.com>
References: <9f2fa9e5-3dfd-edc6-03d3-88c740a94811@oracle.com>
Message-ID: <8c15d0ee-7e82-a79d-a09d-7598ad2714f9@oracle.com>

Looks fine.

Mandy

On 5/31/19 10:37 AM, Jonathan Gibbons wrote:
> Please review another round of fixes for HTML issues, this time in 
> java.naming.
>
> As with the management APIs, there were some inconsistencies in the 
> ranks for the headings, which have been addressed.? The log with the 
> simplified diff listing is attached.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8225129
> Webrev: 
> http://cr.openjdk.java.net/~jjg/8225129/webrev.00/webrev/index.html
>
>
>


From lance.andersen at oracle.com  Fri May 31 18:00:53 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 31 May 2019 14:00:53 -0400
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <9806f4b1-9b55-d1d8-4511-5db0ef6786a5@oracle.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <a3e64312-d902-b751-d55d-0af1c4c6e3c5@oracle.com>
 <953449f0913340f6a94ae3d83611fd92@sap.com>
 <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com>
 <HE1PR0201MB2266326D98F5119796990BFC8A410@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <a1d07268-b4d2-23eb-6de2-a91766a985ee@oracle.com>
 <AM6PR02MB5192FC0B58CB4CF7176189878A330@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <fad24c8f-aa40-821e-fa15-9cbe32b0eb76@oracle.com>
 <DB7PR02MB51937A87EECD7D1E01F71D098A070@DB7PR02MB5193.eurprd02.prod.outlook.com>
 <62a26037-a991-dc31-a972-a82386f63b92@oracle.com>
 <AM6PR02MB51924EFF0E6E9A3C3FCB91B98A1F0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <9806f4b1-9b55-d1d8-4511-5db0ef6786a5@oracle.com>
Message-ID: <33E52896-E491-4660-A932-46D5A270A63E@oracle.com>


> On May 31, 2019, at 12:32 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 29/05/2019 13:16, Langer, Christoph wrote:
>> Hi Alan,
>> 
>>> The table items in L119-150 look fine, we just need to avoid really long
>>> lines One minor comment on L123 is that it might be clearer if you drop
>>> "created" from the sentence.
>>> 
>>> L48-78 is a "wall of text" and links that I don't think will be easy for
>>> most developers to read. Can I provide suggested wording for this part
>>> of the spec? I'm just thinking that an alternative wording might help
>>> avoid too much iteration on this.
>> I have created a new webrev to add some linebreaks and pick up your suggestion to drop the word "created" in L123.
>> 
>> http://cr.openjdk.java.net/~clanger/webrevs/8213031.12/
>> 
>> Waiting on your update for the other part.
> Attached is alternative wording for the "Support for POSIX file permissions" section. My concern with the proposed in webrev.12 is that it's dense and not easy to read. It also misses a few things - one important one is that access permissions aren't enforced.

I think the wording below is looking good.  A few minor suggestions below.
> 
> So overall I think you've got this feature into reasonable shape (I realize it has taken 7 months to get here, this is perhaps a good example of something that needs a lot of up front discussion before going near the code).

Once we finalize the CSR, we should look towards getting the changes in early in the JDK 14 cycle so that we have time to vet/catch potential issues.

> 
> -Alan
> 
> 
> import java.nio.file.Files;
> import java.nio.file.LinkOption;
> import java.nio.file.Path;
> import java.nio.file.attribute.FileAttributeView;
> import java.nio.file.attribute.PosixFileAttributes;
> import java.nio.file.attribute.PosixFilePermission;
> import java.nio.file.attribute.PosixFileAttributeView;
> import java.util.Set;
> 
> 
>  * <h2> POSIX file attributes </h2>
>  *
>  * <p> A Zip file system supports a file attribute {@link FileAttributeView view}
>  * named "{@code zip}" that defines the following file attribute:
>  *
>  * <blockquote>
>  * <table class="striped">
>  * <caption style="display:none">Supported attributes</caption>
>  * <thead>
>  *   <tr>
>  *     <th scope="col"> Name </th>
>  *     <th scope="col"> Type </th>
>  *   </tr>
>  * </thead>
>  * <tbody>
>  *  <tr>
>  *     <th scope="row"> permissions </th>
>  *     <td> {@link Set}&lt;{@link PosixFilePermission}&gt; </td>
>  *   </tr>
>  * </tbody>
>  * </table>
>  * </blockquote>
>  *
>  * The "permissions" attribute is the set of access permissions that are optionally
>  * stored for entries in a Zip file. The value of the attribute is {@code null}
>  * for entries that do not have access permissions. Zip file systems do not
>  * enforce access permissions.
>  *
>  * <p> The "permissions" attribute can be read and set using the
can-> may
>  * {@linkplain Files#getAttribute(Path, String, LinkOption...) Files.getAttribute} and
>  * {@linkplain Files#setAttribute(Path, String, Object, LinkOption...) Files.setAttribute}
>  * methods. The following example uses these methods to read and set the attribute:
>  * <pre> {@code
>  *     Set<PosixFilePermission> perms = Files.getAttribute(entry, "zip:permissions");
>  *     if (perms == null) {
>  *         perms = PosixFilePermissions.fromString("rw-rw-rw-");
>  *         Files.setAttribute(entry, "zip:permissions", perms);
>  *     }
>  * } </pre>
>  *
>  * <p> In addition to the "{@code zip}" view, a Zip file system optionally supports
>  * the {@link PosixFileAttributeView POSIX file attribute view} ("{@code posix}").
>  * This view extends the "{@code basic}" view with type safe access to the
>  * {@link PosixFileAttributes#owner() owner}, {@link PosixFileAttributes#group() group-owner},
>  * and {@link PosixFileAttributes#permissions() permissions} attributes. The
>  * "{@code posix}" view is only supported when the Zip file system is created with
>  * the provider property "{@code enablePosixFileAttributes}" set to "{@code true}".
>  * The following creates a file system with this property and reads the access
>  * permissions of a file:
>  * <pre> {@code
>  *     var env = Map.of("enablePosixFileAttributes", "true");
>  *     try (FileSystem fs = FileSystems.newFileSystem(file, env) {
>  *         Path entry = fs.getPath("entry");
>  *         Set<PosixFilePermission> perms = Files.getPosixFilePermissions(entry);
>  *     }
>  * } </pre>
>  *
>  * <p> The file owner and group owner attributes are not persisted, meaning they are
>  * not stored in the zip file. The "{@code defaultOwner}" and "{@code defaultGroup}"
>  * provider properties (listed below) can be used to configure the default values
>  * for these attributes. If these properties are not set then the file owner
>  * defaults to the owner of the zip file, and the group owner defaults to the
>  * zip file's group owner (or the file owner on platforms that don't support a
>  * group owner).
>  *
>  * <p> The "{@code permissions}" attribute is not optional in the "{@code posix}"
>  * view so a default of set of permissions are used for entries that do not have
                                 ^^^
                           of seems out of place
>  * access permissions stored in the Zip file. The default set of permissions
>  * is {@link PosixFilePermission#OWNER_READ OWNER_READ}, {@link PosixFilePermission#OWNER_WRITE
is -> are
>  * OWNER_WRITE} and {@link PosixFilePermission#GROUP_READ GROUP_READ}.
perhaps consider using a <UL>  when listing the permissions?
> The default
>  * permissions can be configured with the "{@code defaultPermissions}" property
>  * described below.



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 kim.barrett at oracle.com  Fri May 31 18:45:27 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 31 May 2019 14:45:27 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <f354b7b3-479e-d097-42dd-1e40d1dcc187@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
 <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
 <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com>
 <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com>
 <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com>
 <fde51a92-22a6-5cee-aea3-d193b2548277@oracle.com>
 <f354b7b3-479e-d097-42dd-1e40d1dcc187@oracle.com>
Message-ID: <C6079C73-0CF5-4FEA-ADBC-A85DA3766AD4@oracle.com>

> On May 31, 2019, at 9:33 AM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
> 
> Thumbs up.
> 
> Dan

Thanks.

> 
> 
> On 5/31/19 8:02 AM, Roger Riggs wrote:
>> +1
>> 
>> On 5/31/19 2:19 AM, David Holmes wrote:
>>> Hi Kim,
>>> 
>>> This seems reasonable to me.
>>> 
>>> Thanks,
>>> David
>>> 
>>> On 31/05/2019 7:04 am, Kim Barrett wrote:
>>>>> On May 30, 2019, at 3:58 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>> 
>>>>> Hi Kim,
>>>>> 
>>>>> To ensure you see some messages in the case of timeouts, it would be
>>>>> useful to call System.out.flush() after printing the message in logProcess().
>>>> 
>>>> Good idea; added.
>>>> 
>>>> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/
>>>> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/
>>>> 
>>>>> I'm ok with the timestamps, as is, though the Duration might be useful in
>>>>> some cases.
>>>> 
>>>> As I discussed with Roger, I want to keep the change simple for now,
>>>> as we're not yet sure where to expend effort looking deeper. I think
>>>> comparing timestamps in just a few cases will tell us a lot (possibly
>>>> that we're looking in entirely the wrong place, in which case we might
>>>> just undo this change).



From kim.barrett at oracle.com  Fri May 31 18:45:37 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 31 May 2019 14:45:37 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <fde51a92-22a6-5cee-aea3-d193b2548277@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
 <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
 <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com>
 <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com>
 <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com>
 <fde51a92-22a6-5cee-aea3-d193b2548277@oracle.com>
Message-ID: <F90A5E7F-992D-4EF8-B8FC-4635B8C740E0@oracle.com>

> On May 31, 2019, at 8:02 AM, Roger Riggs <roger.riggs at oracle.com> wrote:
> 
> +1

Thanks.

> 
> On 5/31/19 2:19 AM, David Holmes wrote:
>> Hi Kim,
>> 
>> This seems reasonable to me.
>> 
>> Thanks,
>> David
>> 
>> On 31/05/2019 7:04 am, Kim Barrett wrote:
>>>> On May 30, 2019, at 3:58 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>> 
>>>> Hi Kim,
>>>> 
>>>> To ensure you see some messages in the case of timeouts, it would be
>>>> useful to call System.out.flush() after printing the message in logProcess().
>>> 
>>> Good idea; added.
>>> 
>>> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/
>>> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/
>>> 
>>>> I'm ok with the timestamps, as is, though the Duration might be useful in
>>>> some cases.
>>> 
>>> As I discussed with Roger, I want to keep the change simple for now,
>>> as we're not yet sure where to expend effort looking deeper.  I think
>>> comparing timestamps in just a few cases will tell us a lot (possibly
>>> that we're looking in entirely the wrong place, in which case we might
>>> just undo this change).



From kim.barrett at oracle.com  Fri May 31 18:45:49 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 31 May 2019 14:45:49 -0400
Subject: RFR: 8219149: ProcessTools.ProcessBuilder should print timing
 info for subprocesses
In-Reply-To: <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com>
References: <D7BE74EF-06D2-4237-A4A7-AF46A4752019@oracle.com>
 <1855dae9-e068-5e0a-e387-2133ae18fdc6@oracle.com>
 <6c572443-4217-4e0a-ff80-9f738c8ebc58@oracle.com>
 <86115e1a-fca4-2129-0bb6-9d2dafecadf3@oracle.com>
 <1CDB80A3-5DC3-4474-A5E8-8422523EE42C@oracle.com>
 <69c69972-e00a-0e02-2659-4ca2009a9b69@oracle.com>
Message-ID: <03361DB4-E364-4532-A48D-952AD11BA37A@oracle.com>

> On May 31, 2019, at 2:19 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Kim,
> 
> This seems reasonable to me.
> 
> Thanks,
> David

Thanks.

> 
> On 31/05/2019 7:04 am, Kim Barrett wrote:
>>> On May 30, 2019, at 3:58 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>> 
>>> Hi Kim,
>>> 
>>> To ensure you see some messages in the case of timeouts, it would be
>>> useful to call System.out.flush() after printing the message in logProcess().
>> Good idea; added.
>> full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/
>> incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/
>>> I'm ok with the timestamps, as is, though the Duration might be useful in
>>> some cases.
>> As I discussed with Roger, I want to keep the change simple for now,
>> as we're not yet sure where to expend effort looking deeper.  I think
>> comparing timestamps in just a few cases will tell us a lot (possibly
>> that we're looking in entirely the wrong place, in which case we might
>> just undo this change).