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:06:18 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 May 2019 07:06:18 +0100
Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA)
In-Reply-To: <CAOEheN6v4iVA6d74PFpF=VRoMGZ5Z1bY0z_wyr5cGoiWdAMUXQ@mail.gmail.com>
References: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AF5@ORSMSX113.amr.corp.intel.com>
 <d8f916bd-4278-b36b-f6ac-fb0ff889ba22@oracle.com>
 <9ACD5B67AAC5594CB6268234CF29CF9AD140CE19@ORSMSX113.amr.corp.intel.com>
 <CAOEheN6v4iVA6d74PFpF=VRoMGZ5Z1bY0z_wyr5cGoiWdAMUXQ@mail.gmail.com>
Message-ID: <7822f79b-0ee2-73b8-a876-26b1c5de6df2@oracle.com>

On 01/05/2019 03:26, yumin qi wrote:
> Hi, Yingqi
>
>    Have you integrated RDMA implementation into jdk13? I haven't seen
> messages related to this JEP since the last email in this thread.
>
The JEP is a candidate [1], not targeted to any release yet (so not 
integrated). The discussion on this feature is on the nio-dev mailing 
list (there are hundreds of mails but you should be able to catch up via 
the archives). The main blocking issues right now are bugs in the Linux 
RDMA support [1]. One of the Intel committers on that project has PRs to 
fix those issues so the development should be able to continue.

-Alan

[1] https://openjdk.java.net/jeps/337
[2] https://github.com/linux-rdma/rdma-core

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 Alan.Bateman at oracle.com  Wed May  1 13:10:13 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 May 2019 14:10:13 +0100
Subject: 8218559: Reimplement the Legacy Socket API
Message-ID: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>


JEP 353 [1] is now a candidate and I would like to get the CSR [2] 
finalized and the changes reviewed so that it can be targeted.

The webrev with the changes is here:
 ?? http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html

The new implementation is one source file; the only other code change is 
to SocketImpl.createPlatformSocketImpl to select the implementation 
based on the system property jdk.net.usePlainSocketImpl. The reason the 
patch isn't too big is that all the "enabling changes" are already in 
jdk/jdk.

We added additional tests a few weeks ago via JDK-8221259 [3] to test 
long standing behavior. The webrev adds a few additional tests, the main 
new one is to test that the SocketImpl is reliable in the fact of usages 
that are not specified by SocketImpl. A selection of existing tests are 
also updated to run with both the old and new implementation - the 
motive of this is to ensure that the old implementation doesn't bit rot 
before it is removed.

Once the changes are in a promoted build then we'll need help testing. 
The best outcome is that nobody notices :-)? Rory O'Donnell, with his 
OpenJDK quality outreach hat on, has agreed to contact the projects 
tracked by that program to test the EA builds when they are available.

-Alan

[1] https://openjdk.java.net/jeps/353
[2] https://bugs.openjdk.java.net/browse/JDK-8222028
[3] https://bugs.openjdk.java.net/browse/JDK-8221259

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 18:11:53 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 May 2019 19:11:53 +0100
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
Message-ID: <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>


On 25/04/2019 00:11, Brian Burkhalter wrote:
>
> I added lutimes() to the retry section (lines 140-141) [1, 2].
That part is fine but I'm still concerned that the code doesn't know if 
there is lutimes support or not. If there is lutimes support then we'd 
skip the openFileAttributeAccess when !followLinks and the file is a sym 
link. I guess I was expecting a new capabilities bit to be added so that 
UnixNativeDispacher.init returns the bit set when the platform supports 
the feature.

-Alan

From brian.burkhalter at oracle.com  Wed May  1 18:17:02 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 May 2019 11:17:02 -0700
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
Message-ID: <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>


> On May 1, 2019, at 11:11 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 25/04/2019 00:11, Brian Burkhalter wrote:
>> 
>> I added lutimes() to the retry section (lines 140-141) [1, 2].
> That part is fine but I'm still concerned that the code doesn't know if there is lutimes support or not. If there is lutimes support then we'd skip the openFileAttributeAccess when !followLinks and the file is a sym link. I guess I was expecting a new capabilities bit to be added so that UnixNativeDispacher.init returns the bit set when the platform supports the feature.

I see. I can look into adding that.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190501/4a131d77/attachment-0001.html>

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190501/7a06652b/attachment-0001.html>

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 brian.burkhalter at oracle.com  Wed May  1 19:16:07 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 May 2019 12:16:07 -0700
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
Message-ID: <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>


> On May 1, 2019, at 11:17 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>> On May 1, 2019, at 11:11 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>> 
>> On 25/04/2019 00:11, Brian Burkhalter wrote:
>>> 
>>> I added lutimes() to the retry section (lines 140-141) [1, 2].
>> That part is fine but I'm still concerned that the code doesn't know if there is lutimes support or not. If there is lutimes support then we'd skip the openFileAttributeAccess when !followLinks and the file is a sym link. I guess I was expecting a new capabilities bit to be added so that UnixNativeDispacher.init returns the bit set when the platform supports the feature.
> 
> I see. I can look into adding that.

Modified as suggested above: new capabilities bit added and logic changed to respond according to whether it is set:

http://cr.openjdk.java.net/~bpb/8220793/webrev.02/ <http://cr.openjdk.java.net/~bpb/8220793/webrev.02/>

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190501/3be4fb2d/attachment.html>

From lance.andersen at oracle.com  Wed May  1 19:29:35 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 1 May 2019 15:29:35 -0400
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
Message-ID: <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>

Coming back to this.

The updated webrev can be found at:

http://cr.openjdk.java.net/~lancea/8218875/webrev.02/index.html <http://cr.openjdk.java.net/~lancea/8218875/webrev.02/index.html>

The CSR was approved this morning https://bugs.openjdk.java.net/browse/JDK-8219793 <https://bugs.openjdk.java.net/browse/JDK-8219793> 

I have also created a sub-task for a release note for this change https://bugs.openjdk.java.net/browse/JDK-8223197


I have run the  Mach5 tier1, tier2, and tier3 tests as well as the JCK api/java_nio/file tests via Mach5 without any failures


> On Feb 20, 2019, at 1:32 PM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Good. Now you can go and change all places where you call newFileSystem(Path, (ClassLoader)null) to newFileSystem(Path) ??

I made the change were possible.  The classes modified in the  jdk.compiler module have to stay as is in order to compile when BUILD_jdk.compiler.interim runs.  When the boot JDK is updated, I believe this can be changed.

>  
> From: Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> 
> Sent: Mittwoch, 20. Februar 2019 19:12
> To: Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>
> Cc: Langer, Christoph <christoph.langer at sap.com <mailto:christoph.langer at sap.com>>; nio-dev at openjdk.java.net <mailto:nio-dev at openjdk.java.net>
> Subject: Re: RFR 8218875: Add new FileSystems.newFileSystem methods
>  
>  
> On Feb 20, 2019, at 11:41 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>  
> On 20/02/2019 13:17, Langer, Christoph wrote:
> 
> :
> But, in any case, there's one thing I'm missing: Why don't you add a FileSystems.newFileSystem(Path) method? I think that's the method that people want to call usually when they currently call FileSystems.newFileSystem(Path, (ClassLoader)null)...
> 
> I agree that it's worth considering now, if only because zipfs has got a lot of attention.
>  
> Ok,  http://cr.openjdk.java.net/~lancea/8218875/webrev.01/index.html <http://cr.openjdk.java.net/~lancea/8218875/webrev.01/index.html>  adds it
> 
> 
> 
> -Alan
> 
>  
> <image001.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>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190501/2d36c6c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190501/2d36c6c2/oracle_sig_logo-0001.gif>

From Alan.Bateman at oracle.com  Wed May  1 19:50:17 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 May 2019 20:50:17 +0100
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
Message-ID: <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>

On 01/05/2019 20:16, Brian Burkhalter wrote:
> :
>
> Modified as suggested above: new capabilities bit added and logic 
> changed to respond according to whether it is set:
>
> http://cr.openjdk.java.net/~bpb/8220793/webrev.02/
>
Thanks, the logic in setTimes looks right. As setting the time stamps on 
a sym link is a bit of outlier then I think I would put the useFutimes 
first but that is no big deal.

The new changes to UnixNativeDispatcher.c create an inconsistency that 
I'm trying to figure out. The init method is using dlym whereas the the 
Java_sun_nio_fs_UnixNativeDispatcher_lutimes0 references the function. 
If you are confident that lutimes is available on the all the gcc 
versions that are used to build the JDK then my_lutimes_func is not needed.

-Alan

From brian.burkhalter at oracle.com  Wed May  1 20:01:30 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 May 2019 13:01:30 -0700
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
Message-ID: <8C1FB11D-9ADA-431F-929A-200887D89977@oracle.com>


> On May 1, 2019, at 12:50 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> The new changes to UnixNativeDispatcher.c create an inconsistency that I'm trying to figure out. The init method is using dlym whereas the the Java_sun_nio_fs_UnixNativeDispatcher_lutimes0 references the function. If you are confident that lutimes is available on the all the gcc versions that are used to build the JDK then my_lutimes_func is not needed.

No, I just screwed that up. Fixing it.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190501/65f4f29c/attachment.html>

From yingqi.lu at intel.com  Wed May  1 20:39:33 2019
From: yingqi.lu at intel.com (Lu, Yingqi)
Date: Wed, 1 May 2019 20:39:33 +0000
Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA)
In-Reply-To: <fef16a1e-9c9d-2aad-3b39-752857ec0c0a@oracle.com>
References: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AF5@ORSMSX113.amr.corp.intel.com>
 <fef16a1e-9c9d-2aad-3b39-752857ec0c0a@oracle.com>
Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD16B17D0@ORSMSX113.amr.corp.intel.com>

Hi Raymond,

This is my first time doing JEP process. I am still learning it :-)

I have JEP 337 available at https://openjdk.java.net/jeps/337 Is this the JEP DOC you refer to? If not, would you please provide a little more background/information on this so that I will create the subtask accordingly?

Thank you very much for your help!

Thanks,
Lucy

>-----Original Message-----
>From: Raymond Gallardo [mailto:raymond.gallardo at oracle.com]
>Sent: Wednesday, May 1, 2019 1:13 PM
>To: Lu, Yingqi <yingqi.lu at intel.com>; jdk-dev at openjdk.java.net
>Cc: Aundhe, Shirish <shirish.aundhe at intel.com>; nio-dev at openjdk.java.net;
>Kaczmarek, Eric <eric.kaczmarek at intel.com>
>Subject: Re: Draft JEP: Socket API for Remote Direct Memory Access (RDMA)
>
>Hi Lucy,
>
>Could you verify that documentation is not required for JEP 337: RDMA
>Network Sockets? I noticed that there's no JEP DOC task associated with it.
>
>If documentation is required, could you create a JEP DOC task for it? If
>documentation isn't required, could you add the docsnoimpact label to the
>JEP?
>
>Thanks,
>--Raymond
>
>On 2018-05-18 2:21 p.m., Lu, Yingqi wrote:
>> Hi All,
>>
>> We just submitted a JEP draft https://bugs.openjdk.java.net/browse/JDK-
>8203434.  The proposal is to enhance the Java Socket API to support Remote
>Direct Memory Access (RDMA) using the rsocket protocol on the Linux-based
>platforms.
>>
>> Please review it and let us know your feedback. Thank you very much for
>your help!
>>
>> Thanks,
>> Lucy
>>
>> From: Lu, Yingqi
>> Sent: Friday, May 18, 2018 10:43 AM
>> To: 'jdk-dev at openjdk.java.net' <jdk-dev at openjdk.java.net>
>> Cc: nio-dev at openjdk.java.net; Lu, Yingqi (yingqi.lu at intel.com)
>> <yingqi.lu at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com>;
>> Aundhe, Shirish <shirish.aundhe at intel.com>; Viswanathan, Sandhya
>> <sandhya.viswanathan at intel.com>; 'Alan Bateman'
>> <Alan.Bateman at oracle.com>; 'Paul Sandoz' <paul.sandoz at oracle.com>
>> Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA)
>>
>> Hi All,
>>
>> Attached JEP draft is for bug 8195160
>https://bugs.openjdk.java.net/browse/JDK-8195160. Please review it and let
>us know your feedback. This effort is to enhance the Java Socket API to
>support Remote Direct Memory Access (RDMA) using the rsocket protocol on
>the Linux-based platforms.
>>
>> Thank you for your help!
>> Lucy
>>
>>

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 brian.burkhalter at oracle.com  Thu May  2 02:54:54 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 May 2019 19:54:54 -0700
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
Message-ID: <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>


> On May 1, 2019, at 12:50 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> Thanks, the logic in setTimes looks right. As setting the time stamps on a sym link is a bit of outlier then I think I would put the useFutimes first but that is no big deal.

I changed it to put useFuTimes first.

> The new changes to UnixNativeDispatcher.c create an inconsistency that I'm trying to figure out. The init method is using dlym whereas the the Java_sun_nio_fs_UnixNativeDispatcher_lutimes0 references the function. If you are confident that lutimes is available on the all the gcc versions that are used to build the JDK then my_lutimes_func is not needed.

I cleaned this up; hopefully it is OK now.

All tiers passed aside from a single unrelated failed test.

Thanks,

Brian

http://cr.openjdk.java.net/~bpb/8220793/webrev.03/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190501/4ed36e3a/attachment-0001.html>

From Alan.Bateman at oracle.com  Thu May  2 06:20:34 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 May 2019 07:20:34 +0100
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
 <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
Message-ID: <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>

On 02/05/2019 03:54, Brian Burkhalter wrote:
> :
>
> http://cr.openjdk.java.net/~bpb/8220793/webrev.03/
I think this version looks good.

I think the test should skip if TestUtil.supportsLinks returns false as 
otherwise it will fail on Windows machines when the user doesn't have 
the appropriate privileges.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/1dd09d01/attachment.html>

From Alan.Bateman at oracle.com  Thu May  2 07:40:25 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 May 2019 08:40:25 +0100
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
Message-ID: <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>

On 01/05/2019 20:29, Lance Andersen wrote:
> Coming back to this.
>
> The updated webrev can be found at:
>
> http://cr.openjdk.java.net/~lancea/8218875/webrev.02/index.html
>
I only have time to look at the changes to FileSystems.java right now.

One nit in the wording is in "in exactly the same manner as the 
newFileSystem ..."? - the word "method" has been dropped from the 
original text. Looks like the same thing shows up in several places so 
it would be good to fix those.

Minor formatting nit on L472 where the "throws IOException" doesn't need 
to be on its own line.

-Alan




From lance.andersen at oracle.com  Thu May  2 12:52:26 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 2 May 2019 08:52:26 -0400
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
 <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
Message-ID: <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>

Thank you Alan for catching the missing ?method?

http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html <http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html> contains your suggested updates mentioned below

Best
Lance
> On May 2, 2019, at 3:40 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 01/05/2019 20:29, Lance Andersen wrote:
>> Coming back to this.
>> 
>> The updated webrev can be found at:
>> 
>> http://cr.openjdk.java.net/~lancea/8218875/webrev.02/index.html
>> 
> I only have time to look at the changes to FileSystems.java right now.
> 
> One nit in the wording is in "in exactly the same manner as the newFileSystem ..."  - the word "method" has been dropped from the original text. Looks like the same thing shows up in several places so it would be good to fix those.
> 
> Minor formatting nit on L472 where the "throws IOException" doesn't need to be on its own line.
> 
> -Alan
> 
> 
> 

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/8d34c3dc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/8d34c3dc/oracle_sig_logo.gif>

From Roger.Riggs at oracle.com  Thu May  2 13:35:20 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 2 May 2019 09:35:20 -0400
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
 <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
 <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
Message-ID: <3222bdd5-9722-354f-d705-68a5b72c6ae8@oracle.com>

Hi Lance,

Can the edits in jdk.compiler replacing null with (ClassLoader)null use 
the 1 arg form of newFileSystem?
Or are they needed for the version-1 bootstrap compilation?

Wildcard imports are discouraged (in the new test).

Test method names that are indicative of the function being tested can 
be helpful when
reading a test log, it communicates a bit sooner what has gone wrong 
without having to read
the test javadoc.

Thanks, Roger

On 05/02/2019 08:52 AM, Lance Andersen wrote:
> Thank you Alan for catching the missing ?method?
>
> http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html 
> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.03/index.html>?contains 
> your suggested updates mentioned below
>
> Best
> Lance
>> On May 2, 2019, at 3:40 AM, Alan Bateman <Alan.Bateman at oracle.com 
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>> On 01/05/2019 20:29, Lance Andersen wrote:
>>> Coming back to this.
>>>
>>> The updated webrev can be found at:
>>>
>>> http://cr.openjdk.java.net/~lancea/8218875/webrev.02/index.html 
>>> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.02/index.html>
>>>
>> I only have time to look at the changes to FileSystems.java right now.
>>
>> One nit in the wording is in "in exactly the same manner as the 
>> newFileSystem ..."? - the word "method" has been dropped from the 
>> original text. Looks like the same thing shows up in several places 
>> so it would be good to fix those.
>>
>> Minor formatting nit on L472 where the "throws IOException" doesn't 
>> need to be on its own line.
>>
>> -Alan
>>
>>
>>
>
> <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 lance.andersen at oracle.com  Thu May  2 14:12:24 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 2 May 2019 10:12:24 -0400
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <3222bdd5-9722-354f-d705-68a5b72c6ae8@oracle.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
 <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
 <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
 <3222bdd5-9722-354f-d705-68a5b72c6ae8@oracle.com>
Message-ID: <5208506C-CC86-4A30-9D8F-F3D437CF3D38@oracle.com>

Hi Roger,

Thank you for your review 
> On May 2, 2019, at 9:35 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Hi Lance,
> 
> Can the edits in jdk.compiler replacing null with (ClassLoader)null use the 1 arg form of newFileSystem?
> Or are they needed for the version-1 bootstrap compilation?

No, I cannot use the 1 arg form unfortunately due to the bootstrap compilation. \

> 
> Wildcard imports are discouraged (in the new test).

I thought I ran optimize imports in Intellij, but I can go back and do this.  Thank you for catching this
> 
> Test method names that are indicative of the function being tested can be helpful when
> reading a test log, it communicates a bit sooner what has gone wrong without having to read
> the test javadoc.

Well, i can change them if you prefer.  Looking at the other tests in zipfs (ZipfsTester and in some of the other test areas, they are not very informative either

I tried to put a useful comment as to what the test does, but I will defer to your preference 

Best
Lance
> 
> Thanks, Roger
> 
> On 05/02/2019 08:52 AM, Lance Andersen wrote:
>> Thank you Alan for catching the missing ?method?
>> 
>> http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.03/index.html> contains your suggested updates mentioned below
>> 
>> Best
>> Lance
>>> On May 2, 2019, at 3:40 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>>> 
>>> On 01/05/2019 20:29, Lance Andersen wrote:
>>>> Coming back to this.
>>>> 
>>>> The updated webrev can be found at:
>>>> 
>>>> http://cr.openjdk.java.net/~lancea/8218875/webrev.02/index.html <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.02/index.html>
>>>> 
>>> I only have time to look at the changes to FileSystems.java right now.
>>> 
>>> One nit in the wording is in "in exactly the same manner as the newFileSystem ..."  - the word "method" has been dropped from the original text. Looks like the same thing shows up in several places so it would be good to fix those.
>>> 
>>> Minor formatting nit on L472 where the "throws IOException" doesn't need to be on its own line.
>>> 
>>> -Alan
>>> 
>>> 
>>> 
>> 
>> <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>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/54baf844/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/54baf844/oracle_sig_logo-0001.gif>

From Roger.Riggs at oracle.com  Thu May  2 14:27:05 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 2 May 2019 10:27:05 -0400
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <5208506C-CC86-4A30-9D8F-F3D437CF3D38@oracle.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
 <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
 <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
 <3222bdd5-9722-354f-d705-68a5b72c6ae8@oracle.com>
 <5208506C-CC86-4A30-9D8F-F3D437CF3D38@oracle.com>
Message-ID: <bfa673f5-b23c-0d16-b208-208bded9e7fb@oracle.com>

Hi Lance,

On 05/02/2019 10:12 AM, Lance Andersen wrote:
> Hi Roger,
>
> Thank you for your review
>> On May 2, 2019, at 9:35 AM, Roger Riggs <Roger.Riggs at oracle.com 
>> <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>> Hi Lance,
>>
>> Can the edits in jdk.compiler replacing null with (ClassLoader)null 
>> use the 1 arg form of newFileSystem?
>> Or are they needed for the version-1 bootstrap compilation?
>
> No, I cannot use the 1 arg form unfortunately due to the bootstrap 
> compilation. \
ok
>
>>
>> Wildcard imports are discouraged (in the new test).
>
> I thought I ran optimize imports in Intellij, but I can go back and do 
> this. ?Thank you for catching this
It depends on your Intellij configuration.? It can do many variations.? :)
See Editor -> Code Style -> Java and check "Use single class import"
>>
>> Test method names that are indicative of the function being tested 
>> can be helpful when
>> reading a test log, it communicates a bit sooner what has gone wrong 
>> without having to read
>> the test javadoc.
>
> Well, i can change them if you prefer. ?Looking at the other tests in 
> zipfs (ZipfsTester and in some of the other test areas, they are not 
> very informative either
>
> I tried to put a useful comment as to what the test does, but I will 
> defer to your preference
I think its best practice to use useful names.
Future maintainers will appreciate it.

Thanks, Roger

>
> Best
> Lance
>>
>> Thanks, Roger
>>
>> On 05/02/2019 08:52 AM, Lance Andersen wrote:
>>> Thank you Alan for catching the missing ?method?
>>>
>>> http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html 
>>> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.03/index.html> 
>>> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.03/index.html>?contains 
>>> your suggested updates mentioned below
>>>
>>> Best
>>> Lance
>>>> On May 2, 2019, at 3:40 AM, Alan Bateman <Alan.Bateman at oracle.com 
>>>> <mailto:Alan.Bateman at oracle.com> <mailto:Alan.Bateman at oracle.com>> 
>>>> wrote:
>>>>
>>>> On 01/05/2019 20:29, Lance Andersen wrote:
>>>>> Coming back to this.
>>>>>
>>>>> The updated webrev can be found at:
>>>>>
>>>>> http://cr.openjdk.java.net/~lancea/8218875/webrev.02/index.html 
>>>>> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.02/index.html> 
>>>>> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.02/index.html>
>>>>>
>>>> I only have time to look at the changes to FileSystems.java right now.
>>>>
>>>> One nit in the wording is in "in exactly the same manner as the 
>>>> newFileSystem ..."? - the word "method" has been dropped from the 
>>>> original text. Looks like the same thing shows up in several places 
>>>> so it would be good to fix those.
>>>>
>>>> Minor formatting nit on L472 where the "throws IOException" doesn't 
>>>> need to be on its own line.
>>>>
>>>> -Alan
>>>>
>>>>
>>>>
>>>
>>> <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>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/c3b6dab8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/c3b6dab8/oracle_sig_logo.gif>

From brian.burkhalter at oracle.com  Thu May  2 15:03:49 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 May 2019 08:03:49 -0700
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
 <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
 <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>
Message-ID: <93D15761-30C7-42E6-8D06-D3515E5D2ECE@oracle.com>


> On May 1, 2019, at 11:20 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> I think the test should skip if TestUtil.supportsLinks returns false as otherwise it will fail on Windows machines when the user doesn't have the appropriate privileges.

Something like this?:

--- a/test/jdk/java/nio/file/Files/SymlinkTime.java
+++ b/test/jdk/java/nio/file/Files/SymlinkTime.java
@@ -41,6 +41,12 @@
 public class SymlinkTime {
     public static void main(String[] args) throws IOException {
         Path dir = TestUtil.createTemporaryDirectory();
+        if (System.getProperty("os.name").startsWith("Windows") &&
+            !TestUtil.supportsLinks(dir)) {
+            System.out.println("Windows: links not supported - skipping test");
+            return;
+        }
+
         try {
             // Create file and symbolic link to it
             final Path file = dir.resolve("file");

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/14115f31/attachment-0001.html>

From Alan.Bateman at oracle.com  Thu May  2 15:10:43 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 May 2019 16:10:43 +0100
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <93D15761-30C7-42E6-8D06-D3515E5D2ECE@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
 <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
 <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>
 <93D15761-30C7-42E6-8D06-D3515E5D2ECE@oracle.com>
Message-ID: <7993a492-3843-88b3-146e-24117eb5f819@oracle.com>

On 02/05/2019 16:03, Brian Burkhalter wrote:
>
> --- a/test/jdk/java/nio/file/Files/SymlinkTime.java
> +++ b/test/jdk/java/nio/file/Files/SymlinkTime.java
> @@ -41,6 +41,12 @@
> ?public class SymlinkTime {
> ? public static void main(String[] args) throws IOException {
> ? ? ? Path dir = TestUtil.createTemporaryDirectory();
> + ? ? ? if (System.getProperty("os.name").startsWith("Windows") &&
> + ? ? ? ? ? !TestUtil.supportsLinks(dir)) {
> + ? ? ? ? ? System.out.println("Windows: links not supported - 
> skipping test");
> + ? ? ? ? ? return;
> + ? ? ? }
> +
>
Yes but no need to check os.name. You'll see examples in other tests.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/b0208ec3/attachment.html>

From brian.burkhalter at oracle.com  Thu May  2 15:21:21 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 May 2019 08:21:21 -0700
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <7993a492-3843-88b3-146e-24117eb5f819@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
 <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
 <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>
 <93D15761-30C7-42E6-8D06-D3515E5D2ECE@oracle.com>
 <7993a492-3843-88b3-146e-24117eb5f819@oracle.com>
Message-ID: <F0D5B3AD-9CA3-48C6-8FD4-AD7374257E36@oracle.com>


> On May 2, 2019, at 8:10 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> Yes but no need to check os.name. You'll see examples in other tests.

I was wondering about that. Changed:

--- a/test/jdk/java/nio/file/Files/SymlinkTime.java
+++ b/test/jdk/java/nio/file/Files/SymlinkTime.java
@@ -41,6 +41,11 @@
 public class SymlinkTime {
     public static void main(String[] args) throws IOException {
         Path dir = TestUtil.createTemporaryDirectory();
+        if (!TestUtil.supportsLinks(dir)) {
+            System.out.println("Links not supported: skipping test");
+            return;
+        }
+

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/57a470ec/attachment.html>

From Roger.Riggs at oracle.com  Thu May  2 15:23:21 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 2 May 2019 11:23:21 -0400
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <7993a492-3843-88b3-146e-24117eb5f819@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
 <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
 <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>
 <93D15761-30C7-42E6-8D06-D3515E5D2ECE@oracle.com>
 <7993a492-3843-88b3-146e-24117eb5f819@oracle.com>
Message-ID: <1e743bd9-0c19-e09d-13bb-4761f8066ed8@oracle.com>

Hi,

How about throwing the SkippedException so it shows up in the jtreg 
summaries as such. [1]

Roger

[1] 
http://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation


On 05/02/2019 11:10 AM, Alan Bateman wrote:
> On 02/05/2019 16:03, Brian Burkhalter wrote:
>>
>> --- a/test/jdk/java/nio/file/Files/SymlinkTime.java
>> +++ b/test/jdk/java/nio/file/Files/SymlinkTime.java
>> @@ -41,6 +41,12 @@
>> ?public class SymlinkTime {
>> ?? ? public static void main(String[] args) throws IOException {
>> ?? ? ? ? Path dir = TestUtil.createTemporaryDirectory();
>> +? ? ? ? if (System.getProperty("os.name").startsWith("Windows") &&
>> +? ? ? ? ? ? !TestUtil.supportsLinks(dir)) {
>> +? ? ? ? ? ? System.out.println("Windows: links not supported - 
>> skipping test");
>> +? ? ? ? ? ? return;
>> +? ? ? ? }
>> +
>>
> Yes but no need to check os.name. You'll see examples in other tests.
>
> -Alan


From lance.andersen at oracle.com  Thu May  2 15:26:51 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 2 May 2019 11:26:51 -0400
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <bfa673f5-b23c-0d16-b208-208bded9e7fb@oracle.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
 <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
 <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
 <3222bdd5-9722-354f-d705-68a5b72c6ae8@oracle.com>
 <5208506C-CC86-4A30-9D8F-F3D437CF3D38@oracle.com>
 <bfa673f5-b23c-0d16-b208-208bded9e7fb@oracle.com>
Message-ID: <A1B69A5F-B933-4FCD-866E-174CA9AAD9CD@oracle.com>

Hi Roger,

> On May 2, 2019, at 10:27 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
>>> 
>>> Wildcard imports are discouraged (in the new test).
>> 
>> I thought I ran optimize imports in Intellij, but I can go back and do this.  Thank you for catching this
> It depends on your Intellij configuration.  It can do many variations.  :)
> See Editor -> Code Style -> Java and check "Use single class import?

Thank you.  I had set that but it must have been after I originally wrote the test.
>>> 
>>> Test method names that are indicative of the function being tested can be helpful when
>>> reading a test log, it communicates a bit sooner what has gone wrong without having to read
>>> the test javadoc.
>> 
>> Well, i can change them if you prefer.  Looking at the other tests in zipfs (ZipfsTester and in some of the other test areas, they are not very informative either
>> 
>> I tried to put a useful comment as to what the test does, but I will defer to your preference 
> I think its best practice to use useful names.
> Future maintainers will appreciate it.

Okie dokie :-)

The updated webrev is here: http://cr.openjdk.java.net/~lancea/8218875/webrev.04/index.html <http://cr.openjdk.java.net/~lancea/8218875/webrev.04/index.html>

I am re-running the mach5 tests as well to make sure there are no hiccups with the name change.  They ran fine on my Mac

Thank you again.

Best
Lance

> 
> Thanks, Roger
> 
>> 
>> Best
>> Lance
>>> 
>>> Thanks, Roger
>>> 
>>> On 05/02/2019 08:52 AM, Lance Andersen wrote:
>>>> Thank you Alan for catching the missing ?method?
>>>> 
>>>> http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.03/index.html><http://cr.openjdk.java.net/%7Elancea/8218875/webrev.03/index.html <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.03/index.html>> contains your suggested updates mentioned below
>>>> 
>>>> Best
>>>> Lance
>>>>> On May 2, 2019, at 3:40 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com> <mailto:Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>> wrote:
>>>>> 
>>>>> On 01/05/2019 20:29, Lance Andersen wrote:
>>>>>> Coming back to this.
>>>>>> 
>>>>>> The updated webrev can be found at:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~lancea/8218875/webrev.02/index.html <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.02/index.html><http://cr.openjdk.java.net/%7Elancea/8218875/webrev.02/index.html <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.02/index.html>>
>>>>>> 
>>>>> I only have time to look at the changes to FileSystems.java right now.
>>>>> 
>>>>> One nit in the wording is in "in exactly the same manner as the newFileSystem ..."  - the word "method" has been dropped from the original text. Looks like the same thing shows up in several places so it would be good to fix those.
>>>>> 
>>>>> Minor formatting nit on L472 where the "throws IOException" doesn't need to be on its own line.
>>>>> 
>>>>> -Alan
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>><http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering
>>>> 1 Network Drive
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>> 
>> 
>> 
> 

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/1f28a07a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/1f28a07a/oracle_sig_logo-0001.gif>

From Alan.Bateman at oracle.com  Thu May  2 15:30:19 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 May 2019 16:30:19 +0100
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <F0D5B3AD-9CA3-48C6-8FD4-AD7374257E36@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
 <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
 <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>
 <93D15761-30C7-42E6-8D06-D3515E5D2ECE@oracle.com>
 <7993a492-3843-88b3-146e-24117eb5f819@oracle.com>
 <F0D5B3AD-9CA3-48C6-8FD4-AD7374257E36@oracle.com>
Message-ID: <c483832b-34b7-f779-95c6-ffb069577818@oracle.com>

On 02/05/2019 16:21, Brian Burkhalter wrote
> I was wondering about that. Changed:
>
> --- a/test/jdk/java/nio/file/Files/SymlinkTime.java
> +++ b/test/jdk/java/nio/file/Files/SymlinkTime.java
> @@ -41,6 +41,11 @@
> ?public class SymlinkTime {
> ? public static void main(String[] args) throws IOException {
> ? ? ? Path dir = TestUtil.createTemporaryDirectory();
> + ? ? ? if (!TestUtil.supportsLinks(dir)) {
> + ? ? ? ? ? System.out.println("Links not supported: skipping test");
> + ? ? ? ? ? return;
> + ? ? ? }
> +
>
It's in the same thing in other tests so I think this is fine.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/b44c5450/attachment.html>

From Roger.Riggs at oracle.com  Thu May  2 15:37:27 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 2 May 2019 11:37:27 -0400
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <A1B69A5F-B933-4FCD-866E-174CA9AAD9CD@oracle.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
 <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
 <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
 <3222bdd5-9722-354f-d705-68a5b72c6ae8@oracle.com>
 <5208506C-CC86-4A30-9D8F-F3D437CF3D38@oracle.com>
 <bfa673f5-b23c-0d16-b208-208bded9e7fb@oracle.com>
 <A1B69A5F-B933-4FCD-866E-174CA9AAD9CD@oracle.com>
Message-ID: <ba7dd8e0-c80d-8c94-fd19-e10114ed710d@oracle.com>

Thanks Lance, Looks good.


On 05/02/2019 11:26 AM, Lance Andersen wrote:
> Hi Roger,
>
>> On May 2, 2019, at 10:27 AM, Roger Riggs <Roger.Riggs at oracle.com 
>> <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>>>>
>>>> Wildcard imports are d
>>>> @Test
>>>> iscouraged (in the new test).
>>>
>>> I thought I ran optimize imports in Intellij, but I can go back and 
>>> do this. ?Thank you for catching this
>> It depends on your Intellij configuration.? It can do many 
>> variations.? :)
>> See Editor -> Code Style -> Java and check "Use single class import?
>
> Thank you. ?I had set that but it must have been after I originally 
> wrote the test.
>>>>
>>>> Test method names that are indicative of the function being tested 
>>>> can be helpful when
>>>> reading a test log, it communicates a bit sooner what has gone 
>>>> wrong without having to read
>>>> the test javadoc.
>>>
>>> Well, i can change them if you prefer. ?Looking at the other tests 
>>> in zipfs (ZipfsTester and in some of the other test areas, they are 
>>> not very informative either
>>>
>>> I tried to put a useful comment as to what the test does, but I will 
>>> defer to your preference
>> I think its best practice to use useful names.
>> Future maintainers will appreciate it.
>
> Okie dokie :-)
>
> The updated webrev is here: 
> http://cr.openjdk.java.net/~lancea/8218875/webrev.04/index.html 
> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.04/index.html>
>
> I am re-running the mach5 tests as well to make sure there are no 
> hiccups with the name change. ?They ran fine on my Mac
>
> Thank you again.
>
> Best
> Lance
>
>>
>> Thanks, Roger
>>
>>>
>>> Best
>>> Lance
>>>>
>>>> Thanks, Roger
>>>>
>>>> On 05/02/2019 08:52 AM, Lance Andersen wrote:
>>>>> Thank you Alan for catching the missing ?method?
>>>>>
>>>>> http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html 
>>>>> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.03/index.html> 
>>>>> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.03/index.html>?contains 
>>>>> your suggested updates mentioned below
>>>>>
>>>>> Best
>>>>> Lance
>>>>>> On May 2, 2019, at 3:40 AM, Alan Bateman <Alan.Bateman at oracle.com 
>>>>>> <mailto:Alan.Bateman at oracle.com> 
>>>>>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>>>>>
>>>>>> On 01/05/2019 20:29, Lance Andersen wrote:
>>>>>>> Coming back to this.
>>>>>>>
>>>>>>> The updated webrev can be found at:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~lancea/8218875/webrev.02/index.html 
>>>>>>> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.02/index.html> 
>>>>>>> <http://cr.openjdk.java.net/%7Elancea/8218875/webrev.02/index.html>
>>>>>>>
>>>>>> I only have time to look at the changes to FileSystems.java right 
>>>>>> now.
>>>>>>
>>>>>> One nit in the wording is in "in exactly the same manner as the 
>>>>>> newFileSystem ..."? - the word "method" has been dropped from the 
>>>>>> original text. Looks like the same thing shows up in several 
>>>>>> places so it would be good to fix those.
>>>>>>
>>>>>> Minor formatting nit on L472 where the "throws IOException" 
>>>>>> doesn't need to be on its own line.
>>>>>>
>>>>>> -Alan
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> <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>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> <oracle_sig_logo.gif> 
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle?Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>
>>
>
> <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>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/1ae4a71b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/1ae4a71b/oracle_sig_logo-0001.gif>

From brian.burkhalter at oracle.com  Thu May  2 15:39:04 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 May 2019 08:39:04 -0700
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <1e743bd9-0c19-e09d-13bb-4761f8066ed8@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
 <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
 <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>
 <93D15761-30C7-42E6-8D06-D3515E5D2ECE@oracle.com>
 <7993a492-3843-88b3-146e-24117eb5f819@oracle.com>
 <1e743bd9-0c19-e09d-13bb-4761f8066ed8@oracle.com>
Message-ID: <B5F66F76-06B5-4D77-8F7A-5CD3DDF4A1FF@oracle.com>

Hi,

> On May 2, 2019, at 8:23 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> How about throwing the SkippedException so it shows up in the jtreg summaries as such. [1]

Good idea.

Thanks,

Brian

--- a/test/jdk/java/nio/file/Files/SymlinkTime.java
+++ b/test/jdk/java/nio/file/Files/SymlinkTime.java
@@ -26,6 +26,7 @@
  * @summary Unit test for updating access and modification times of symlinks
  * @requires (os.family == "linux" | os.family == "mac" | os.family == "windows")
  * @library ..
+ * @library /test/lib
  * @build SymlinkTime
  * @run main/othervm SymlinkTime
  */
@@ -38,9 +39,14 @@
 import java.nio.file.attribute.BasicFileAttributeView;
 import java.nio.file.attribute.FileTime;
 
+import jtreg.SkippedException;
+
 public class SymlinkTime {
     public static void main(String[] args) throws IOException {
         Path dir = TestUtil.createTemporaryDirectory();
+        if (!TestUtil.supportsLinks(dir))
+            throw new SkippedException("Links not supported: skipping test");
+

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/af30c1ed/attachment.html>

From Alan.Bateman at oracle.com  Thu May  2 15:41:11 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 May 2019 16:41:11 +0100
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
 <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
 <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
Message-ID: <80367c3b-826c-f5d5-257f-ce03a193f311@oracle.com>

On 02/05/2019 13:52, Lance Andersen wrote:
> Thank you Alan for catching the missing ?method?
>
> http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html?contains 
> your suggested updates mentioned below
>
Thanks, the javadoc looks good now. There's still one stray "{" at L473 
that belongs on the previous line, otherwise looks fine.

-Alan

From Roger.Riggs at oracle.com  Thu May  2 15:47:08 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 2 May 2019 11:47:08 -0400
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <B5F66F76-06B5-4D77-8F7A-5CD3DDF4A1FF@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
 <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
 <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>
 <93D15761-30C7-42E6-8D06-D3515E5D2ECE@oracle.com>
 <7993a492-3843-88b3-146e-24117eb5f819@oracle.com>
 <1e743bd9-0c19-e09d-13bb-4761f8066ed8@oracle.com>
 <B5F66F76-06B5-4D77-8F7A-5CD3DDF4A1FF@oracle.com>
Message-ID: <fa04b6dd-fce1-55d7-4695-f8b6dcaaba4c@oracle.com>

Looks good.

Thanks, Roger

On 05/02/2019 11:39 AM, Brian Burkhalter wrote:
> Hi,
>
>> On May 2, 2019, at 8:23 AM, Roger Riggs <Roger.Riggs at oracle.com 
>> <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>> How about throwing the SkippedException so it shows up in the jtreg 
>> summaries as such. [1]
>
> Good idea.
>
> Thanks,
>
> Brian
>
> --- a/test/jdk/java/nio/file/Files/SymlinkTime.java
> +++ b/test/jdk/java/nio/file/Files/SymlinkTime.java
> @@ -26,6 +26,7 @@
> * @summary Unit test for updating access and modification times of 
> symlinks
> * @requires (os.family == "linux" | os.family == "mac" | os.family == 
> "windows")
> * @library ..
> + * @library /test/lib
> * @build SymlinkTime
> * @run main/othervm SymlinkTime
> */
> @@ -38,9 +39,14 @@
> ?import java.nio.file.attribute.BasicFileAttributeView;
> ?import java.nio.file.attribute.FileTime;
>
>
> +import jtreg.SkippedException;
> +
> ?public class SymlinkTime {
> ? public static void main(String[] args) throws IOException {
> ? ? ? Path dir = TestUtil.createTemporaryDirectory();
> + ? ? ? if (!TestUtil.supportsLinks(dir))
> + ? ? ? ? ? throw new SkippedException("Links not supported: skipping 
> test");
> +
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/c0a9f40a/attachment-0001.html>

From lance.andersen at oracle.com  Thu May  2 15:57:06 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 2 May 2019 11:57:06 -0400
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <80367c3b-826c-f5d5-257f-ce03a193f311@oracle.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
 <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
 <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
 <80367c3b-826c-f5d5-257f-ce03a193f311@oracle.com>
Message-ID: <CF66CE5A-9B38-491B-9E72-048BD60C8184@oracle.com>


> On May 2, 2019, at 11:41 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 02/05/2019 13:52, Lance Andersen wrote:
>> Thank you Alan for catching the missing ?method?
>> 
>> http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html contains your suggested updates mentioned below
>> 
> Thanks, the javadoc looks good now. There's still one stray "{" at L473 that belongs on the previous line, otherwise looks fine.
> 
Sorry about that missing that

Addressed here: http://cr.openjdk.java.net/~lancea/8218875/webrev.05/index.html <http://cr.openjdk.java.net/~lancea/8218875/webrev.05/index.html>

Best
Lance
> -Alan

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/a3a77b0c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/a3a77b0c/oracle_sig_logo.gif>

From jan.schloessin at incasoft.de  Thu May  2 16:34:59 2019
From: jan.schloessin at incasoft.de (=?UTF-8?B?SmFuIFNjaGzDtsOfaW4=?=)
Date: Thu, 2 May 2019 18:34:59 +0200
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <F0D5B3AD-9CA3-48C6-8FD4-AD7374257E36@oracle.com>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
 <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
 <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>
 <93D15761-30C7-42E6-8D06-D3515E5D2ECE@oracle.com>
 <7993a492-3843-88b3-146e-24117eb5f819@oracle.com>
 <F0D5B3AD-9CA3-48C6-8FD4-AD7374257E36@oracle.com>
Message-ID: <69e66a5a-4c81-37a8-e3f2-e28b21f2a1f7@incasoft.de>

Hi,

it's a bit off topic. But do you guys have in mind, that windows
supports symlinks, too? Since "Windows 10 build 14972" you can create
them without being admin.

  https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/

Thanks,
Jan

Brian Burkhalter schrieb:
> 
>> On May 2, 2019, at 8:10 AM, Alan Bateman <Alan.Bateman at oracle.com
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>> Yes but no need to check os.name. You'll see examples in other tests.
> 
> I was wondering about that. Changed:
> 
> --- a/test/jdk/java/nio/file/Files/SymlinkTime.java
> +++ b/test/jdk/java/nio/file/Files/SymlinkTime.java
> @@ -41,6 +41,11 @@
> ?public class SymlinkTime {
> ?? ? public static void main(String[] args) throws IOException {
> ?? ? ? ? Path dir = TestUtil.createTemporaryDirectory();
> +? ? ? ? if (!TestUtil.supportsLinks(dir)) {
> +? ? ? ? ? ? System.out.println("Links not supported: skipping test");
> +? ? ? ? ? ? return;
> +? ? ? ? }
> +
> 
> Thanks,
> 
> Brian


From brian.burkhalter at oracle.com  Thu May  2 16:37:59 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 May 2019 09:37:59 -0700
Subject: 8220793: (fs) No support for changing modification time of symlink
In-Reply-To: <69e66a5a-4c81-37a8-e3f2-e28b21f2a1f7@incasoft.de>
References: <94054704-7CD6-4FE8-BE86-D17145C06E97@oracle.com>
 <6044b47b-74ff-1679-6b83-8cc1d71bcc39@oracle.com>
 <DBA1C302-08FB-4FD0-8BF7-2ABB348E27A5@oracle.com>
 <AC8F0B4E-65FD-4B30-A267-3653A73B6774@oracle.com>
 <fcef6dd9-ab59-2d70-f577-49cf9df11f8f@oracle.com>
 <20A4042B-4836-4928-921D-7021C02C83D3@oracle.com>
 <C16E2A3C-183F-46FA-BA61-5D2B9A760DCE@oracle.com>
 <df15f078-4676-ba94-5419-ebc887509d85@oracle.com>
 <E2D54514-BCC9-4B4C-9B71-797CA2F7028D@oracle.com>
 <66f085a2-40b6-18aa-1a02-455f80568ccb@oracle.com>
 <93D15761-30C7-42E6-8D06-D3515E5D2ECE@oracle.com>
 <7993a492-3843-88b3-146e-24117eb5f819@oracle.com>
 <F0D5B3AD-9CA3-48C6-8FD4-AD7374257E36@oracle.com>
 <69e66a5a-4c81-37a8-e3f2-e28b21f2a1f7@incasoft.de>
Message-ID: <9C124D1A-370A-4713-AB91-628401B542BB@oracle.com>

Hi,

Yes, we know about Developer Mode. Please see this thread:

http://mail.openjdk.java.net/pipermail/nio-dev/2019-April/005990.html

Thanks,

Brian

> On May 2, 2019, at 9:34 AM, Jan Schl??in <jan.schloessin at incasoft.de> wrote:
> 
> 
> it's a bit off topic. But do you guys have in mind, that windows
> supports symlinks, too? Since "Windows 10 build 14972" you can create
> them without being admin.
> 
>  https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/ <https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/30ad72d1/attachment-0001.html>

From christoph.langer at sap.com  Thu May  2 20:28:46 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 2 May 2019 20:28:46 +0000
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <CF66CE5A-9B38-491B-9E72-048BD60C8184@oracle.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
 <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
 <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
 <80367c3b-826c-f5d5-257f-ce03a193f311@oracle.com>
 <CF66CE5A-9B38-491B-9E72-048BD60C8184@oracle.com>
Message-ID: <AM6PR02MB5192A1C72B664A5F84385E598A340@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Lance,

looks good to me, too.

A little nit in the test: line 173 should be:
Map<String, ?> nullMap = null;

Also you could remove the blank lines 87, 102, and 116 for consistency and declare the variable ZIPFS_SCHEME as private in line 52. But that?s bikeshedding ??

Best regards
Christoph


From: nio-dev <nio-dev-bounces at openjdk.java.net> On Behalf Of Lance Andersen
Sent: Donnerstag, 2. Mai 2019 17:57
To: Alan Bateman <Alan.Bateman at oracle.com>
Cc: nio-dev at openjdk.java.net
Subject: Re: RFR 8218875: Add new FileSystems.newFileSystem methods


On May 2, 2019, at 11:41 AM, Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>> wrote:

On 02/05/2019 13:52, Lance Andersen wrote:

Thank you Alan for catching the missing ?method?

http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html contains your suggested updates mentioned below
Thanks, the javadoc looks good now. There's still one stray "{" at L473 that belongs on the previous line, otherwise looks fine.
Sorry about that missing that

Addressed here: http://cr.openjdk.java.net/~lancea/8218875/webrev.05/index.html

Best
Lance
-Alan

[cid:image001.gif at 01D50136.6771A320]<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>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/9a8325d3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 658 bytes
Desc: image001.gif
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/9a8325d3/image001.gif>

From lance.andersen at oracle.com  Thu May  2 21:10:07 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 2 May 2019 17:10:07 -0400
Subject: RFR 8218875: Add new FileSystems.newFileSystem methods
In-Reply-To: <AM6PR02MB5192A1C72B664A5F84385E598A340@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <828154C3-7D00-4517-B0DD-A8203E087459@oracle.com>
 <d822bc35-a4db-d1f0-0309-463a2537d0cc@oracle.com>
 <9f9975a1c3bd47898d15cdeef75a5060@sap.com>
 <BD8C7671-3023-4ED2-B00B-8A7639476C38@oracle.com>
 <c3bddb3560004b53947dfc9f8935549f@sap.com>
 <3c8533bc-65ad-ed12-cee1-d1591eb422ae@oracle.com>
 <94D3CB5C-36D6-4CE4-8918-8B0E2079039F@oracle.com>
 <3f19ba19a06a4f539fc3a620e62725a2@sap.com>
 <EADC44AD-D737-4703-AC90-07AB9F90B502@oracle.com>
 <11ab28ba-a8d8-2f3e-8576-3441dd0b7cb6@oracle.com>
 <95EED826-6A67-4145-81DB-E165E3C90B65@oracle.com>
 <80367c3b-826c-f5d5-257f-ce03a193f311@oracle.com>
 <CF66CE5A-9B38-491B-9E72-048BD60C8184@oracle.com>
 <AM6PR02MB5192A1C72B664A5F84385E598A340@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <9F856200-0304-4988-96CC-71070CB8D537@oracle.com>

Hi Christoph,

Thank you for the review

I made the suggested changes below and tested locally before pushing.

Best
Lance
> On May 2, 2019, at 4:28 PM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Lance,
>  
> looks good to me, too.
>  
> A little nit in the test: line 173 should be:
> Map<String, ?> nullMap = null;
>  
> Also you could remove the blank lines 87, 102, and 116 for consistency and declare the variable ZIPFS_SCHEME as private in line 52. But that?s bikeshedding ??
>  
> Best regards
> Christoph
>  
>  
> From: nio-dev <nio-dev-bounces at openjdk.java.net <mailto:nio-dev-bounces at openjdk.java.net>> On Behalf Of Lance Andersen
> Sent: Donnerstag, 2. Mai 2019 17:57
> To: Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>>
> Cc: nio-dev at openjdk.java.net <mailto:nio-dev at openjdk.java.net>
> Subject: Re: RFR 8218875: Add new FileSystems.newFileSystem methods
>  
>  
> On May 2, 2019, at 11:41 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>  
> On 02/05/2019 13:52, Lance Andersen wrote:
> 
> Thank you Alan for catching the missing ?method?
> 
> http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html <http://cr.openjdk.java.net/~lancea/8218875/webrev.03/index.html> contains your suggested updates mentioned below
> 
> Thanks, the javadoc looks good now. There's still one stray "{" at L473 that belongs on the previous line, otherwise looks fine.
> 
> Sorry about that missing that
>  
> Addressed here: http://cr.openjdk.java.net/~lancea/8218875/webrev.05/index.html <http://cr.openjdk.java.net/~lancea/8218875/webrev.05/index.html>
>  
> Best
> Lance
> -Alan
>  
> <image001.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>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/0b1ff774/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190502/0b1ff774/oracle_sig_logo-0001.gif>

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 Alan.Bateman at oracle.com  Sun May  5 19:00:05 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 5 May 2019 20:00:05 +0100
Subject: 8223353: (ch) Change channel close implementation to not wait for I/O
 threads
Message-ID: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>

I'd like to refactor the SelectableChannel close implementations so that 
the close methods don't wait for I/O operations to abort when closing a 
channel in blocking mode.

As I'm sure we all know here, closing a channel is complicated because 
it requires coordinating with threads doing I/O operations. It also 
requires coordinating with selection operations as the channel may be 
registered with one or more Selectors. As things currently stand, 
closing a channel in blocking mode with threads blocked in I/O 
operations involves:

1. pre-close (the dup2 trick to close the connection but not release the 
file descriptor)
2. signal the threads in blocking I/O operations so that they abort with 
EINTR
3. wait for the threads to complete/abort the I/O operation
4. close the file descriptor (if not registered with a Selector - not 
usually possible with channels configured in blocking mode but there are 
convoluted scenarios to consider).

For comparison, the non-blocking case is a simple lock/unlock to ensure 
that all I/O operations have completed and then closing the file 
descriptor when not registered with a Selector. If registered with a 
Selector then the close is deferred until its key is flushed from the 
last Selector that it is registered with.

The proposed change is to eliminate #3 above and have the last I/O 
operation to complete do the final close. This simplifies the close nd 
means that I/O operation in progress and registered with Selector cases 
are handled consistently. The change should not be observable to code 
using these APIs as the pre-close will close the connection as before.

One benefit of the change is that is Thread.interrupt doesn't wait. A 
second benefit is that we move stateLock in the implementations back to 
being a built-in monitor, the condition object used to await/signal, 
goes away.

The webrev with the proposed changes is here. The changes to stateLock 
are purely mechanical, everything else is the refactor of the 
implCloseSelectableChannel implementations.

http://cr.openjdk.java.net/~alanb/8223353/0/webrev/

-Alan

From fweimer at redhat.com  Mon May  6 09:57:24 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 06 May 2019 11:57:24 +0200
Subject: 8223353: (ch) Change channel close implementation to not wait for
 I/O threads
In-Reply-To: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com> (Alan Bateman's
 message of "Sun, 5 May 2019 20:00:05 +0100")
References: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>
Message-ID: <87lfzjgb23.fsf@oldenburg2.str.redhat.com>

* Alan Bateman:

> 1. pre-close (the dup2 trick to close the connection but not release
> the file descriptor)
> 2. signal the threads in blocking I/O operations so that they abort
> with EINTR
> 3. wait for the threads to complete/abort the I/O operation
> 4. close the file descriptor (if not registered with a Selector - not
> usually possible with channels configured in blocking mode but there
> are convoluted scenarios to consider).

> The proposed change is to eliminate #3 above and have the last I/O
> operation to complete do the final close. This simplifies the close nd
> means that I/O operation in progress and registered with Selector
> cases are handled consistently. The change should not be observable to
> code using these APIs as the pre-close will close the connection as
> before.

What about resource consumption?

I think without #3, an application will have to synchronize with the
threads performing I/O on the channel being closed before it can safely
create a new channel, to ensure that the actual close (and resource
deallocation) happens before the creation of the new channel.

Based on your description of the current behavior, it should be possible
to create a new channel immediately after closing the old one because
the close call only returns after the scarce resource (the file
descriptor) has been deallocated.  I'm pretty sure this predictable
behavior would be lost.

Thanks,
Florian

From Alan.Bateman at oracle.com  Mon May  6 12:05:31 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 6 May 2019 13:05:31 +0100
Subject: 8223353: (ch) Change channel close implementation to not wait for
 I/O threads
In-Reply-To: <87lfzjgb23.fsf@oldenburg2.str.redhat.com>
References: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>
 <87lfzjgb23.fsf@oldenburg2.str.redhat.com>
Message-ID: <c92037da-7730-0ee4-a25e-034eba397982@oracle.com>

On 06/05/2019 10:57, Florian Weimer wrote:
> :
> What about resource consumption?
>
> I think without #3, an application will have to synchronize with the
> threads performing I/O on the channel being closed before it can safely
> create a new channel, to ensure that the actual close (and resource
> deallocation) happens before the creation of the new channel.
>
> Based on your description of the current behavior, it should be possible
> to create a new channel immediately after closing the old one because
> the close call only returns after the scarce resource (the file
> descriptor) has been deallocated.  I'm pretty sure this predictable
> behavior would be lost.
>
The socket/connection is closed at step #1, it's only the final release 
of the file descriptor (connected to one of a pipe) that is delayed.

-Alan

From fweimer at redhat.com  Mon May  6 12:18:12 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 06 May 2019 14:18:12 +0200
Subject: 8223353: (ch) Change channel close implementation to not wait for
 I/O threads
In-Reply-To: <c92037da-7730-0ee4-a25e-034eba397982@oracle.com> (Alan Bateman's
 message of "Mon, 6 May 2019 13:05:31 +0100")
References: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>
 <87lfzjgb23.fsf@oldenburg2.str.redhat.com>
 <c92037da-7730-0ee4-a25e-034eba397982@oracle.com>
Message-ID: <87ef5bepyz.fsf@oldenburg2.str.redhat.com>

* Alan Bateman:

> On 06/05/2019 10:57, Florian Weimer wrote:
>> :
>> What about resource consumption?
>>
>> I think without #3, an application will have to synchronize with the
>> threads performing I/O on the channel being closed before it can safely
>> create a new channel, to ensure that the actual close (and resource
>> deallocation) happens before the creation of the new channel.
>>
>> Based on your description of the current behavior, it should be possible
>> to create a new channel immediately after closing the old one because
>> the close call only returns after the scarce resource (the file
>> descriptor) has been deallocated.  I'm pretty sure this predictable
>> behavior would be lost.
>>
> The socket/connection is closed at step #1, it's only the final
> release of the file descriptor (connected to one of a pipe) that is
> delayed.

But that descriptor consumes a slot in the descriptor table, which is an
extremely scarce resource.  It does not matter that the file description
used magic I/O inhibition is shared and therefore consumes very little
kernel resources.  The original file descriptor is still occupied until
the lazy close completes and cannot be reused for creating new channels.

Thanks,
Florian

From Alan.Bateman at oracle.com  Mon May  6 12:22:45 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 6 May 2019 13:22:45 +0100
Subject: 8223353: (ch) Change channel close implementation to not wait for
 I/O threads
In-Reply-To: <87ef5bepyz.fsf@oldenburg2.str.redhat.com>
References: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>
 <87lfzjgb23.fsf@oldenburg2.str.redhat.com>
 <c92037da-7730-0ee4-a25e-034eba397982@oracle.com>
 <87ef5bepyz.fsf@oldenburg2.str.redhat.com>
Message-ID: <63694db1-703c-3ac8-f392-8faa03065378@oracle.com>

On 06/05/2019 13:18, Florian Weimer wrote:
> :
> But that descriptor consumes a slot in the descriptor table, which is an
> extremely scarce resource.  It does not matter that the file description
> used magic I/O inhibition is shared and therefore consumes very little
> kernel resources.  The original file descriptor is still occupied until
> the lazy close completes and cannot be reused for creating new channels.
>
Sure, but that is exactly how it works since JDK 1.4. If you have a JDK 
8 build handy you can trace the syscalls and see what I mean. It's 
exactly the same with classic networking too (also since JDK 1.4).

-Alan

From daniel.fuchs at oracle.com  Tue May  7 11:56:41 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 7 May 2019 12:56:41 +0100
Subject: 8223353: (ch) Change channel close implementation to not wait for
 I/O threads
In-Reply-To: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>
References: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>
Message-ID: <d0eafa1a-83c7-4680-5e16-3e748995ff78@oracle.com>

Hi Alan,

The changes seem reasonable to me. It looks like a nice
simplification. I guess the JIRA issue will need a noreg-cleanup
label. I assume you have verified that the tests have remained
stable?

best regards,

-- daniel

On 05/05/2019 20:00, Alan Bateman wrote:
> I'd like to refactor the SelectableChannel close implementations so that 
> the close methods don't wait for I/O operations to abort when closing a 
> channel in blocking mode.
> 
> As I'm sure we all know here, closing a channel is complicated because 
> it requires coordinating with threads doing I/O operations. It also 
> requires coordinating with selection operations as the channel may be 
> registered with one or more Selectors. As things currently stand, 
> closing a channel in blocking mode with threads blocked in I/O 
> operations involves:
> 
> 1. pre-close (the dup2 trick to close the connection but not release the 
> file descriptor)
> 2. signal the threads in blocking I/O operations so that they abort with 
> EINTR
> 3. wait for the threads to complete/abort the I/O operation
> 4. close the file descriptor (if not registered with a Selector - not 
> usually possible with channels configured in blocking mode but there are 
> convoluted scenarios to consider).
> 
> For comparison, the non-blocking case is a simple lock/unlock to ensure 
> that all I/O operations have completed and then closing the file 
> descriptor when not registered with a Selector. If registered with a 
> Selector then the close is deferred until its key is flushed from the 
> last Selector that it is registered with.
> 
> The proposed change is to eliminate #3 above and have the last I/O 
> operation to complete do the final close. This simplifies the close nd 
> means that I/O operation in progress and registered with Selector cases 
> are handled consistently. The change should not be observable to code 
> using these APIs as the pre-close will close the connection as before.
> 
> One benefit of the change is that is Thread.interrupt doesn't wait. A 
> second benefit is that we move stateLock in the implementations back to 
> being a built-in monitor, the condition object used to await/signal, 
> goes away.
> 
> The webrev with the proposed changes is here. The changes to stateLock 
> are purely mechanical, everything else is the refactor of the 
> implCloseSelectableChannel implementations.
> 
> http://cr.openjdk.java.net/~alanb/8223353/0/webrev/
> 
> -Alan


From chris.hegarty at oracle.com  Tue May  7 13:35:55 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 7 May 2019 14:35:55 +0100
Subject: 8223353: (ch) Change channel close implementation to not wait for
 I/O threads
In-Reply-To: <63694db1-703c-3ac8-f392-8faa03065378@oracle.com>
References: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>
 <87lfzjgb23.fsf@oldenburg2.str.redhat.com>
 <c92037da-7730-0ee4-a25e-034eba397982@oracle.com>
 <87ef5bepyz.fsf@oldenburg2.str.redhat.com>
 <63694db1-703c-3ac8-f392-8faa03065378@oracle.com>
Message-ID: <CE1DE4D1-55B9-4766-8968-293EBAA02363@oracle.com>


> On 6 May 2019, at 13:22, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 06/05/2019 13:18, Florian Weimer wrote:
>> :
>> But that descriptor consumes a slot in the descriptor table, which is an
>> extremely scarce resource.  It does not matter that the file description
>> used magic I/O inhibition is shared and therefore consumes very little
>> kernel resources.  The original file descriptor is still occupied until
>> the lazy close completes and cannot be reused for creating new channels.
>> 
> Sure, but that is exactly how it works since JDK 1.4. If you have a JDK 8 build handy you can trace the syscalls and see what I mean. It's exactly the same with classic networking too (also since JDK 1.4).

The changes to convert the stateLock back to using the built-in monitor
of a private Object seem ok ( from what I can tell the changes seem to
accurately anti-delta part of what was done in 8222774 [1] )

I'm trying to piece this together the other aspect of this change,
close not waiting on I/O threads. To help better understand the change
in behaviour, was it the changes for (8198562 & 8198754) [2], in
Java 11, that resulted in socket channel `close` waiting on I/O threads
to complete? Or something else ( I could be wrong as the code in this
area has changed a few times ).

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8222774
[2] https://hg.openjdk.java.net/jdk/jdk/rev/ce06058197a4


From Alan.Bateman at oracle.com  Tue May  7 13:58:58 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 May 2019 14:58:58 +0100
Subject: 8223353: (ch) Change channel close implementation to not wait for
 I/O threads
In-Reply-To: <CE1DE4D1-55B9-4766-8968-293EBAA02363@oracle.com>
References: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>
 <87lfzjgb23.fsf@oldenburg2.str.redhat.com>
 <c92037da-7730-0ee4-a25e-034eba397982@oracle.com>
 <87ef5bepyz.fsf@oldenburg2.str.redhat.com>
 <63694db1-703c-3ac8-f392-8faa03065378@oracle.com>
 <CE1DE4D1-55B9-4766-8968-293EBAA02363@oracle.com>
Message-ID: <6aaa7e94-6bc9-7e92-380f-290ae1ad761f@oracle.com>

On 07/05/2019 14:35, Chris Hegarty wrote:
> :
> The changes to convert the stateLock back to using the built-in monitor
> of a private Object seem ok ( from what I can tell the changes seem to
> accurately anti-delta part of what was done in 8222774 [1] )
Yes although the non-trivial parts of JDK-8222774 are not changed.

>
> I'm trying to piece this together the other aspect of this change,
> close not waiting on I/O threads. To help better understand the change
> in behaviour, was it the changes for (8198562 & 8198754) [2], in
> Java 11, that resulted in socket channel `close` waiting on I/O threads
> to complete? Or something else ( I could be wrong as the code in this
> area has changed a few times ).
>
Right. When you close a channel (or socket) that has threads(s) blocked 
on I/O operations then you have to coordinate the close with those 
threads. We have two ways to do this. Both use preClose and signal to 
ensure that threads commencing I/O operations will not block and threads 
that are already blocked will get EINTR. The approaches differ on which 
thread does the "final close" to release the file descriptor. With 
classic networking the last thread to abort does the final close. With 
NIO it was the same prior to JDK 11. The channels implementations were 
mostly re-implemented in JDK 11 to separate the blocking/non-blocking 
code paths and async close changed to wait for the blocking case. So 
it's revisiting this so the last I/O operation to abort will do the 
final close. Part of the motivation now is Thread.interrupt to avoid 
that needing to wait. No change to non-blocking, the final close is 
always deferred when registered with one or more selectors.

-Alan

From Alan.Bateman at oracle.com  Tue May  7 14:00:19 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 May 2019 15:00:19 +0100
Subject: 8223353: (ch) Change channel close implementation to not wait for
 I/O threads
In-Reply-To: <d0eafa1a-83c7-4680-5e16-3e748995ff78@oracle.com>
References: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>
 <d0eafa1a-83c7-4680-5e16-3e748995ff78@oracle.com>
Message-ID: <30492486-1271-b327-1320-6176393c6f78@oracle.com>



On 07/05/2019 12:56, Daniel Fuchs wrote:
> Hi Alan,
>
> The changes seem reasonable to me. It looks like a nice
> simplification. I guess the JIRA issue will need a noreg-cleanup
> label. I assume you have verified that the tests have remained
> stable?
Thanks. Yes, lots of tests for this area as async close has been very 
problematic. I've run all of them on all platforms many times and have 
not observed any issues.

-Alan

From chris.hegarty at oracle.com  Tue May  7 15:42:14 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 7 May 2019 16:42:14 +0100
Subject: 8223353: (ch) Change channel close implementation to not wait for
 I/O threads
In-Reply-To: <6aaa7e94-6bc9-7e92-380f-290ae1ad761f@oracle.com>
References: <09b9ffd0-8f20-71f6-f7cc-bb8986caf8c4@oracle.com>
 <87lfzjgb23.fsf@oldenburg2.str.redhat.com>
 <c92037da-7730-0ee4-a25e-034eba397982@oracle.com>
 <87ef5bepyz.fsf@oldenburg2.str.redhat.com>
 <63694db1-703c-3ac8-f392-8faa03065378@oracle.com>
 <CE1DE4D1-55B9-4766-8968-293EBAA02363@oracle.com>
 <6aaa7e94-6bc9-7e92-380f-290ae1ad761f@oracle.com>
Message-ID: <7EBBA9D9-AF50-4B56-945C-5503D22523C9@oracle.com>


> On 7 May 2019, at 14:58, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> ... Part of the motivation now is Thread.interrupt to avoid that needing to wait. No change to non-blocking, the final close is always deferred when registered with one or more selectors.

Ok, this makes sense to me now. I didn't realize that in Java 11 a
thread interrupting another thread could potentially wait for I/O
operations to complete. It is certainly good to avoid this.

I wonder if a note should be added to the bug to capture this and the
little bit of history that has been discussed here, as it was not clear
to me.

BTW the changes look good.

-Chris.

From michael.x.mcmahon at oracle.com  Tue May  7 15:44:34 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 07 May 2019 16:44:34 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
Message-ID: <5CD1A7E2.60903@oracle.com>

Hi Alan,

What's the purpose of the change to the UdpTest?

- Michael.

On 01/05/2019, 14:10, Alan Bateman wrote:
>
> JEP 353 [1] is now a candidate and I would like to get the CSR [2] 
> finalized and the changes reviewed so that it can be targeted.
>
> The webrev with the changes is here:
>    http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html
>
> The new implementation is one source file; the only other code change 
> is to SocketImpl.createPlatformSocketImpl to select the implementation 
> based on the system property jdk.net.usePlainSocketImpl. The reason 
> the patch isn't too big is that all the "enabling changes" are already 
> in jdk/jdk.
>
> We added additional tests a few weeks ago via JDK-8221259 [3] to test 
> long standing behavior. The webrev adds a few additional tests, the 
> main new one is to test that the SocketImpl is reliable in the fact of 
> usages that are not specified by SocketImpl. A selection of existing 
> tests are also updated to run with both the old and new implementation 
> - the motive of this is to ensure that the old implementation doesn't 
> bit rot before it is removed.
>
> Once the changes are in a promoted build then we'll need help testing. 
> The best outcome is that nobody notices :-)  Rory O'Donnell, with his 
> OpenJDK quality outreach hat on, has agreed to contact the projects 
> tracked by that program to test the EA builds when they are available.
>
> -Alan
>
> [1] https://openjdk.java.net/jeps/353
> [2] https://bugs.openjdk.java.net/browse/JDK-8222028
> [3] https://bugs.openjdk.java.net/browse/JDK-8221259

From Alan.Bateman at oracle.com  Tue May  7 16:14:22 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 May 2019 17:14:22 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <5CD1A7E2.60903@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <5CD1A7E2.60903@oracle.com>
Message-ID: <ab012284-2be5-48be-176d-3392ef9d5578@oracle.com>

On 07/05/2019 16:44, Michael McMahon wrote:
> Hi Alan,
>
> What's the purpose of the change to the UdpTest?
The deprecated Socket constructors can be used to create a Socket that 
uses UDP. This means the new SocketImpl has to support the creation of 
UDP sockets and use the ResourceManager to enforce limits when running 
with a? security manager.? So it's just increasing test coverage as I 
wasn't able to find any tests in test/jdk that exercise it.

-Alan

From chris.hegarty at oracle.com  Tue May  7 16:30:51 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 7 May 2019 17:30:51 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
Message-ID: <B21EF255-AA82-4A94-9E80-9E31D9D6D952@oracle.com>


> On 1 May 2019, at 14:10, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> JEP 353 [1] is now a candidate and I would like to get the CSR [2] finalized and the changes reviewed so that it can be targeted.
> 
> The webrev with the changes is here:
>    http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html <http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html>

I have looked at this a number of times, already given some feedback and
pushed a few changes to the sandbox branch ( some time ago ).

Is this webrev ready for review? ( I see Michael has asked about a
change to UdpTest, but I see no UdpTest in the patch, maybe an old
version? )

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190507/d51675cb/attachment.html>

From Alan.Bateman at oracle.com  Tue May  7 16:39:02 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 7 May 2019 17:39:02 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <B21EF255-AA82-4A94-9E80-9E31D9D6D952@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <B21EF255-AA82-4A94-9E80-9E31D9D6D952@oracle.com>
Message-ID: <dd429470-2774-74f2-f139-cb430444f2dd@oracle.com>

On 07/05/2019 17:30, Chris Hegarty wrote:
>
>> On 1 May 2019, at 14:10, Alan Bateman <Alan.Bateman at oracle.com 
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>
>> JEP 353 [1] is now a candidate and I would like to get the CSR [2] 
>> finalized and the changes reviewed so that it can be targeted.
>>
>> The webrev with the changes is here:
>> http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html
>
> I have looked at this a number of times, already given some feedback and
> pushed a few changes to the sandbox branch ( some time ago ).
>
> Is this webrev ready for review? ( I see Michael has asked about a
> change to UdpTest, but I see no UdpTest in the patch, maybe an old
> version? )
Yes, it is ready for review.

I think/assume Michael was asking about the changes to the 
Socket/UdpSocket.java test. I didn't touch ipv6tests/UdpTest.java as 
that is a DatagramSocket test.

-Alan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190507/f4600268/attachment.html>

From chris.hegarty at oracle.com  Wed May  8 11:02:30 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 May 2019 12:02:30 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48sqMd_Eabo+orz4czgmmE1zXNGodOgdPH1DTSf-LQc+anw@mail.gmail.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
Message-ID: <48f29fb8-1fa3-a10b-02b5-2d93b5c45c20@oracle.com>

Arthur,

On 07/05/2019 19:35, Arthur Eubanks wrote:
> ...
> 
> 
> With help from Chris's references ([1]), I added a test with a policy 
> file that grants IPSupport permission to listen/resolve localhost:0, and 
> read the java.net.preferIPv4Stack system property. Without either 
> permission, the test fails as expected.
> One thing I discovered is that to make the policy file work properly 
> with the jtreg directory structure, I needed to add "@build 
> jdk.test.lib.net.IPSupport" to the test. So any test that wants to use 
> IPSupport and security managers needs to have that extra line and make 
> sure that its policy file contains all the permissions as in the new 
> test policy I added.

That is ok.

> Without "@build jdk.test.lib.net.IPSupport", the policy file would need 
> grant codeBase "file:${test.classes}/-"
> With?"@build jdk.test.lib.net.IPSupport", the policy file needs grant 
> codeBase "file:${test.classes}/../../../../test/lib/-"

Right, the difference comes from how jtreg builds its dependencies. The
former is an example of when a library is used conveniently with just
the @library tag, the library is automatically compiled into the
specific test's classes directory. The latter is when the library is
explicitly compiled with an @build, and gets put into a shared library
output directory, so that other tests ( that also specify an @build with
that library name ) can use the pre-built classes.

> This matches [1], and seems more restrictive (only applies to test 
> library code) and better.
> 
> New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/

I am happy with this latest version. Reviewed.

Trivially, maybe rename B8220673.java to something more descriptive
( without the bug no. ). Maybe MinimumPermissions? or whatever,
no need for a new webrev.

-Chris.

P.S. adding nio-dev since there are a few tests in that area
being updated.

> 
> [1]: 
> https://hg.openjdk.java.net/jdk/jdk/file/1dc9bf9d016b/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24

From chris.hegarty at oracle.com  Wed May  8 15:25:05 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 May 2019 16:25:05 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
Message-ID: <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>

Alan,

On 01/05/2019 14:10, Alan Bateman wrote:
> 
> JEP 353 [1] is now a candidate and I would like to get the CSR [2] 
> finalized and the changes reviewed so that it can be targeted.
> 
> The webrev with the changes is here:
>  ?? http://cr.openjdk.java.net/~alanb/8221481/1/webrev/index.html
This is a nice. The code is well structured and much more readable than
the plain implementation.

Some specific comments:

NioSocketImpl.java

  If configureBlocking returned a boolean, then an assert could be
  written to ensure that it operates as expected. For example, both
  connect and accept require it to actually switch the block mode for
  timed operations when called ( it cannot be a no-op ).

  RuntimeException is being used to transport IOException between
  FileDescriptorCloser::run ( which cannot throw a checked exception )
  and tryClose. I believe that tryClose should catch and unwrap this
  carrier RuntimeException.

  When tryClose is invoked in end[Read|Write|Connect|Accept], I believe
  that IOExceptions should be suppressed, at least when `completed` is
  true.

  typos "an" -> "a"
   408  * @throws SocketException if the socket is closed or *an* socket 
I/O error occurs
   429  * @throws SocketException if the socket is closed or *an* socket 
I/O error occurs

   882         // shutdown output when linger interval not set to 0
   883         try {
   884             var SO_LINGER = StandardSocketOptions.SO_LINGER;
   885             if ((int) Net.getSocketOption(fd, SO_LINGER) != 0) {
   886                 Net.shutdown(fd, Net.SHUT_WR);
   887             }
   888         } catch (IOException ignore) { }

  Is this a bug fix, or something that you ran across? I'm not familiar
  with this.

SocketImpl.java

  "45  * @implNote Client and server sockets created with the {@code 
Socket} and
   46  * {@code SocketServer} public constructors create a 
system/platform default
   47  * {@code SocketImpl}."

  The public no-args j.n.Socket constructor has the following slightly
  different wording: "Creates an unconnected socket, with the
  system-default type of SocketImpl." - these should probably be
  consistent.

  Why the use of "Java virtual machine" and "command line", since it is
  just a system property. I assume that this must come from the read-once
  nature of its impact? If so, are there other example of such and where?

  49  * newer implementation. The JDK continues to ship with the older 
implementation
  50  * to allow code to run that depends on unspecified behavior that 
differs between
  51  * the old and new implementations.

  If the intention of this property is as a temporarily aid for folk,
  that have code that depend upon the unspecified behavior, to run
  successfully until that code can be amended to remove the dependency on
  the particular unspecified behavior, then can that please be made
  clear.

  The property is effectively terminally deprecated at birth, right? If
  so, can a note indicating such be added.

Timeouts.java

  The test uses `assertTrue(false);` in a few places. TestNG has
  `org.testng.Assert.fail(String)` for this.

  Only time will tell if these tests that check duration will be stable
  on all platforms and configurations.

UdpSocket.java

  The new test scenario uses a hardcoded port number. Could this be a
  problem?

   121             while (ref.get() != null) {
   122                 System.gc();
   123                 Thread.sleep(100);
   124             }

  Is this loop guaranteed to exist at some point?

  80   assertTrue(Arrays.equals(array1, 0, n, array2, 0, n), "Unexpected 
contents");

  Can use `assertEquals(byte[] actual, byte[] expected, String message)`,
  which will print the arrays if unequal.

NewSocketMethods.java

  Is the change in this class still needed, or left over from a previous
  iteration?

test/jdk/java/net/SocketImpl/BadUsages.java

  At one point I added test/jdk/java/net/SocketImpl/BadSocketImpls.java
  to the sandbox branch. Have the test scenarios been subsumed into
  BadUsages? Or where have they gone?

-Chris.



From Alan.Bateman at oracle.com  Wed May  8 17:18:21 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 8 May 2019 18:18:21 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>
Message-ID: <570257cd-ee17-5878-cadd-7c2f090b7f80@oracle.com>

On 08/05/2019 16:25, Chris Hegarty wrote:
> This is a nice. The code is well structured and much more readable than
> the plain implementation.
Thanks for doing through the implementation.

> :
>
> NioSocketImpl.java
>
> ?If configureBlocking returned a boolean, then an assert could be
> ?written to ensure that it operates as expected. For example, both
> ?connect and accept require it to actually switch the block mode for
> ?timed operations when called ( it cannot be a no-op ).
It's just connect that restores the blocking mode after a connection is 
established with a timeout. IOException is thrown if it fails. I assume 
you are wondering if there is a code path that calls 
configureNonBlockingForever that locks the socket in non-blocking mode. 
I guess we could add asserts but that would complicate down stream work. 
So I guess I'm inclined to leave it as is, and add any comments to help 
if there isn't anything obvious on how it works.


>
> ?RuntimeException is being used to transport IOException between
> ?FileDescriptorCloser::run ( which cannot throw a checked exception )
> ?and tryClose. I believe that tryClose should catch and unwrap this
> ?carrier RuntimeException.
Fair point as there is an assumption it cannot fail. There is actually 
is a long standing issue here in that 
FileDispatcherImpl.closeFileDescriptor should not throw an exception if 
close fails with EINTR (as close is not restartable). If it fails with 
anything else then it suggests a serious bug somewhere.

> :
>
> ?typos "an" -> "a"
> ? 408? * @throws SocketException if the socket is closed or *an* 
> socket I/O error occurs
> ? 429? * @throws SocketException if the socket is closed or *an* 
> socket I/O error occurs
Thanks.


>
> ? 882???????? // shutdown output when linger interval not set to 0
> ? 883???????? try {
> ? 884???????????? var SO_LINGER = StandardSocketOptions.SO_LINGER;
> ? 885???????????? if ((int) Net.getSocketOption(fd, SO_LINGER) != 0) {
> ? 886???????????????? Net.shutdown(fd, Net.SHUT_WR);
> ? 887???????????? }
> ? 888???????? } catch (IOException ignore) { }
>
> ?Is this a bug fix, or something that you ran across? I'm not familiar
> ?with this.
This preserves existing behavior to do a graceful shutdown when there is 
no linger interval. If you look at the NET_SocketClose implementation on 
Windows or SocketChannelImpl.close then you'll see what I mean.

>
> SocketImpl.java
>
> ?"45? * @implNote Client and server sockets created with the {@code 
> Socket} and
> ? 46? * {@code SocketServer} public constructors create a 
> system/platform default
> ? 47? * {@code SocketImpl}."
>
> ?The public no-args j.n.Socket constructor has the following slightly
> ?different wording: "Creates an unconnected socket, with the
> ?system-default type of SocketImpl." - these should probably be
> ?consistent.
Okay, I can try to keep it consistent although at some point I think we 
should do a pass over some of the JDK 1.0 era javadoc and re-visit the 
places it talks about the default SocketImpl, esp. all the references to 
"plain".

>
> ?Why the use of "Java virtual machine" and "command line", since it is
> ?just a system property. I assume that this must come from the read-once
> ?nature of its impact? If so, are there other example of such and where?
It's not reliable to set the system property in a running VM so the note 
is just setting the expectations that it needs to be set at startup, 
nothing more.

>
> ?49? * newer implementation. The JDK continues to ship with the older 
> implementation
> ?50? * to allow code to run that depends on unspecified behavior that 
> differs between
> ?51? * the old and new implementations.
>
> ?If the intention of this property is as a temporarily aid for folk,
> ?that have code that depend upon the unspecified behavior, to run
> ?successfully until that code can be amended to remove the dependency on
> ?the particular unspecified behavior, then can that please be made
> ?clear.
>
> ?The property is effectively terminally deprecated at birth, right? If
> ?so, can a note indicating such be added.
The intention is that implNote will be removed when the property and old 
implementation are removed. It's something that I was going to put in 
the RN/docs but I guess we could extend the implNote on this point too.


>
> Timeouts.java
>
> ?The test uses `assertTrue(false);` in a few places. TestNG has
> ?`org.testng.Assert.fail(String)` for this.
Okay.


>
> ?Only time will tell if these tests that check duration will be stable
> ?on all platforms and configurations.
Right, it's always tricky to test timeout behavior. In this case, I've 
run the test 1000+ times on all platforms and have not seen any failures.

>
> UdpSocket.java
>
> ?The new test scenario uses a hardcoded port number. Could this be a
> ?problem?
The host/port specified to the 3-arg constructor is the remote socket 
address that it connects to, not the local address/port. So it's like 
DatagramSocket.connect and any port will do because it's not 
sending/receiving packets.

>
> ? 121???????????? while (ref.get() != null) {
> ? 122???????????????? System.gc();
> ? 123???????????????? Thread.sleep(100);
> ? 124???????????? }
>
> ?Is this loop guaranteed to exist at some point?
We use this idiom in several tests. If someone where to run the tests 
with +DisableExplicitGC then it would fail but hundreds of other tests 
would also fail.

>
> ?80?? assertTrue(Arrays.equals(array1, 0, n, array2, 0, n), 
> "Unexpected contents");
>
> ?Can use `assertEquals(byte[] actual, byte[] expected, String message)`,
> ?which will print the arrays if unequal.
Fair point although this is the existing test where it just throws when 
the size or contents differ.


>
> NewSocketMethods.java
>
> ?Is the change in this class still needed, or left over from a previous
> ?iteration?
This is an outlier on Solaris as that platform doesn't allow IPV6_TCLASS 
to be set when the socket is connected. There is a note in the JEP on 
this as it is masked by the old implementation. I see you've collected 
some useful info in JDK-8221487 on the issue so I think we can keep it 
separate.


>
> test/jdk/java/net/SocketImpl/BadUsages.java
>
> ?At one point I added test/jdk/java/net/SocketImpl/BadSocketImpls.java
> ?to the sandbox branch. Have the test scenarios been subsumed into
> ?BadUsages? Or where have they gone?
BadSocketImpls.java exercised the platform SocketImpl accepting a 
connection with a no-op SocketImpl.? It pre-dates the work in 
JDK-8220493 to prevent such combinations. We added 
SocketImplCombinations.java as part of JDK-8220493 to test all the 
combinations and scenarios that we could come up, I don't think there 
was anything in BadSocketImpls that we could bring over.

-Alan.

From Alan.Bateman at oracle.com  Thu May  9 06:22:54 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 May 2019 07:22:54 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <48f29fb8-1fa3-a10b-02b5-2d93b5c45c20@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
 <48f29fb8-1fa3-a10b-02b5-2d93b5c45c20@oracle.com>
Message-ID: <b99a68bf-27b3-fb83-b7a3-dfaaa83deca3@oracle.com>

On 08/05/2019 12:02, Chris Hegarty wrote:
> :
>>
>> New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/
>
> :
>
> P.S. adding nio-dev since there are a few tests in that area
> being updated.
Thanks for forwarding.

IPSupports.skipIfConcurrentConfigurationIsInvalid is a bit strange and I 
think the first use of SkippedException in the jdk tests. I'm tempted to 
suggest this should be a key that tests should select on via the 
@requires tag but that may not be feasible because it depends on 
properties such as preferIPv4Stack. So I guess the approach is okay but 
we should rename the method to start with "skipTest" as it's not clear 
from the use-case what is being skipped. Also 
"ConcurrentConfigurationIsInvalid" is vague and I think it would be 
useful if the method description could emulate the conditions a bit 
better so that someone seeing a IPSupport.skipTestXXX knows what is means.

-Alan

From michael.x.mcmahon at oracle.com  Thu May  9 10:51:55 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 09 May 2019 11:51:55 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <ab012284-2be5-48be-176d-3392ef9d5578@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <5CD1A7E2.60903@oracle.com> <ab012284-2be5-48be-176d-3392ef9d5578@oracle.com>
Message-ID: <5CD4064B.9060205@oracle.com>



On 07/05/2019, 17:14, Alan Bateman wrote:
> On 07/05/2019 16:44, Michael McMahon wrote:
>> Hi Alan,
>>
>> What's the purpose of the change to the UdpTest?
> The deprecated Socket constructors can be used to create a Socket that 
> uses UDP. This means the new SocketImpl has to support the creation of 
> UDP sockets and use the ResourceManager to enforce limits when running 
> with a  security manager.  So it's just increasing test coverage as I 
> wasn't able to find any tests in test/jdk that exercise it.
>
> -Alan
Ok, thanks. A test that might be useful could be one that compares the 
supported options between the old
and new impls for both client and server sockets. I guess it shouldn't 
be required for the initial push though.

- Michael.

From chris.hegarty at oracle.com  Thu May  9 11:02:08 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 9 May 2019 12:02:08 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <b99a68bf-27b3-fb83-b7a3-dfaaa83deca3@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <CAPW48spqbX6YYfwQvKKP-0EsK1KNiRKgWqtKpRHygVsVBEy_RQ@mail.gmail.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
 <48f29fb8-1fa3-a10b-02b5-2d93b5c45c20@oracle.com>
 <b99a68bf-27b3-fb83-b7a3-dfaaa83deca3@oracle.com>
Message-ID: <0CB64687-CB65-4249-867D-B583E272E408@oracle.com>

Alan,

> On 9 May 2019, at 07:22, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 08/05/2019 12:02, Chris Hegarty wrote:
>> :
>>> 
>>> New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/
>> 
>> :
>> 
>> P.S. adding nio-dev since there are a few tests in that area
>> being updated.
> Thanks for forwarding.
> 
> IPSupports.skipIfConcurrentConfigurationIsInvalid is a bit strange and I think the first use of SkippedException in the jdk tests. I'm tempted to suggest this should be a key that tests should select on via the @requires tag but that may not be feasible because it depends on properties such as preferIPv4Stack.

The alternative of using `@requires` was considered and rejected, for
the same reason you mention [1]. Additionally, using SkippedException
will be more straight forward to detect skipped tests and the reason
( the IP configuration ) why the test was skipped.

> So I guess the approach is okay but we should rename the method to start with "skipTest" as it's not clear from the use-case what is being skipped. Also "ConcurrentConfigurationIsInvalid" is vague and I think it would be useful if the method description could emulate the conditions a bit better so that someone seeing a IPSupport.skipTestXXX knows what is means.

I agree that the method name could be improved. It?s really:

?skip test if cannot create a minimally-operational IPv4 or IPv6 socket"

Some concrete method name suggestions ( more welcome ):

  - IPSupport::skipTestIfNonOperational
  - IPSupport::skipTestIfCannotCreateAnyIPSockets
  

Suggested method-level documentation improvement:

  /**
   * Ensures that the platform supports the ability to create a
   * minimally-operational socket whose protocol is either one of IPv4
   * or IPv6.
   *
   * <p> A minimally-operation socket is one that can be created and
   * bound to an IP-specific loopback address. IP support is
   * considered non-operational if a socket cannot be bound to either
   * one of, an IPv4 loopback address, or the IPv6 loopback address.
   *
   * @throws SkippedException if the current networking configuration
   *         is non-operational
   */
  public static void skipTestIfNonOperational() throws SkippedException


-Chris.

P.S. 8220673 has been pushed already, but we should continue the
discussion here and I will create a follow-on JIRA issue to track it.

[1] https://mail.openjdk.java.net/pipermail/net-dev/2019-April/012348.html



From Alan.Bateman at oracle.com  Thu May  9 11:16:38 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 May 2019 12:16:38 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <5CD4064B.9060205@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <5CD1A7E2.60903@oracle.com> <ab012284-2be5-48be-176d-3392ef9d5578@oracle.com>
 <5CD4064B.9060205@oracle.com>
Message-ID: <24cd3c15-ad4f-351e-2cfa-1b80bbc895b8@oracle.com>

On 09/05/2019 11:51, Michael McMahon wrote:
> Ok, thanks. A test that might be useful could be one that compares the 
> supported options between the old
> and new impls for both client and server sockets. I guess it shouldn't 
> be required for the initial push though.
>
There are several existing tests that will fail if there options missing 
but they might not catch the scenario where the new implementation 
supports additional option. I can add another test for that as it's easy.

-Alan


From Alan.Bateman at oracle.com  Thu May  9 11:20:18 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 May 2019 12:20:18 +0100
Subject: [ipv6] Regarding 8220673: Add test library support for
 determining platform IP support
In-Reply-To: <0CB64687-CB65-4249-867D-B583E272E408@oracle.com>
References: <34640ecf-3396-786d-f2dd-e87a174b3c4f@oracle.com>
 <64950EF2-A595-45A4-8960-4DD9089D8BF4@oracle.com>
 <CAPW48spbxh6LyYe1HuERWOkPqVJKFpjVkhhVQUSn+oX2fQ-knQ@mail.gmail.com>
 <CAPW48sohpTxv+GaKjJqxqBn6v_wgAu_3q4oSGc+Po0=QT=XDCw@mail.gmail.com>
 <C1ED5547-2D64-45AF-B5B0-2A1D0443E4F9@oracle.com>
 <d80f9381-a3cc-c41b-0b5b-719e3cd5b174@oracle.com>
 <CAPW48srR5kP0p0MZnScy9EwTai8OaG04zxLus3idp6vnkGF=jg@mail.gmail.com>
 <28EBA60A-E235-4204-BC77-7E39F880ECBD@oracle.com>
 <CAPW48srJ6PWUwo5guPbatSMaLz3b8vmbj8weka-Oouwg78rE9Q@mail.gmail.com>
 <CAPW48sp7WoB8xRyWPOdWyDOHKijKuDwiC6RbR3EmLj+zahGMOA@mail.gmail.com>
 <bdf5c0f9-579e-f23c-33c2-75ed4ab8d0f8@oracle.com>
 <CAPW48so7CaXSk_7XU195ARrJPXBX5HRo-1jk_Z2kPtFMykp2YA@mail.gmail.com>
 <8a2a8491-fab5-d85e-4c43-bdb65995d0bc@oracle.com>
 <CAPW48sqq1X7kDvdyoBhJCpUkw40Sw_fVMe5bXesr+7T9pWZCng@mail.gmail.com>
 <48f29fb8-1fa3-a10b-02b5-2d93b5c45c20@oracle.com>
 <b99a68bf-27b3-fb83-b7a3-dfaaa83deca3@oracle.com>
 <0CB64687-CB65-4249-867D-B583E272E408@oracle.com>
Message-ID: <3f1f5602-7c33-913c-9a7d-6d2df4513447@oracle.com>

On 09/05/2019 12:02, Chris Hegarty wrote:
> :
> I agree that the method name could be improved. It?s really:
>
> ?skip test if cannot create a minimally-operational IPv4 or IPv6 socket"
>
> Some concrete method name suggestions ( more welcome ):
>
>    - IPSupport::skipTestIfNonOperational
>    - IPSupport::skipTestIfCannotCreateAnyIPSockets
>    
>
throwSkippedExceptionIfXXX might work too. That might make it a bit more 
obvious in the tests.

-Alan

From Alan.Bateman at oracle.com  Thu May  9 13:00:18 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 May 2019 14:00:18 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <570257cd-ee17-5878-cadd-7c2f090b7f80@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>
 <570257cd-ee17-5878-cadd-7c2f090b7f80@oracle.com>
Message-ID: <6831d5b3-a6b2-cd08-a412-81c734ce247a@oracle.com>

Thanks Chris and Michael for the reviews/help so far. I've uploaded a 
new webrev to address most of their points here:
 ?? http://cr.openjdk.java.net/~alanb/8221481/2/webrev/index.html

and delta webrev with the changes from 1 to 2 here:
 ?? http://cr.openjdk.java.net/~alanb/8221481/1to2/webrev/index.html

-Alan

From chris.hegarty at oracle.com  Thu May  9 13:24:26 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 9 May 2019 14:24:26 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <6831d5b3-a6b2-cd08-a412-81c734ce247a@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>
 <570257cd-ee17-5878-cadd-7c2f090b7f80@oracle.com>
 <6831d5b3-a6b2-cd08-a412-81c734ce247a@oracle.com>
Message-ID: <39747523-B6D1-42FD-891C-CDBE3F17117A@oracle.com>

Alan,

> On 9 May 2019, at 14:00, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> Thanks Chris and Michael for the reviews/help so far. I've uploaded a new webrev to address most of their points here:
>    http://cr.openjdk.java.net/~alanb/8221481/2/webrev/index.html
> 
> and delta webrev with the changes from 1 to 2 here:
>    http://cr.openjdk.java.net/~alanb/8221481/1to2/webrev/index.html


This addresses my comments / concerns. Reviewed.

-Chris.

P.S. Thanks for generating the delta-webrev.

From michael.x.mcmahon at oracle.com  Thu May  9 13:24:38 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 09 May 2019 14:24:38 +0100
Subject: 8218559: Reimplement the Legacy Socket API
In-Reply-To: <6831d5b3-a6b2-cd08-a412-81c734ce247a@oracle.com>
References: <c1f32b20-07cb-800b-6ca3-a6c55b753f9b@oracle.com>
 <6eb2c56a-3533-7e70-f0d7-92a6debf878a@oracle.com>
 <570257cd-ee17-5878-cadd-7c2f090b7f80@oracle.com>
 <6831d5b3-a6b2-cd08-a412-81c734ce247a@oracle.com>
Message-ID: <5CD42A16.6060909@oracle.com>

Looks good to me. I don't have anything else to add at this point. I 
agree the new implementation is much clearer
than the old and it will be great to see it working in the field.

Thanks,

Michael

On 09/05/2019, 14:00, Alan Bateman wrote:
> Thanks Chris and Michael for the reviews/help so far. I've uploaded a 
> new webrev to address most of their points here:
>    http://cr.openjdk.java.net/~alanb/8221481/2/webrev/index.html
>
> and delta webrev with the changes from 1 to 2 here:
>    http://cr.openjdk.java.net/~alanb/8221481/1to2/webrev/index.html
>
> -Alan

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190509/9be8b49c/attachment-0001.html>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190513/7fbee9df/attachment.html>

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190513/bc954590/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190513/bc954590/oracle_sig_logo-0001.gif>

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>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190513/5e9769b9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190513/5e9769b9/oracle_sig_logo-0001.gif>

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190514/59dfddf0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 658 bytes
Desc: image001.gif
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190514/59dfddf0/image001-0001.gif>

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190514/f0b4b52a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190514/f0b4b52a/oracle_sig_logo.gif>

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 Alan.Bateman at oracle.com  Thu May 16 06:48:46 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 May 2019 07:48:46 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
Message-ID: <8b6a9cf1-0d1d-eb13-fb6e-d0eda7f1a464@oracle.com>

On 16/05/2019 01:45, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224019
> webrev: http://cr.openjdk.java.net/~aeubanks/8224019/webrev.00/index.html
>
> test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java 
> assumes 
> NetworkConfiguration.probe().ip4MulticastInterfaces().iterator() 
> always has at least one NetworkInterface. Instead it should do 
> something like the IPv6 code right after it where it checks that the 
> iterator is not empty.
I think this test will require other changes to do what you want. In 
particular, expectionTests should be run if there is IPv4 or IPv6 
available. It might be that expectionTests needs the family agnostic 
tests split out, or maybe it needs parameter to indicate the family and 
multicast groups to use.

-Alan.

From Alan.Bateman at oracle.com  Thu May 16 13:10:34 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 May 2019 14:10:34 +0100
Subject: 8223442: java/nio/channels/SocketChannel/AdaptorStreams.java
 testConcurrentTimedReadWrite3(): failure
Message-ID: <76608951-7407-ef9b-0d77-cbc48b3ae3ab@oracle.com>

One of the tests in the recently added AdaptorStreams.java has failed a 
few times on Windows. It turns out to be a long standing Windows 
specific issue, it just happens that this test creates the right 
conditions to tickle it.

The issue arises when asynchronously closing a socket when the channel 
is configured blocking. The Windows implementation need to invalidate 
the FileDescriptor before closing so it works the same as classic 
networking.

The webrev with the proposed change is here.
 ?? http://cr.openjdk.java.net/~alanb/8223442/webrev/

-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 michael.x.mcmahon at oracle.com  Thu May 16 13:43:50 2019
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 16 May 2019 14:43:50 +0100
Subject: 8223442: java/nio/channels/SocketChannel/AdaptorStreams.java
 testConcurrentTimedReadWrite3(): failure
In-Reply-To: <76608951-7407-ef9b-0d77-cbc48b3ae3ab@oracle.com>
References: <76608951-7407-ef9b-0d77-cbc48b3ae3ab@oracle.com>
Message-ID: <5CDD6916.3060206@oracle.com>

This looks fine to me Alan.

- Michael.

On 16/05/2019, 14:10, Alan Bateman wrote:
> One of the tests in the recently added AdaptorStreams.java has failed 
> a few times on Windows. It turns out to be a long standing Windows 
> specific issue, it just happens that this test creates the right 
> conditions to tickle it.
>
> The issue arises when asynchronously closing a socket when the channel 
> is configured blocking. The Windows implementation need to invalidate 
> the FileDescriptor before closing so it works the same as classic 
> networking.
>
> The webrev with the proposed change is here.
>    http://cr.openjdk.java.net/~alanb/8223442/webrev/
>
> -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>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190516/8c73e478/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190516/8c73e478/oracle_sig_logo-0001.gif>

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 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: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 Alan.Bateman at oracle.com  Fri May 17 06:41:15 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 May 2019 07:41:15 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
 <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
Message-ID: <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>

On 16/05/2019 23:38, Arthur Eubanks wrote:
> I've added testing exceptions to IPv6 as well, PTAL.
> This required hardcoding IPv4 and IPv6 loopback addresses for the IPv4 
> and IPv6 code paths. Else DatagramChannel.join() fails since you can't 
> mix IPv4 and IPv6 addresses, and InetAddress.getLocalHost() can only 
> be one of those.
>
> http://cr.openjdk.java.net/~aeubanks/8224019/webrev.01/
>
Adding back nio-dev as it seems to have been dropped from thread again.

On webrev.01, I think the approach looks okay but would you have 
re-ordering the parameters to both membershipKeyTests and exceptionTests 
so that the protocol family is first, then the groups, then the 
NetworkInterface as that will align with the usages and the join methods 
where the order is always group, networkInterface (and optionally source).

-Alan

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>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190517/c13771ac/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 658 bytes
Desc: image001.gif
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190517/c13771ac/image001-0001.gif>

From aeubanks at google.com  Fri May 17 17:22:36 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Fri, 17 May 2019 10:22:36 -0700
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java
 assumes IPv4 is always available
In-Reply-To: <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
 <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
 <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>
Message-ID: <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>

On Thu, May 16, 2019 at 11:41 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 16/05/2019 23:38, Arthur Eubanks wrote:
> > I've added testing exceptions to IPv6 as well, PTAL.
> > This required hardcoding IPv4 and IPv6 loopback addresses for the IPv4
> > and IPv6 code paths. Else DatagramChannel.join() fails since you can't
> > mix IPv4 and IPv6 addresses, and InetAddress.getLocalHost() can only
> > be one of those.
> >
> > http://cr.openjdk.java.net/~aeubanks/8224019/webrev.01/
> >
> Adding back nio-dev as it seems to have been dropped from thread again.
>
> On webrev.01, I think the approach looks okay but would you have
> re-ordering the parameters to both membershipKeyTests and exceptionTests
> so that the protocol family is first, then the groups, then the
> NetworkInterface as that will align with the usages and the join methods
> where the order is always group, networkInterface (and optionally source).
>
> -Alan
>
Done, order is protocol family, group/notGroup InetAddress,
NetworkInterface, source InetAddress
http://cr.openjdk.java.net/~aeubanks/8224019/webrev.02/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190517/1e5a5eca/attachment.html>

From Alan.Bateman at oracle.com  Fri May 17 17:49:12 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 May 2019 18:49:12 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
 <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
 <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>
 <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
Message-ID: <891ff1c3-cce1-1f5e-1041-376e19e227b7@oracle.com>

On 17/05/2019 18:22, Arthur Eubanks wrote:
>
> Done, order is protocol family, group/notGroup InetAddress, 
> NetworkInterface, source InetAddress
> http://cr.openjdk.java.net/~aeubanks/8224019/webrev.02/
Thanks, this version looks okay to me.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190517/59e5f01d/attachment.html>

From lance.andersen at oracle.com  Fri May 17 23:46:28 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 17 May 2019 19:46:28 -0400
Subject: RFR: 8222807:  Address iteration with invalid ZIP header entries
Message-ID: <93D301F8-FA23-4F57-A57C-DFB94C33625A@oracle.com>

Hi all.

Please review the webrev for 8222807.  This deals with ZIP header entries such as ?foo//?. resulting in issues walking walking through a ZIP archive.

The webrev can be found at: http://cr.openjdk.java.net/~lancea/8222807/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8222807/webrev.00/index.html>.

I have verified that the mach5 tier1, tier2, and tier3 tests all pass.

Thank you and have a good weekend.

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>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190517/a6f6eaf8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190517/a6f6eaf8/oracle_sig_logo.gif>

From claes.redestad at oracle.com  Sat May 18 01:14:19 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 18 May 2019 03:14:19 +0200
Subject: RFR: 8222807: Address iteration with invalid ZIP header entries
In-Reply-To: <93D301F8-FA23-4F57-A57C-DFB94C33625A@oracle.com>
References: <93D301F8-FA23-4F57-A57C-DFB94C33625A@oracle.com>
Message-ID: <f9ed40d0-1dc0-960e-6b69-ea50d2f79ef0@oracle.com>

Hi Lance,

since needing to normalize should be very rare in practice it might be
profitable to outline that case, see similar code in
UnixFileSystem::normalize

You introduced int len = path.length but then use path.length
in most places.

/Claes

On 2019-05-18 01:46, Lance Andersen wrote:
> Hi all.
> 
> Please review the webrev for?8222807. ?This deals?with ZIP header 
> entries such as ?foo//?. resulting in issues walking walking through a 
> ZIP archive.
> 
> The webrev can be found at: 
> http://cr.openjdk.java.net/~lancea/8222807/webrev.00/index.html.
> 
> I have verified that the mach5 tier1, tier2, and tier3 tests all pass.
> 
> Thank you and have a good weekend.
> 
> Best
> Lance
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| 
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> 
> 

From Alan.Bateman at oracle.com  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 lance.andersen at oracle.com  Sat May 18 20:58:52 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sat, 18 May 2019 16:58:52 -0400
Subject: RFR: 8222807: Address iteration with invalid ZIP header entries
In-Reply-To: <f9ed40d0-1dc0-960e-6b69-ea50d2f79ef0@oracle.com>
References: <93D301F8-FA23-4F57-A57C-DFB94C33625A@oracle.com>
 <f9ed40d0-1dc0-960e-6b69-ea50d2f79ef0@oracle.com>
Message-ID: <BB24A4A2-BAD1-4EDA-B66A-51AE1550AB09@oracle.com>

Hi Claes,

Thank you for the feedback.
> On May 17, 2019, at 9:14 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi Lance,
> 
> since needing to normalize should be very rare in practice it might be
> profitable to outline that case, see similar code in
> UnixFileSystem::normalize

Per your suggestion, I made the change and it can be found at: http://cr.openjdk.java.net/~lancea/8222807/webrev.01/index.html <http://cr.openjdk.java.net/~lancea/8222807/webrev.01/index.html>

Mach5 tier1, tier2 and tier3 runs are clean

> 
> You introduced int len = path.length but then use path.length
> in most places.

Thank you again.

Best
Lance
> 
> /Claes
> 
> On 2019-05-18 01:46, Lance Andersen wrote:
>> Hi all.
>> Please review the webrev for 8222807.  This deals with ZIP header entries such as ?foo//?. resulting in issues walking walking through a ZIP archive.
>> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8222807/webrev.00/index.html.
>> I have verified that the mach5 tier1, tier2, and tier3 tests all pass.
>> Thank you and have a good weekend.
>> 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>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190518/dcced6c3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190518/dcced6c3/oracle_sig_logo.gif>

From claes.redestad at oracle.com  Sat May 18 23:37:54 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sun, 19 May 2019 01:37:54 +0200
Subject: RFR: 8222807: Address iteration with invalid ZIP header entries
In-Reply-To: <BB24A4A2-BAD1-4EDA-B66A-51AE1550AB09@oracle.com>
References: <93D301F8-FA23-4F57-A57C-DFB94C33625A@oracle.com>
 <f9ed40d0-1dc0-960e-6b69-ea50d2f79ef0@oracle.com>
 <BB24A4A2-BAD1-4EDA-B66A-51AE1550AB09@oracle.com>
Message-ID: <5526FAB6-0E36-444D-B5F3-8AE69B186631@oracle.com>

Looks good, Lance!

/Claes

Lance Andersen <lance.andersen at oracle.com> skrev: (18 maj 2019 22:58:52 CEST)
>Hi Claes,
>
>Thank you for the feedback.
>> On May 17, 2019, at 9:14 PM, Claes Redestad
><claes.redestad at oracle.com> wrote:
>> 
>> Hi Lance,
>> 
>> since needing to normalize should be very rare in practice it might
>be
>> profitable to outline that case, see similar code in
>> UnixFileSystem::normalize
>
>Per your suggestion, I made the change and it can be found at:
>http://cr.openjdk.java.net/~lancea/8222807/webrev.01/index.html
><http://cr.openjdk.java.net/~lancea/8222807/webrev.01/index.html>
>
>Mach5 tier1, tier2 and tier3 runs are clean
>
>> 
>> You introduced int len = path.length but then use path.length
>> in most places.
>
>Thank you again.
>
>Best
>Lance
>> 
>> /Claes
>> 
>> On 2019-05-18 01:46, Lance Andersen wrote:
>>> Hi all.
>>> Please review the webrev for 8222807.  This deals with ZIP header
>entries such as ?foo//?. resulting in issues walking walking through a
>ZIP archive.
>>> The webrev can be found at:
>http://cr.openjdk.java.net/~lancea/8222807/webrev.00/index.html.
>>> I have verified that the mach5 tier1, tier2, and tier3 tests all
>pass.
>>> Thank you and have a good weekend.
>>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190519/c4f7d067/attachment-0001.html>

From christoph.langer at sap.com  Mon May 20 06:58:15 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 20 May 2019 06:58:15 +0000
Subject: RFR: 8222807: Address iteration with invalid ZIP header entries
In-Reply-To: <BB24A4A2-BAD1-4EDA-B66A-51AE1550AB09@oracle.com>
References: <93D301F8-FA23-4F57-A57C-DFB94C33625A@oracle.com>
 <f9ed40d0-1dc0-960e-6b69-ea50d2f79ef0@oracle.com>
 <BB24A4A2-BAD1-4EDA-B66A-51AE1550AB09@oracle.com>
Message-ID: <AM6PR02MB51922ADBCF194422271589958A060@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Lance,

I checked the code and it looks good to me.

The comment in the test (line 46) should probably be more like: ?Validate that you can iterate a ZIP file with invalid ZIP header entries?.

Best regards
Christoph


From: nio-dev <nio-dev-bounces at openjdk.java.net> On Behalf Of Lance Andersen
Sent: Samstag, 18. Mai 2019 22:59
To: Claes Redestad <claes.redestad at oracle.com>
Cc: nio-dev <nio-dev at openjdk.java.net>
Subject: Re: RFR: 8222807: Address iteration with invalid ZIP header entries

Hi Claes,

Thank you for the feedback.
On May 17, 2019, at 9:14 PM, Claes Redestad <claes.redestad at oracle.com<mailto:claes.redestad at oracle.com>> wrote:

Hi Lance,

since needing to normalize should be very rare in practice it might be
profitable to outline that case, see similar code in
UnixFileSystem::normalize

Per your suggestion, I made the change and it can be found at: http://cr.openjdk.java.net/~lancea/8222807/webrev.01/index.html

Mach5 tier1, tier2 and tier3 runs are clean



You introduced int len = path.length but then use path.length
in most places.

Thank you again.

Best
Lance


/Claes

On 2019-05-18 01:46, Lance Andersen wrote:

Hi all.
Please review the webrev for 8222807.  This deals with ZIP header entries such as ?foo//?. resulting in issues walking walking through a ZIP archive.
The webrev can be found at: http://cr.openjdk.java.net/~lancea/8222807/webrev.00/index.html.
I have verified that the mach5 tier1, tier2, and tier3 tests all pass.
Thank you and have a good weekend.
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>

[cid:image001.gif at 01D50EEA.1F60C770]<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>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190520/d8e203d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 658 bytes
Desc: image001.gif
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190520/d8e203d6/image001.gif>

From chris.hegarty at oracle.com  Mon May 20 10:02:07 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 20 May 2019 11:02:07 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
 <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
 <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>
 <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
Message-ID: <da4b186f-8221-6169-1c6b-bc4a3d2ba36b@oracle.com>

Arthur,

On 17/05/2019 18:22, Arthur Eubanks wrote:
> ...
> http://cr.openjdk.java.net/~aeubanks/8224019/webrev.02/

Looks good.

-Chris.

From lance.andersen at oracle.com  Mon May 20 11:16:32 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 20 May 2019 07:16:32 -0400
Subject: RFR: 8222807: Address iteration with invalid ZIP header entries
In-Reply-To: <AM6PR02MB51922ADBCF194422271589958A060@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <93D301F8-FA23-4F57-A57C-DFB94C33625A@oracle.com>
 <f9ed40d0-1dc0-960e-6b69-ea50d2f79ef0@oracle.com>
 <BB24A4A2-BAD1-4EDA-B66A-51AE1550AB09@oracle.com>
 <AM6PR02MB51922ADBCF194422271589958A060@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <66C50BE3-5BE5-4EF0-AEC7-275907F72299@oracle.com>

Hi Christoph,

Thank you for the review.
> On May 20, 2019, at 2:58 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Lance,
>  
> I checked the code and it looks good to me.
>  
> The comment in the test (line 46) should probably be more like: ?Validate that you can iterate a ZIP file with invalid ZIP header entries?.

Sure I can update that prior to pushing.

Best
lance
>  
> Best regards
> Christoph
>  
>  
> From: nio-dev <nio-dev-bounces at openjdk.java.net <mailto:nio-dev-bounces at openjdk.java.net>> On Behalf Of Lance Andersen
> Sent: Samstag, 18. Mai 2019 22:59
> To: Claes Redestad <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>>
> Cc: nio-dev <nio-dev at openjdk.java.net <mailto:nio-dev at openjdk.java.net>>
> Subject: Re: RFR: 8222807: Address iteration with invalid ZIP header entries
>  
> Hi Claes,
>  
> Thank you for the feedback.
> On May 17, 2019, at 9:14 PM, Claes Redestad <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>  
> Hi Lance,
> 
> since needing to normalize should be very rare in practice it might be
> profitable to outline that case, see similar code in
> UnixFileSystem::normalize
>  
> Per your suggestion, I made the change and it can be found at: http://cr.openjdk.java.net/~lancea/8222807/webrev.01/index.html <http://cr.openjdk.java.net/~lancea/8222807/webrev.01/index.html>
>  
> Mach5 tier1, tier2 and tier3 runs are clean
> 
> 
> 
> You introduced int len = path.length but then use path.length
> in most places.
>  
> Thank you again.
>  
> Best
> Lance
> 
> 
> /Claes
> 
> On 2019-05-18 01:46, Lance Andersen wrote:
> 
> Hi all.
> Please review the webrev for 8222807.  This deals with ZIP header entries such as ?foo//?. resulting in issues walking walking through a ZIP archive.
> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8222807/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8222807/webrev.00/index.html>.
> I have verified that the mach5 tier1, tier2, and tier3 tests all pass.
> Thank you and have a good weekend.
> Best
> Lance
> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>><http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>  
> <image001.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>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190520/a40c2be6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190520/a40c2be6/oracle_sig_logo-0001.gif>

From daniel.fuchs at oracle.com  Mon May 20 11:23:43 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 20 May 2019 12:23:43 +0100
Subject: [ipv6]: 8224019:
 test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes
 IPv4 is always available
In-Reply-To: <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
References: <CAPW48sqDi4VBip-JNMHfbGRWiz-m7Frggf8nP3gT+puWqqw39w@mail.gmail.com>
 <50e44bcd-c08d-f7b0-1dee-c43d100acb76@oracle.com>
 <CAPW48sqpRYv_0snpjzb1tTFxF2FvEU2Q6PnX3qbZuUU3S9qc3w@mail.gmail.com>
 <bb09ee2e-a337-d953-1882-2838400ff281@oracle.com>
 <CAPW48spucs3ttJRAVwuEbDaFBPHZQo4n-jRcg02jK0nioOc9jg@mail.gmail.com>
Message-ID: <b1d5ff41-44f3-c393-8c41-93975b5a10e3@oracle.com>

On 17/05/2019 18:22, Arthur Eubanks wrote:
> Done, order is protocol family, group/notGroup InetAddress, 
> NetworkInterface, source InetAddress
> http://cr.openjdk.java.net/~aeubanks/8224019/webrev.02/

Looks good to me as well Arthur!

best regard,

-- daniel

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 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 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 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 brian.burkhalter at oracle.com  Fri May 24 23:39:30 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 24 May 2019 16:39:30 -0700
Subject: 8224617: (fs) java/nio/file/FileStore/Basic.java found filesystem
 twice
Message-ID: <D441470B-DBBE-4485-930A-D4AEFEAD1E9D@oracle.com>

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

The proposed change adds a method ?checkMountPoints()? to the FileUtils test library class and in FileStore/Basic.java replaces the use of FileUtils.areFileSystemsAccessible() with the new method. The new method accomplishes the same thing as areFileSystemsAccessible() but additionally checks that there are not duplicate mount points on the system. This latter would indicate a file system misconfiguration which would formerly have appeared as a FileStore failure but with the present change is flagged explicitly as a system configuration problem.

One question about the new code is whether the test at lines 269-279 of the new version of FileUtils should not assume that duplicates occur in succession in the output of ?df.? (This is assumed in Basic in the testing for dulicate FileStores). An alternative would be to accumulate each new non-null entry into a Set and check whether adding the entry actually changed the Set. If it did not then there is a duplicate.

Thanks,

Brian

From Alan.Bateman at oracle.com  Sun May 26 08:58:28 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 26 May 2019 09:58:28 +0100
Subject: 8224617: (fs) java/nio/file/FileStore/Basic.java found filesystem
 twice
In-Reply-To: <D441470B-DBBE-4485-930A-D4AEFEAD1E9D@oracle.com>
References: <D441470B-DBBE-4485-930A-D4AEFEAD1E9D@oracle.com>
Message-ID: <4d6ab69c-a7cd-b3ca-eae7-3b4def6f0d1a@oracle.com>

On 25/05/2019 00:39, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8224617
> http://cr.openjdk.java.net/~bpb/8224617/webrev.00/
>
> The proposed change adds a method ?checkMountPoints()? to the FileUtils test library class and in FileStore/Basic.java replaces the use of FileUtils.areFileSystemsAccessible() with the new method. The new method accomplishes the same thing as areFileSystemsAccessible() but additionally checks that there are not duplicate mount points on the system. This latter would indicate a file system misconfiguration which would formerly have appeared as a FileStore failure but with the present change is flagged explicitly as a system configuration problem.
The approach looks okay although 90s is a long time for a test to wait 
for `df` to complete. Also I'm not sure that checkMountPoints is the 
best name for a method that returns a boolean to indicate if the file 
systems are usable for testing. Something like 
areAllMountPointsAccessible() might be more obvious when reading the test.

>
> One question about the new code is whether the test at lines 269-279 of the new version of FileUtils should not assume that duplicates occur in succession in the output of ?df.? (This is assumed in Basic in the testing for dulicate FileStores). An alternative would be to accumulate each new non-null entry into a Set and check whether adding the entry actually changed the Set. If it did not then there is a duplicate.
>
Are there any scenarios where FileSystem::getFileStores should ignore 
the duplicates?

-Alan

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 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 Alan.Bateman at oracle.com  Sun May 26 18:34:03 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 26 May 2019 19:34:03 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
Message-ID: <f10dd14b-dd36-ecbe-5b09-fc64fee34527@oracle.com>

On 23/05/2019 18:19, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224645
> webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.00/
>
> Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails 
> with NoSuchElementException on Solaris.
>
> java.util.NoSuchElementException
> at java.base/java.util.Spliterators$1Adapter.next(Spliterators.java:688)
> at BasicMulticastTests.main(BasicMulticastTests.java:221)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
>
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
>
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) 
>
> at java.base/java.lang.Thread.run(Thread.java:830)
>
> This changes the test to check if any multicast interfaces are 
> available for IPv4/IPv6 before testing one. This does have the effect 
> of not failing if no multicast interfaces available, which may or may 
> not be desirable.
Adding nio-dev as this is a DatagramChannel test.

Might be a bit more readable if you rename "multicasts" to 
"multicastInterfaces" but otherwise looks okay to me.

-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 pavel.rappo at oracle.com  Mon May 27 10:50:49 2019
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 27 May 2019 11:50:49 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
Message-ID: <4352EE27-1098-4583-B069-40DB4E06515A@oracle.com>

I ran that changed test on Solaris many times. Those runs included some of the
machines on which the previous incarnation failed. The runs were successful.
Other platforms looked fine too.

Looks good.

> On 23 May 2019, at 18:19, Arthur Eubanks <aeubanks at google.com> wrote:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8224645
> webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.00/
> 
> Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException on Solaris.
> 
> java.util.NoSuchElementException 
> at java.base/java.util.Spliterators$1Adapter.next(Spliterators.java:688) 
> at BasicMulticastTests.main(BasicMulticastTests.java:221) 
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
> at java.base/java.lang.reflect.Method.invoke(Method.java:567) 
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) 
> at java.base/java.lang.Thread.run(Thread.java:830)
> 
> This changes the test to check if any multicast interfaces are available for IPv4/IPv6 before testing one. This does have the effect of not failing if no multicast interfaces available, which may or may not be desirable.


From daniel.fuchs at oracle.com  Mon May 27 11:02:56 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 27 May 2019 12:02:56 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
Message-ID: <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>

[adding nio-dev]

On 23/05/2019 18:19, Arthur Eubanks wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8224645
> webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.00/


Hi Arthur,

I would suggest three things:

1. replace `if (....hasNext()) {` with `while (....hasNext()) {`
2. add a counter, and increment it at the end of the `while` block
    to count how many interfaces where successfully tested
3. In the end, just before exiting main, check the value of
    the counter with something like:


```
         if (count == 1) {
             System.out.println("Tested only " + count
                            + " multicast interface");
         } else if (count > 1) {
             System.out.println("Tested " + count
                            + " multicast interfaces");
         } else {
             NetworkConfiguration.printSystemConfiguration(System.err);
             throw new SkippedException(
                       "No multicast interfaces found!");
         }
```

best regards,

-- daniel

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 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 aeubanks at google.com  Tue May 28 17:27:07 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Tue, 28 May 2019 10:27:07 -0700
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java
 fails with NoSuchElementException
In-Reply-To: <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
Message-ID: <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>

>
> Might be a bit more readable if you rename "multicasts" to
> "multicastInterfaces" but otherwise looks okay to me.

Done.


> Hi Arthur,
>
> I would suggest three things:
>
> 1. replace `if (....hasNext()) {` with `while (....hasNext()) {`
> 2. add a counter, and increment it at the end of the `while` block
>     to count how many interfaces where successfully tested
> 3. In the end, just before exiting main, check the value of
>     the counter with something like:
>
>
> ```
>          if (count == 1) {
>              System.out.println("Tested only " + count
>                             + " multicast interface");
>          } else if (count > 1) {
>              System.out.println("Tested " + count
>                             + " multicast interfaces");
>          } else {
>              NetworkConfiguration.printSystemConfiguration(System.err);
>              throw new SkippedException(
>                        "No multicast interfaces found!");
>          }
> ```
>
> best regards,
>
> -- daniel
>
Done.

new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190528/a906bd57/attachment.html>

From brian.burkhalter at oracle.com  Tue May 28 19:45:27 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 28 May 2019 12:45:27 -0700
Subject: 8224617: (fs) java/nio/file/FileStore/Basic.java found filesystem
 twice
In-Reply-To: <4d6ab69c-a7cd-b3ca-eae7-3b4def6f0d1a@oracle.com>
References: <D441470B-DBBE-4485-930A-D4AEFEAD1E9D@oracle.com>
 <4d6ab69c-a7cd-b3ca-eae7-3b4def6f0d1a@oracle.com>
Message-ID: <9EBF8F97-67A3-4F77-91CC-8A0BC898DF7C@oracle.com>


> On May 26, 2019, at 1:58 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 25/05/2019 00:39, Brian Burkhalter wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8224617 <https://bugs.openjdk.java.net/browse/JDK-8224617>
>> http://cr.openjdk.java.net/~bpb/8224617/webrev.00/ <http://cr.openjdk.java.net/~bpb/8224617/webrev.00/>
>> 
>> The proposed change adds a method ?checkMountPoints()? to the FileUtils test library class and in FileStore/Basic.java replaces the use of FileUtils.areFileSystemsAccessible() with the new method. The new method accomplishes the same thing as areFileSystemsAccessible() but additionally checks that there are not duplicate mount points on the system. This latter would indicate a file system misconfiguration which would formerly have appeared as a FileStore failure but with the present change is flagged explicitly as a system configuration problem.
> The approach looks okay although 90s is a long time for a test to wait for `df` to complete.

This is the value that is used in the pre-existing method FileUtils.areFileSystemsAccessible() which was intended mainly to detect whether ?df? hangs. The Process.waitFor() method appears actually to return after about only 0.05 ms at least on my system.

> Also I'm not sure that checkMountPoints is the best name for a method that returns a boolean to indicate if the file systems are usable for testing. Something like areAllMountPointsAccessible() might be more obvious when reading the test.

Yes I changed the name more than once while writing this:

--- a/test/jdk/java/nio/file/FileStore/Basic.java
+++ b/test/jdk/java/nio/file/FileStore/Basic.java
@@ -115,7 +115,7 @@
         /**
          * Test: Enumerate all FileStores
          */
-        if (FileUtils.checkMountPoints()) {
+        if (FileUtils.areAllMountPointsAccessible()) {
             FileStore prev = null;
             for (FileStore store: FileSystems.getDefault().getFileStores()) {
                 System.out.format("%s (name=%s type=%s)\n", store, store.name(),

--- a/test/lib/jdk/test/lib/util/FileUtils.java
+++ b/test/lib/jdk/test/lib/util/FileUtils.java
@@ -256,7 +256,7 @@
      * @throws RuntimeException if there are duplicate mount points or some
      * other execution problem occurs
      */
-    public static boolean checkMountPoints() {
+    public static boolean areAllMountPointsAccessible() {
         final AtomicBoolean areMountPointsOK = new AtomicBoolean(true);
         if (!IS_WINDOWS) {
             Thread thr = new Thread(() -> {


>> One question about the new code is whether the test at lines 269-279 of the new version of FileUtils should not assume that duplicates occur in succession in the output of ?df.? (This is assumed in Basic in the testing for dulicate FileStores). An alternative would be to accumulate each new non-null entry into a Set and check whether adding the entry actually changed the Set. If it did not then there is a duplicate.
>> 
> Are there any scenarios where FileSystem::getFileStores should ignore the duplicates?

It is not specified whether it does or does not as far as I can see. The test FileStore/Basic historically only flags duplicates if they are successors in the FileStore iteration. The order of the elements in the iteration is undefined according to the specification however. I would think that either duplicates should be allowed in the iteration or if they are not allowed then the error should be independent of their order. In either of these cases the test has been wrong and still is.

Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190528/553d2006/attachment-0001.html>

From Alan.Bateman at oracle.com  Wed May 29 06:29:53 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 07:29:53 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
Message-ID: <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>

On 28/05/2019 18:27, Arthur Eubanks wrote:
> :
>
> new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.01/
The purpose of L237-244 isn't clear. Maybe it's useful to print the 
count of interfaces supporting multicast but it is necessary to throw 
SkipException when the count is 0? For debugging purposes I think it 
would be much prefer if the value of nif were printed before it runs the 
test on the interface. I think that would eliminate the need for the count.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190529/5219852b/attachment.html>

From Alan.Bateman at oracle.com  Wed May 29 06:36:13 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 07:36:13 +0100
Subject: 8224617: (fs) java/nio/file/FileStore/Basic.java found filesystem
 twice
In-Reply-To: <9EBF8F97-67A3-4F77-91CC-8A0BC898DF7C@oracle.com>
References: <D441470B-DBBE-4485-930A-D4AEFEAD1E9D@oracle.com>
 <4d6ab69c-a7cd-b3ca-eae7-3b4def6f0d1a@oracle.com>
 <9EBF8F97-67A3-4F77-91CC-8A0BC898DF7C@oracle.com>
Message-ID: <ef56242e-c7a1-4bfd-8914-9af84005e0de@oracle.com>

On 28/05/2019 20:45, Brian Burkhalter wrote:
>
> Yes I changed the name more than once while writing this:
areAllMountPointsAccessible seems okay.

>
> It is not specified whether it does or does not as far as I can see. 
> The test FileStore/Basic historically only flags duplicates if they 
> are successors in the FileStore iteration. The order of the elements 
> in the iteration is undefined according to the specification however. 
> I would think that either duplicates should be allowed in the 
> iteration or if they are not allowed then the error should be 
> independent of their order. In either of these cases the test has been 
> wrong and still is.
>
I think we'll need to do a bit more investigation on this as 
FileSystem::getFileStores shouldn't have duplicates (and I think the 
test was checking for that). So I think we need to dig into how we are 
ending up with duplicates in the mount table and then decide if they 
need to be filtered or not.

-Alan

From daniel.fuchs at oracle.com  Wed May 29 07:08:47 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 May 2019 08:08:47 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
Message-ID: <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>

Hi Alan,

On 29/05/2019 07:29, Alan Bateman wrote:
> The purpose of L237-244 isn't clear. Maybe it's useful to print the 
> count of interfaces supporting multicast but it is necessary to throw 
> SkipException when the count is 0? For debugging purposes I think it 
> would be much prefer if the value of nif were printed before it runs the 
> test on the interface. I think that would eliminate the need for the count.

The idea is that if a test machine has no IPv4 and no
IPv6 multicast interfaces then it's probably misconfigured.

Also if a regression is introduced that causes this to happen,
then we'd probably want to see it.

AFAIK the SkippedException is a good match for that.

best regard,

-- daniel

From Alan.Bateman at oracle.com  Wed May 29 07:23:24 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 08:23:24 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
Message-ID: <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>

On 29/05/2019 08:08, Daniel Fuchs wrote:
>
> The idea is that if a test machine has no IPv4 and no
> IPv6 multicast interfaces then it's probably misconfigured.
>
> Also if a regression is introduced that causes this to happen,
> then we'd probably want to see it.
>
> AFAIK the SkippedException is a good match for that.
>
I don't like the dependency on jtreg.SkippedException but if you find it 
useful then okay. I assume we can remove the other messages added at the 
end as they are less useful than printing the value of each network 
interface before testing it.

-Alan

From daniel.fuchs at oracle.com  Wed May 29 07:28:15 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 May 2019 08:28:15 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
Message-ID: <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>

On 29/05/2019 08:23, Alan Bateman wrote:
>> AFAIK the SkippedException is a good match for that.
>>
> I don't like the dependency on jtreg.SkippedException but if you find it 
> useful then okay.

Would you prefer to throw AssertionError instead? It's also
a possibility. Chris thought it might be "too strong".

> I assume we can remove the other messages added at the 
> end as they are less useful than printing the value of each network 
> interface before testing it.

Right - printing interfaces before testing them would be useful.
But printing all interfaces if no multicast was found is useful
too - it might help figure out why the test was not run.

best regards,

-- daniel


From Alan.Bateman at oracle.com  Wed May 29 07:40:02 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 08:40:02 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
Message-ID: <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>

On 29/05/2019 08:28, Daniel Fuchs wrote:
>
> Would you prefer to throw AssertionError instead? It's also
> a possibility. Chris thought it might be "too strong".
It might be odd to have a test system configured without multicast 
enabled but it's not wrong. So I think the test should pass.

> :
>
> Right - printing interfaces before testing them would be useful.
> But printing all interfaces if no multicast was found is useful
> too - it might help figure out why the test was not run.
>
I think it would be useful for tests such as this one to print the 
network interface configuration at the start. That might be something 
for a supporting method in jdk.test.lib.NetworkConfiguration (if there 
isn't anything already).

-Alan

From chris.hegarty at oracle.com  Wed May 29 08:19:02 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 29 May 2019 09:19:02 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
Message-ID: <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>


> On 29 May 2019, at 08:40, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 29/05/2019 08:28, Daniel Fuchs wrote:
>> 
>> Would you prefer to throw AssertionError instead? It's also
>> a possibility. Chris thought it might be "too strong".
> It might be odd to have a test system configured without multicast enabled but it's not wrong. So I think the test should pass.

Right, that was my thought too.

It is useful to be able to scan a collection of jtr files and
differentiate between a test that did nothing ( and passed silently )
from a test that actually did do something. Using SkippedException will
make this task a little easier - which could then be used to identify
possibly misconfigured systems.

The test already has a test library dependency, so the addition of 
SkippedException does not introduce any new significant burden
for standalone testing.

>> :
>> 
>> Right - printing interfaces before testing them would be useful.
>> But printing all interfaces if no multicast was found is useful
>> too - it might help figure out why the test was not run.
>> 
> I think it would be useful for tests such as this one to print the network interface configuration at the start. That might be something for a supporting method in jdk.test.lib.NetworkConfiguration (if there isn't anything already).

This already exists.
NetworkConfiguration.printSystemConfiguration(PrintStream)

I think there needs to be a balance between readability and
diagnosability. It's often the case that much debugging statements are
added to a test when investigating a failure. It's good to have some
breadcrumbs to follow when things go wrong, but it should not complicate
the code too much.

It might be useful to just unconditionally printSystemConfiguration, at
the start of the test, and then the nic in use for each iteration. I 
don't think anything more is needed.

-Chris.



From daniel.fuchs at oracle.com  Wed May 29 09:32:29 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 May 2019 10:32:29 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
 <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
Message-ID: <e478376e-09a5-8ca5-6cbe-7575fbbf416e@oracle.com>

On 29/05/19 09:19, Chris Hegarty wrote:
> This already exists.
> NetworkConfiguration.printSystemConfiguration(PrintStream)
> 
> I think there needs to be a balance between readability and
> diagnosability. It's often the case that much debugging statements are
> added to a test when investigating a failure. It's good to have some
> breadcrumbs to follow when things go wrong, but it should not complicate
> the code too much.
> 
> It might be useful to just unconditionally printSystemConfiguration, at
> the start of the test, and then the nic in use for each iteration. I
> don't think anything more is needed.

+1

For the record I ran Arthur's webrev.01 through our test system and
got no failures (just tested BasicMulticastTests.java).

best regards,

-- daniel

From Alan.Bateman at oracle.com  Wed May 29 09:57:43 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 10:57:43 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
 <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
Message-ID: <0f8a1d9a-47de-5ea4-4912-9720f6231ee9@oracle.com>

On 29/05/2019 09:19, Chris Hegarty wrote:
> :
> The test already has a test library dependency, so the addition of
> SkippedException does not introduce any new significant burden
> for standalone testing.
There are a couple of tests in the nio/channels area that are useful to 
run outside of the jtreg environment when debugging on specific 
machines. BasicMulticastTests is one of those tests (on several 
occasions I've had to remove the dependent on the test libs too).

> :
>
> It might be useful to just unconditionally printSystemConfiguration, at
> the start of the test, and then the nic in use for each iteration.
That would be good. There may be a few other tests where we do the same 
(when they are next edited).

-Alan

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 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 aeubanks at google.com  Wed May 29 16:27:45 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 29 May 2019 09:27:45 -0700
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java
 fails with NoSuchElementException
In-Reply-To: <e478376e-09a5-8ca5-6cbe-7575fbbf416e@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
 <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
 <e478376e-09a5-8ca5-6cbe-7575fbbf416e@oracle.com>
Message-ID: <CAPW48soDZ8i6qsvmfqikPbEAjbeFAYuEVobOM3R=fMqsDpZFLw@mail.gmail.com>

>
> For the record I ran Arthur's webrev.01 through our test system and
> got no failures (just tested BasicMulticastTests.java).
>
> best regards,
>
> -- daniel
>
Thanks.

Moved NetworkConfiguration.printSystemConfiguration() to the beginning,
removed counting and printing the number of interfaces/throwing
SkippedException.
new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.02/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190529/bac5b470/attachment.html>

From Alan.Bateman at oracle.com  Wed May 29 19:56:20 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 May 2019 20:56:20 +0100
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
 NoSuchElementException
In-Reply-To: <CAPW48soDZ8i6qsvmfqikPbEAjbeFAYuEVobOM3R=fMqsDpZFLw@mail.gmail.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
 <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
 <e478376e-09a5-8ca5-6cbe-7575fbbf416e@oracle.com>
 <CAPW48soDZ8i6qsvmfqikPbEAjbeFAYuEVobOM3R=fMqsDpZFLw@mail.gmail.com>
Message-ID: <dc0c31e9-c285-687a-9add-5b2c7362e66c@oracle.com>

On 29/05/2019 17:27, Arthur Eubanks wrote:
> :
>
> Moved?NetworkConfiguration.printSystemConfiguration() to the 
> beginning, removed counting and printing the number of 
> interfaces/throwing SkippedException.
> new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.02/
This looks okay to me, the only thing is that the NetworkConfiguration 
is sent to System.err whereas the test proper sends its output to 
System.out. Can you check the .jtr file to see how it looks? I suspect 
it may be easier to read if you send the network configuration to 
System.out.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190529/5f168780/attachment-0001.html>

From aeubanks at google.com  Wed May 29 20:08:40 2019
From: aeubanks at google.com (Arthur Eubanks)
Date: Wed, 29 May 2019 13:08:40 -0700
Subject: [RFR] 8224645: Test
 java/nio/channels/DatagramChannel/BasicMulticastTests.java
 fails with NoSuchElementException
In-Reply-To: <dc0c31e9-c285-687a-9add-5b2c7362e66c@oracle.com>
References: <CAPW48spnsRE_kSZr36PjT8jCM4vnbqpgdBJ6j3iP-v+AEkWtiA@mail.gmail.com>
 <d2bc9923-d19c-7f08-d49e-9a4484b6d4db@oracle.com>
 <CAPW48soESocW0+3u7fKFTXG6S0vdwwQH-Zc8=TWy4naCLiuZLg@mail.gmail.com>
 <8fa9d55a-520e-df06-1d5d-566ef39fa992@oracle.com>
 <27fa2523-2f81-10c9-0688-3de42af96b02@oracle.com>
 <7e2ead05-f49c-8ca3-9bd5-b6d1e3e6ec21@oracle.com>
 <bd74910b-ea21-6bae-9522-b06d31c5d98b@oracle.com>
 <548abdef-3f06-0947-2e00-e05cc59f626f@oracle.com>
 <CC986E22-DB63-421D-8D33-FD3743C08E43@oracle.com>
 <e478376e-09a5-8ca5-6cbe-7575fbbf416e@oracle.com>
 <CAPW48soDZ8i6qsvmfqikPbEAjbeFAYuEVobOM3R=fMqsDpZFLw@mail.gmail.com>
 <dc0c31e9-c285-687a-9add-5b2c7362e66c@oracle.com>
Message-ID: <CAPW48spnqhYqXwKhh3iUPMOr=cP-=92q+Q46PeSrKcwGczFPNQ@mail.gmail.com>

>
> Moved NetworkConfiguration.printSystemConfiguration() to the beginning,
> removed counting and printing the number of interfaces/throwing
> SkippedException.
> new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.02/
>
> This looks okay to me, the only thing is that the NetworkConfiguration is
> sent to System.err whereas the test proper sends its output to System.out.
> Can you check the .jtr file to see how it looks? I suspect it may be easier
> to read if you send the network configuration to System.out.
>
> -Alan
>
I don't think it's a big difference either way, but changed it to
System.out. Also added some extra info to the "Exception Tests" log to show
the addresses it's testing. Now it looks like:

----------System.out:(33/801)----------
*** all system network interface configuration ***
Display name: eth0
Name: eth0
InetAddress: /2620:15c:2ce:200:fb70:ba8c:5c39:dd96%eth0
InetAddress: /fe80:0:0:0:3745:855d:754c:c782%eth0
InetAddress: /100.117.216.36
Up? true
Loopback? false
PointToPoint? false
Supports multicast? true
Virtual? false
Hardware address: [112, 90, 15, 47, 36, 82]
MTU: 1500
Index: 2

Display name: lo
Name: lo
InetAddress: /0:0:0:0:0:0:0:1%lo
InetAddress: /127.0.0.1
Up? true
Loopback? true
PointToPoint? false
Supports multicast? false
Virtual? false
Hardware address: null
MTU: 65536
Index: 1

*** end ***
MembershipKey test using 225.4.5.6 @ eth0
Exception Tests using 225.4.5.6, 1.2.3.4 @ eth0
MembershipKey test using ff02:0:0:0:0:0:0:a @ eth0
Exception Tests using ff02:0:0:0:0:0:0:a, fe80:0:0:0:0:0:0:1234 @ eth0
----------System.err:(1/15)----------
STATUS:Passed.

http://cr.openjdk.java.net/~aeubanks/8224645/webrev.03
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190529/8b5161d7/attachment.html>

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190531/b20a47a8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190531/b20a47a8/oracle_sig_logo-0001.gif>