From Alan.Bateman at oracle.com Mon May 2 09:26:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 May 2016 10:26:15 +0100 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: References: <57238688.1040500@oracle.com> <57238CBD.8080804@oracle.com> <57239459.1030704@oracle.com> <572397DC.5050004@oracle.com> Message-ID: <57271D37.2070309@oracle.com> On 29/04/2016 18:39, Francis Galiegue wrote: > : > > Still, "walking" archives using JSR 203 is great, and zip being there, > although "unspecified", if it were solid enough for daily use, that > would be a great demonstration of what JSR 203 is really capable of. > > The zip provider was very much a demo provider initially but there is quite a bit of usage so we do want to make it solid. Also as Sherman pointed out, javac has moved completely to the new file system API and so is very reliant on the jrtfs and zipfs providers. This is helping to shaking out a few performance issues with zipfs in particular. -Alan From fgaliegue at gmail.com Mon May 2 13:58:49 2016 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 2 May 2016 15:58:49 +0200 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: <57271D37.2070309@oracle.com> References: <57238688.1040500@oracle.com> <57238CBD.8080804@oracle.com> <57239459.1030704@oracle.com> <572397DC.5050004@oracle.com> <57271D37.2070309@oracle.com> Message-ID: Hello again, On Mon, May 2, 2016 at 11:26 AM, Alan Bateman wrote: [...] > > The zip provider was very much a demo provider initially but there is quite > a bit of usage so we do want to make it solid. Also as Sherman pointed out, > javac has moved completely to the new file system API and so is very reliant > on the jrtfs and zipfs providers. This is helping to shaking out a few > performance issues with zipfs in particular. > jrtfs? As in this? https://github.com/forax/jigsaw-jrtfs Regards, -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/fge/grappa From Alan.Bateman at oracle.com Mon May 2 15:22:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 May 2016 16:22:46 +0100 Subject: Unable to create a zip file using the Zip filesystem provider anymore? In-Reply-To: References: <57238688.1040500@oracle.com> <57238CBD.8080804@oracle.com> <57239459.1030704@oracle.com> <572397DC.5050004@oracle.com> <57271D37.2070309@oracle.com> Message-ID: <572770C6.2080008@oracle.com> On 02/05/2016 14:58, Francis Galiegue wrote: > Hello again, > > On Mon, May 2, 2016 at 11:26 AM, Alan Bateman wrote: > [...] >> The zip provider was very much a demo provider initially but there is quite >> a bit of usage so we do want to make it solid. Also as Sherman pointed out, >> javac has moved completely to the new file system API and so is very reliant >> on the jrtfs and zipfs providers. This is helping to shaking out a few >> performance issues with zipfs in particular. >> > jrtfs? As in this? https://github.com/forax/jigsaw-jrtfs > I think that project was a one-off backport that R?mi did. The "jrt" file system provider was one we added via JEP 220 [1] in JDK 9 to support access to the runtime image. Most of the IDEs have early access support that uses this to access the classes/resources for projects that target JDK 9. -Alan [1] http://openjdk.java.net/jeps/220 From Alan.Bateman at oracle.com Mon May 2 19:23:52 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 May 2016 20:23:52 +0100 Subject: [PATCH] 8153925: WindowsWatchService hangs on GetOverlappedResult and locks directory In-Reply-To: <571F40C3.5020509@redhat.com> References: <570980DE.2080804@redhat.com> <5709EFF2.6010301@oracle.com> <570A2B60.3030508@redhat.com> <570BC513.1010609@oracle.com> <570BCC4B.5030703@redhat.com> <571F40C3.5020509@redhat.com> Message-ID: <5727A948.1090003@oracle.com> On 26/04/2016 11:19, Alex Kashchenko wrote: > > Please review the updated webrev for jdk8u-dev repo - > http://cr.openjdk.java.net/~akasko/jdk8u/8153925/webrev.01/ > > Patch is changed to skip CancelIo call. > > Test is rewritten to be closer to LotsOfCancels test and included into > webrev. > The updated patch to WindowsWatchService looks good. I've re-based the patch against jdk9/dev because all changes that aren't JDK 8 update specific are required to be fixed in JDK 9 first. Once it has a baked for a bit then we can look to get it approved for jdk8u-dev. The updated test looks much better too but could do with a few small changes to bring it closer in style to the existing tests. Timeouts can be problematic sometimes, esp. when running tests concurrently but here I can we can just wait for the tasks to complete without any timeout One minor point is that there is no need to register for OVERFLOW. Here's the updated webrev with the changes to the test (no changes to your patch to WindowsWatchService). If you are okay with this then I push it to jdk9/dev. http://cr.openjdk.java.net/~alanb/8153925/webrev/ -Alan From akashche at redhat.com Mon May 2 19:49:18 2016 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 02 May 2016 20:49:18 +0100 Subject: [PATCH] 8153925: WindowsWatchService hangs on GetOverlappedResult and locks directory In-Reply-To: <5727A948.1090003@oracle.com> References: <570980DE.2080804@redhat.com> <5709EFF2.6010301@oracle.com> <570A2B60.3030508@redhat.com> <570BC513.1010609@oracle.com> <570BCC4B.5030703@redhat.com> <571F40C3.5020509@redhat.com> <5727A948.1090003@oracle.com> Message-ID: <5727AF3E.2050600@redhat.com> On 05/02/2016 08:23 PM, Alan Bateman wrote: > > On 26/04/2016 11:19, Alex Kashchenko wrote: >> >> Please review the updated webrev for jdk8u-dev repo - >> http://cr.openjdk.java.net/~akasko/jdk8u/8153925/webrev.01/ >> >> Patch is changed to skip CancelIo call. >> >> Test is rewritten to be closer to LotsOfCancels test and included into >> webrev. >> > The updated patch to WindowsWatchService looks good. > > I've re-based the patch against jdk9/dev because all changes that aren't > JDK 8 update specific are required to be fixed in JDK 9 first. Once it > has a baked for a bit then we can look to get it approved for jdk8u-dev. > > The updated test looks much better too but could do with a few small > changes to bring it closer in style to the existing tests. Timeouts can > be problematic sometimes, esp. when running tests concurrently but here > I can we can just wait for the tasks to complete without any timeout One > minor point is that there is no need to register for OVERFLOW. > > Here's the updated webrev with the changes to the test (no changes to > your patch to WindowsWatchService). If you are okay with this then I > push it to jdk9/dev. > > http://cr.openjdk.java.net/~alanb/8153925/webrev/ Updated test looks fine to me, I checked that it reproduces the problem in the same environment. Thanks. -- -Alex From brian.burkhalter at oracle.com Tue May 3 22:13:01 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 3 May 2016 15:13:01 -0700 Subject: JDK 9 RFR of 8153192: (se) Selector.select(long) uses wrong timeout after EINTR (lnx) Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8153192 Patch: http://cr.openjdk.java.net/~bpb/8153192/webrev.00/ Pass what remains of the initial timeout to epoll_wait(2) (Linux) and ioctl(7d) (Solaris) instead of the original un-decremented timeout value. The problem was initially called to attention by [1]. The other related files of this nature do not seem to contain this error.. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/nio-dev/2016-March/003612.html From Alan.Bateman at oracle.com Wed May 4 11:58:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 12:58:45 +0100 Subject: JDK 9 RFR of 8153192: (se) Selector.select(long) uses wrong timeout after EINTR (lnx) In-Reply-To: References: Message-ID: <5729E3F5.6030603@oracle.com> On 03/05/2016 23:13, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8153192 > Patch: http://cr.openjdk.java.net/~bpb/8153192/webrev.00/ > > Pass what remains of the initial timeout to epoll_wait(2) (Linux) and ioctl(7d) (Solaris) instead of the original un-decremented timeout value. The problem was initially called to attention by [1]. > > The other related files of this nature do not seem to contain this error.. > > This looks okay to me. -Alan. From Roger.Riggs at Oracle.com Wed May 4 14:37:04 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 4 May 2016 10:37:04 -0400 Subject: JDK 9 RFR of 8153192: (se) Selector.select(long) uses wrong timeout after EINTR (lnx) In-Reply-To: References: Message-ID: <5f3e5c52-7514-26e0-0f19-e1a828febe0e@Oracle.com> Hi Brian, Looks ok, Roger On 5/3/2016 6:13 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8153192 > Patch: http://cr.openjdk.java.net/~bpb/8153192/webrev.00/ > > Pass what remains of the initial timeout to epoll_wait(2) (Linux) and ioctl(7d) (Solaris) instead of the original un-decremented timeout value. The problem was initially called to attention by [1]. > > The other related files of this nature do not seem to contain this error.. > > Thanks, > > Brian > > [1] http://mail.openjdk.java.net/pipermail/nio-dev/2016-March/003612.html From huaming.li at oracle.com Fri May 6 06:58:55 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 6 May 2016 14:58:55 +0800 Subject: JDK 9 RFR of JDK-8156002: java/nio/channels/SocketChannel/AdaptSocket.java Fails in Mesos on OSX Message-ID: <572C40AF.3070900@oracle.com> Please review the patch for java/nio/channels/SocketChannel/AdaptSocket.java Fails in Mesos on OSX. Root Cause: it's kind of race condition due to linger time and timeout time. Even though timeout(10ms) is far less than linger time(100ms), but in some condition the linger time is still not long enough. Suggested Fix: create a NoResponseServer which will accept connection but never response to any input. bug: https://bugs.openjdk.java.net/browse/JDK-8156002 webrev: http://cr.openjdk.java.net/~mli/8156002/webrev.01/ Thank you -Hamlin From daniel.fuchs at oracle.com Fri May 6 07:45:26 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 6 May 2016 09:45:26 +0200 Subject: JDK 9 RFR of JDK-8156002: java/nio/channels/SocketChannel/AdaptSocket.java Fails in Mesos on OSX In-Reply-To: <572C40AF.3070900@oracle.com> References: <572C40AF.3070900@oracle.com> Message-ID: <3b07976d-b642-6035-014d-b35142362d7c@oracle.com> On 5/6/16 8:58 AM, Hamlin Li wrote: > Please review the patch for > java/nio/channels/SocketChannel/AdaptSocket.java Fails in Mesos on OSX. > > Root Cause: it's kind of race condition due to linger time and timeout > time. Even though timeout(10ms) is far less than linger time(100ms), but > in some condition the linger time is still not long enough. > Suggested Fix: create a NoResponseServer which will accept connection > but never response to any input. > > bug: https://bugs.openjdk.java.net/browse/JDK-8156002 > webrev: http://cr.openjdk.java.net/~mli/8156002/webrev.01/ Hi Hamlin, The idea is very good, but I wonder about the implementation. calling super(Long.MAX_VALUE) will make the NoResponseServer wait forever in the accept loop line 223 - while I think that for the spirit of this test we want the accept loop to proceed normally, but linger instead in the connection thread, line 372. Or am I mistaken? best regards, -- daniel > > Thank you > -Hamlin From huaming.li at oracle.com Fri May 6 12:14:14 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 6 May 2016 20:14:14 +0800 Subject: JDK 9 RFR of JDK-8156002: java/nio/channels/SocketChannel/AdaptSocket.java Fails in Mesos on OSX In-Reply-To: <3b07976d-b642-6035-014d-b35142362d7c@oracle.com> References: <572C40AF.3070900@oracle.com> <3b07976d-b642-6035-014d-b35142362d7c@oracle.com> Message-ID: <572C8A96.9030807@oracle.com> On 2016/5/6 15:45, Daniel Fuchs wrote: > On 5/6/16 8:58 AM, Hamlin Li wrote: >> Please review the patch for >> java/nio/channels/SocketChannel/AdaptSocket.java Fails in Mesos on OSX. >> >> Root Cause: it's kind of race condition due to linger time and timeout >> time. Even though timeout(10ms) is far less than linger time(100ms), but >> in some condition the linger time is still not long enough. >> Suggested Fix: create a NoResponseServer which will accept connection >> but never response to any input. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8156002 >> webrev: http://cr.openjdk.java.net/~mli/8156002/webrev.01/ > > Hi Hamlin, > > The idea is very good, but I wonder about the implementation. > calling super(Long.MAX_VALUE) will make the NoResponseServer > wait forever in the accept loop line 223 - while I think that > for the spirit of this test we want the accept loop to > proceed normally, but linger instead in the connection > thread, line 372. Hi Daniel, Thanks for reviewing. Please let me clarify. Yes, NoResponseServer will wait forever in the accept loop line 223 (in TestServers.java). But, 1. As we only need only one connection, so it does not matter, NoResponseServer will accept one connection at line 222 (in TestServers.java) and not response to any input from the client connection. 2. Even if there are 2 or more connections coming, NoResponseServer will still work as expected. In java code level as you mentioned it will wait forever in the accept loop at line 223 (in TestServers.java), but real TCP accept operation will be finished by TCP stack once the ServerSocket object is constructed, so real TCP accept operation will not be blocked at line 223 (in TestServers.java). So although NoResponseServer will wait forever at line 223 (in TestServers.java), it can accept multiple connections. The test pass JPRT: http://scaaa637.us.oracle.com/archive/2016/05/2016-05-06-070151.oracle.dev/. It works well even if line 175 (in AdaptSocket.java) is looped for 100 times. Thank you -Hamlin > > Or am I mistaken? > > best regards, > > -- daniel > > From daniel.fuchs at oracle.com Fri May 6 12:24:42 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 6 May 2016 14:24:42 +0200 Subject: JDK 9 RFR of JDK-8156002: java/nio/channels/SocketChannel/AdaptSocket.java Fails in Mesos on OSX In-Reply-To: <572C8A96.9030807@oracle.com> References: <572C40AF.3070900@oracle.com> <3b07976d-b642-6035-014d-b35142362d7c@oracle.com> <572C8A96.9030807@oracle.com> Message-ID: <7e482a16-44f3-8772-d177-c66797026495@oracle.com> On 06/05/16 14:14, Hamlin Li wrote: > On 2016/5/6 15:45, Daniel Fuchs wrote: >> On 5/6/16 8:58 AM, Hamlin Li wrote: >>> Please review the patch for >>> java/nio/channels/SocketChannel/AdaptSocket.java Fails in Mesos on OSX. >>> >>> Root Cause: it's kind of race condition due to linger time and timeout >>> time. Even though timeout(10ms) is far less than linger time(100ms), but >>> in some condition the linger time is still not long enough. >>> Suggested Fix: create a NoResponseServer which will accept connection >>> but never response to any input. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8156002 >>> webrev: http://cr.openjdk.java.net/~mli/8156002/webrev.01/ >> >> Hi Hamlin, >> >> The idea is very good, but I wonder about the implementation. >> calling super(Long.MAX_VALUE) will make the NoResponseServer >> wait forever in the accept loop line 223 - while I think that >> for the spirit of this test we want the accept loop to >> proceed normally, but linger instead in the connection >> thread, line 372. > Hi Daniel, > > Thanks for reviewing. Please let me clarify. > Yes, NoResponseServer will wait forever in the accept loop line 223 (in > TestServers.java). But, > 1. As we only need only one connection, so it does not matter, > NoResponseServer will accept one connection at line 222 (in > TestServers.java) and not response to any input from the client connection. > 2. Even if there are 2 or more connections coming, NoResponseServer > will still work as expected. In java code level as you mentioned it will > wait forever in the accept loop at line 223 (in TestServers.java), but > real TCP accept operation will be finished by TCP stack once the > ServerSocket object is constructed, so real TCP accept operation will > not be blocked at line 223 (in TestServers.java). So although > NoResponseServer will wait forever at line 223 (in TestServers.java), it > can accept multiple connections. > > The test pass JPRT: > http://scaaa637.us.oracle.com/archive/2016/05/2016-05-06-070151.oracle.dev/. > > It works well even if line 175 (in AdaptSocket.java) is looped for 100 > times. Oh - right - the first connection will be accepted before the server lingers and there is only one connection - so it does not matter where it actually lingers. OK then, +1 me :-) best regards, -- daniel > > Thank you > -Hamlin >> >> Or am I mistaken? >> >> best regards, >> >> -- daniel >> >> > From pavel.rappo at oracle.com Thu May 12 10:48:10 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 12 May 2016 11:48:10 +0100 Subject: 8150785: (bf) Hoist slice and duplicate methods up to java.nio.Buffer In-Reply-To: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: <876B555F-7F53-444A-B162-BD8B71FB8FED@oracle.com> Hi, Could you please review my change for JDK-8150785? http://cr.openjdk.java.net/~prappo/8150785/webrev.02/ http://cr.openjdk.java.net/~prappo/8150785/specdiff.02/java/nio/package-summary.html Thanks, -Pavel From Alan.Bateman at oracle.com Thu May 12 13:27:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 May 2016 14:27:13 +0100 Subject: 8150785: (bf) Hoist slice and duplicate methods up to java.nio.Buffer In-Reply-To: <876B555F-7F53-444A-B162-BD8B71FB8FED@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <876B555F-7F53-444A-B162-BD8B71FB8FED@oracle.com> Message-ID: <573484B1.7070306@oracle.com> On 12/05/2016 11:48, Pavel Rappo wrote: > Hi, > > Could you please review my change for JDK-8150785? > > http://cr.openjdk.java.net/~prappo/8150785/webrev.02/ > http://cr.openjdk.java.net/~prappo/8150785/specdiff.02/java/nio/package-summary.html > This looks okay to me. As you know, there are other methods that could be hoisted to Buffer too but what you have looks good. -Alan From Roger.Riggs at Oracle.com Thu May 12 14:57:45 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 12 May 2016 10:57:45 -0400 Subject: 8150785: (bf) Hoist slice and duplicate methods up to java.nio.Buffer In-Reply-To: <573484B1.7070306@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <876B555F-7F53-444A-B162-BD8B71FB8FED@oracle.com> <573484B1.7070306@oracle.com> Message-ID: <990ac3d8-89f2-ebc2-8a3a-2914415017fe@Oracle.com> Hi Pavel, A test of the new hoisted methods would be a good addition. Roger On 5/12/2016 9:27 AM, Alan Bateman wrote: > On 12/05/2016 11:48, Pavel Rappo wrote: >> Hi, >> >> Could you please review my change for JDK-8150785? >> >> http://cr.openjdk.java.net/~prappo/8150785/webrev.02/ >> http://cr.openjdk.java.net/~prappo/8150785/specdiff.02/java/nio/package-summary.html >> > This looks okay to me. As you know, there are other methods that could > be hoisted to Buffer too but what you have looks good. > > -Alan From chris.hegarty at oracle.com Thu May 12 15:02:36 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 May 2016 16:02:36 +0100 Subject: 8150785: (bf) Hoist slice and duplicate methods up to java.nio.Buffer In-Reply-To: <573484B1.7070306@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <876B555F-7F53-444A-B162-BD8B71FB8FED@oracle.com> <573484B1.7070306@oracle.com> Message-ID: <8E9C0DF8-7105-4DBB-BDAF-2E2F1D693A62@oracle.com> On 12 May 2016, at 14:27, Alan Bateman wrote: > On 12/05/2016 11:48, Pavel Rappo wrote: >> Hi, >> >> Could you please review my change for JDK-8150785? >> >> http://cr.openjdk.java.net/~prappo/8150785/webrev.02/ >> http://cr.openjdk.java.net/~prappo/8150785/specdiff.02/java/nio/package-summary.html >> > This looks okay to me. As you know, there are other methods that could be hoisted to Buffer too but what you have looks good. +1. -Chris. From pavel.rappo at oracle.com Fri May 13 11:39:33 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 13 May 2016 12:39:33 +0100 Subject: RFR 8156931: java.nio.Buffer tests cleanup In-Reply-To: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> Message-ID: <16AC42E5-5215-4A18-8768-6F022E3FBDAF@oracle.com> Hi, Could you please review my change for JDK-8156931? http://cr.openjdk.java.net/~prappo/8156931/webrev.00/ It's a pass through before updating tests for "(bf) Hoist slice and duplicate methods up to java.nio.Buffer" https://bugs.openjdk.java.net/browse/JDK-8150785 Thanks, -Pavel From Alan.Bateman at oracle.com Fri May 13 12:00:41 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 May 2016 13:00:41 +0100 Subject: RFR 8156931: java.nio.Buffer tests cleanup In-Reply-To: <16AC42E5-5215-4A18-8768-6F022E3FBDAF@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <16AC42E5-5215-4A18-8768-6F022E3FBDAF@oracle.com> Message-ID: <5735C1E9.6090506@oracle.com> On 13/05/2016 12:39, Pavel Rappo wrote: > Hi, > > Could you please review my change for JDK-8156931? > > http://cr.openjdk.java.net/~prappo/8156931/webrev.00/ > > It's a pass through before updating tests for "(bf) Hoist slice and duplicate > methods up to java.nio.Buffer" > > https://bugs.openjdk.java.net/browse/JDK-8150785 > This looks okay except that I wouldn't bother with the extra braces. Would you mind fixing testAlign while you are there? The tests for this introduce very long lines and so means annoying horizontal scrolling when looking at the diffs. -Alan From pavel.rappo at oracle.com Fri May 13 14:19:33 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 13 May 2016 15:19:33 +0100 Subject: RFR 8156931: java.nio.Buffer tests cleanup In-Reply-To: <5735C1E9.6090506@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <16AC42E5-5215-4A18-8768-6F022E3FBDAF@oracle.com> <5735C1E9.6090506@oracle.com> Message-ID: <093F95EE-C9EC-4170-A664-1BC67B89EDB8@oracle.com> Hi Alan, Thanks for looking into this! I have fixed excessively long lines and removed clarifying curly braces where not needed. http://cr.openjdk.java.net/~prappo/8156931/webrev.01/ > On 13 May 2016, at 13:00, Alan Bateman wrote: > > On 13/05/2016 12:39, Pavel Rappo wrote: >> Hi, >> >> Could you please review my change for JDK-8156931? >> >> http://cr.openjdk.java.net/~prappo/8156931/webrev.00/ >> >> It's a pass through before updating tests for "(bf) Hoist slice and duplicate >> methods up to java.nio.Buffer" >> >> https://bugs.openjdk.java.net/browse/JDK-8150785 >> > This looks okay except that I wouldn't bother with the extra braces. > > Would you mind fixing testAlign while you are there? The tests for this introduce very long lines and so means annoying horizontal scrolling when looking at the diffs. > > -Alan From Alan.Bateman at oracle.com Sat May 14 08:42:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 May 2016 09:42:12 +0100 Subject: RFR 8156931: java.nio.Buffer tests cleanup In-Reply-To: <093F95EE-C9EC-4170-A664-1BC67B89EDB8@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <16AC42E5-5215-4A18-8768-6F022E3FBDAF@oracle.com> <5735C1E9.6090506@oracle.com> <093F95EE-C9EC-4170-A664-1BC67B89EDB8@oracle.com> Message-ID: <5736E4E4.1030103@oracle.com> On 13/05/2016 15:19, Pavel Rappo wrote: > Hi Alan, > > Thanks for looking into this! I have fixed excessively long lines and removed > clarifying curly braces where not needed. > > http://cr.openjdk.java.net/~prappo/8156931/webrev.01/ > > This looks a good cleanup with some additional test coverage too. -Alan From pavel.rappo at oracle.com Mon May 16 10:10:05 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 16 May 2016 11:10:05 +0100 Subject: 8150785: (bf) Hoist slice and duplicate methods up to java.nio.Buffer In-Reply-To: <990ac3d8-89f2-ebc2-8a3a-2914415017fe@Oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <876B555F-7F53-444A-B162-BD8B71FB8FED@oracle.com> <573484B1.7070306@oracle.com> <990ac3d8-89f2-ebc2-8a3a-2914415017fe@Oracle.com> Message-ID: <3C351AE3-DC87-4F75-9CFD-5D5CF8942535@oracle.com> Hi, The webrev has been updated in-place http://cr.openjdk.java.net/~prappo/8150785/webrev.02/ to address Roger's suggestion on tests. I must admit `slice` and `duplicate` (and `asReadOnly` for that matter) functionality hasn't been covered well. So I've improved it a bit [1]. Thanks, -Pavel -------------------------------------------------------------------------------- [1] As I understand, some tests generated by `Order-X.java.template` for each Buffer subtype 56 ck$Type$Buffer(ByteBuffer.allocate(LENGTH).as$Type$Buffer(), be); 57 ck$Type$Buffer(ByteBuffer.allocateDirect(LENGTH).as$Type$Buffer(), be); are better covered in and do belong to Order.java 45 private static void ckViews(ByteBuffer bb) { 46 ck(bb.asCharBuffer().order(), bb.order()); 47 ck(bb.asShortBuffer().order(), bb.order()); 48 ck(bb.asIntBuffer().order(), bb.order()); 49 ck(bb.asLongBuffer().order(), bb.order()); 50 ck(bb.asFloatBuffer().order(), bb.order()); 51 ck(bb.asDoubleBuffer().order(), bb.order()); 52 } After all, these tests are checking order contracts of view methods defined in ByteBuffer, which Order.java corresponds to. > On 12 May 2016, at 15:57, Roger Riggs wrote: > > Hi Pavel, > > A test of the new hoisted methods would be a good addition. > > Roger > > > > On 5/12/2016 9:27 AM, Alan Bateman wrote: >> On 12/05/2016 11:48, Pavel Rappo wrote: >>> Hi, >>> >>> Could you please review my change for JDK-8150785? >>> >>> http://cr.openjdk.java.net/~prappo/8150785/webrev.02/ >>> http://cr.openjdk.java.net/~prappo/8150785/specdiff.02/java/nio/package-summary.html >>> >> This looks okay to me. As you know, there are other methods that could be hoisted to Buffer too but what you have looks good. >> >> -Alan > From Alan.Bateman at oracle.com Mon May 16 13:21:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 May 2016 14:21:37 +0100 Subject: 8150785: (bf) Hoist slice and duplicate methods up to java.nio.Buffer In-Reply-To: <3C351AE3-DC87-4F75-9CFD-5D5CF8942535@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <876B555F-7F53-444A-B162-BD8B71FB8FED@oracle.com> <573484B1.7070306@oracle.com> <990ac3d8-89f2-ebc2-8a3a-2914415017fe@Oracle.com> <3C351AE3-DC87-4F75-9CFD-5D5CF8942535@oracle.com> Message-ID: <5739C961.5050603@oracle.com> On 16/05/2016 11:10, Pavel Rappo wrote: > Hi, > > The webrev has been updated in-place > > http://cr.openjdk.java.net/~prappo/8150785/webrev.02/ > > to address Roger's suggestion on tests. I must admit `slice` and `duplicate` > (and `asReadOnly` for that matter) functionality hasn't been covered well. So > I've improved it a bit [1]. > > This looks good. -Alan From Roger.Riggs at Oracle.com Mon May 16 13:58:33 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 16 May 2016 09:58:33 -0400 Subject: 8150785: (bf) Hoist slice and duplicate methods up to java.nio.Buffer In-Reply-To: <8E9C0DF8-7105-4DBB-BDAF-2E2F1D693A62@oracle.com> References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com> <876B555F-7F53-444A-B162-BD8B71FB8FED@oracle.com> <573484B1.7070306@oracle.com> <8E9C0DF8-7105-4DBB-BDAF-2E2F1D693A62@oracle.com> Message-ID: +1 On 5/12/2016 11:02 AM, Chris Hegarty wrote: > On 12 May 2016, at 14:27, Alan Bateman wrote: > >> On 12/05/2016 11:48, Pavel Rappo wrote: >>> Hi, >>> >>> Could you please review my change for JDK-8150785? >>> >>> http://cr.openjdk.java.net/~prappo/8150785/webrev.02/ >>> http://cr.openjdk.java.net/~prappo/8150785/specdiff.02/java/nio/package-summary.html >>> >> This looks okay to me. As you know, there are other methods that could be hoisted to Buffer too but what you have looks good. > +1. > > -Chris. From xueming.shen at oracle.com Wed May 25 16:39:15 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 May 2016 09:39:15 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() Message-ID: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> Hi, Please help review the changes for the following zipfs related bug fixes JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() issue: https://bugs.openjdk.java.net/browse/JDK-8147539 https://bugs.openjdk.java.net/browse/JDK-8153248 https://bugs.openjdk.java.net/browse/JDK-8146754 https://bugs.openjdk.java.net/browse/JDK-8139956 webrev: http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ The changes are relative easy. (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at ZipPath.normalize(byte[], int), but is missed in the "main" method) (3) ZipPath.register() should throw PME as suggested. Thanks, Sherman From alexandre.iline at oracle.com Wed May 25 17:18:15 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 25 May 2016 10:18:15 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> Message-ID: Hi. Should the tests also declare ?@modules jdk.zipfs?? Shura > On May 25, 2016, at 9:39 AM, Xueming Shen wrote: > > Hi, > > Please help review the changes for the following zipfs related bug fixes > > JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() > JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result > JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / > JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() > > issue: > https://bugs.openjdk.java.net/browse/JDK-8147539 > https://bugs.openjdk.java.net/browse/JDK-8153248 > https://bugs.openjdk.java.net/browse/JDK-8146754 > https://bugs.openjdk.java.net/browse/JDK-8139956 > > webrev: > http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ > > The changes are relative easy. > (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does > (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at > ZipPath.normalize(byte[], int), but is missed in the "main" method) > (3) ZipPath.register() should throw PME as suggested. > > Thanks, > Sherman From xueming.shen at oracle.com Wed May 25 17:49:54 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 May 2016 10:49:54 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> Message-ID: <5745E5C2.4090705@oracle.com> Should it? My understanding is that those tests don't use zipfs directly from zipfs module, it access it via java.base's FileSystemProvider interface. It depends on the jdk runtime to pick up the zipfs "provider" to function. So if the jdk runtime fails to pick up the zipfs module for whatever reason, that's something we want to detect as well? -Sherman On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: > Hi. > > Should the tests also declare ?@modules jdk.zipfs?? > > Shura > >> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >> >> Hi, >> >> Please help review the changes for the following zipfs related bug fixes >> >> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >> >> issue: >> https://bugs.openjdk.java.net/browse/JDK-8147539 >> https://bugs.openjdk.java.net/browse/JDK-8153248 >> https://bugs.openjdk.java.net/browse/JDK-8146754 >> https://bugs.openjdk.java.net/browse/JDK-8139956 >> >> webrev: >> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >> >> The changes are relative easy. >> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >> ZipPath.normalize(byte[], int), but is missed in the "main" method) >> (3) ZipPath.register() should throw PME as suggested. >> >> Thanks, >> Sherman From alexandre.iline at oracle.com Wed May 25 18:06:43 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 25 May 2016 11:06:43 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <5745E5C2.4090705@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> Message-ID: Sherman, Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. Shura > On May 25, 2016, at 10:49 AM, Xueming Shen wrote: > > > Should it? My understanding is that those tests don't use zipfs directly > from zipfs module, it access it via java.base's FileSystemProvider interface. > It depends on the jdk runtime to pick up the zipfs "provider" to function. So > if the jdk runtime fails to pick up the zipfs module for whatever reason, > that's something we want to detect as well? > > -Sherman > > On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: >> Hi. >> >> Should the tests also declare ?@modules jdk.zipfs?? >> >> Shura >> >>> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >>> >>> Hi, >>> >>> Please help review the changes for the following zipfs related bug fixes >>> >>> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >>> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >>> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >>> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >>> >>> issue: >>> https://bugs.openjdk.java.net/browse/JDK-8147539 >>> https://bugs.openjdk.java.net/browse/JDK-8153248 >>> https://bugs.openjdk.java.net/browse/JDK-8146754 >>> https://bugs.openjdk.java.net/browse/JDK-8139956 >>> >>> webrev: >>> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >>> >>> The changes are relative easy. >>> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >>> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >>> ZipPath.normalize(byte[], int), but is missed in the "main" method) >>> (3) ZipPath.register() should throw PME as suggested. >>> >>> Thanks, >>> Sherman > From mandy.chung at oracle.com Wed May 25 18:31:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 11:31:03 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> Message-ID: <7EEDA61B-69FF-4A13-99A3-990EC1A05E66@oracle.com> The tests under test/jdk/nio/zipfs are intended to test the zipfs implementation and hence they fail if the zipfs provider does not exist. So I agree with Shura that they should have @modules jdk.zipfs that enables test selection per the @modules declaration. Mandy > On May 25, 2016, at 11:06 AM, Alexandre (Shura) Iline wrote: > > Sherman, > > Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? > > I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. > > Shura > >> On May 25, 2016, at 10:49 AM, Xueming Shen wrote: >> >> >> Should it? My understanding is that those tests don't use zipfs directly >> from zipfs module, it access it via java.base's FileSystemProvider interface. >> It depends on the jdk runtime to pick up the zipfs "provider" to function. So >> if the jdk runtime fails to pick up the zipfs module for whatever reason, >> that's something we want to detect as well? >> >> -Sherman >> >> On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: >>> Hi. >>> >>> Should the tests also declare ?@modules jdk.zipfs?? >>> >>> Shura >>> >>>> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >>>> >>>> Hi, >>>> >>>> Please help review the changes for the following zipfs related bug fixes >>>> >>>> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >>>> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >>>> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >>>> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >>>> >>>> issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8147539 >>>> https://bugs.openjdk.java.net/browse/JDK-8153248 >>>> https://bugs.openjdk.java.net/browse/JDK-8146754 >>>> https://bugs.openjdk.java.net/browse/JDK-8139956 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >>>> >>>> The changes are relative easy. >>>> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >>>> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >>>> ZipPath.normalize(byte[], int), but is missed in the "main" method) >>>> (3) ZipPath.register() should throw PME as suggested. >>>> >>>> Thanks, >>>> Sherman >> > From xueming.shen at oracle.com Wed May 25 18:31:52 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 May 2016 11:31:52 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> Message-ID: <5745EF98.9040002@oracle.com> On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: > Sherman, > > Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? > > I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. Hi Shura, Yes, the test will fail if the jdk.zipfs is absence. With the assumption that zipfs module should be available to the jdk images/runtime by default. If it's not there/available, something is wrong and we would want to know why. So the intention here is not to skip the zipfs test silently, if the zipfs is missing from the jdk image. That said, arguably these existing tests are the unit tests for the zipfs functionality, it might be desired to have separate test(s) for testing the availability of the zipfs... sherman > > Shura > >> On May 25, 2016, at 10:49 AM, Xueming Shen wrote: >> >> >> Should it? My understanding is that those tests don't use zipfs directly >> from zipfs module, it access it via java.base's FileSystemProvider interface. >> It depends on the jdk runtime to pick up the zipfs "provider" to function. So >> if the jdk runtime fails to pick up the zipfs module for whatever reason, >> that's something we want to detect as well? >> >> -Sherman >> >> On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: >>> Hi. >>> >>> Should the tests also declare ?@modules jdk.zipfs?? >>> >>> Shura >>> >>>> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >>>> >>>> Hi, >>>> >>>> Please help review the changes for the following zipfs related bug fixes >>>> >>>> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >>>> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >>>> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >>>> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >>>> >>>> issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8147539 >>>> https://bugs.openjdk.java.net/browse/JDK-8153248 >>>> https://bugs.openjdk.java.net/browse/JDK-8146754 >>>> https://bugs.openjdk.java.net/browse/JDK-8139956 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >>>> >>>> The changes are relative easy. >>>> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >>>> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >>>> ZipPath.normalize(byte[], int), but is missed in the "main" method) >>>> (3) ZipPath.register() should throw PME as suggested. >>>> >>>> Thanks, >>>> Sherman From alexandre.iline at oracle.com Wed May 25 18:46:14 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 25 May 2016 11:46:14 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <5745EF98.9040002@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> Message-ID: > On May 25, 2016, at 11:31 AM, Xueming Shen wrote: > > On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: >> Sherman, >> >> Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? >> >> I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. > > Hi Shura, > > Yes, the test will fail if the jdk.zipfs is absence. With the assumption that zipfs module should > be available to the jdk images/runtime by default. If it's not there/available, something is wrong Well, not necessarily. Since JTReg is taking on the burden to select tests for execution based on the available modules, be it -limitmods option or a custom built limited JDK image, the test suite will be used to execute tests for compact profiles, for example. We will be relying on JTReg to select proper tests. The plan is to get rid of the test groups for compact profiles when the test markup is complete. Shura > and we would want to know why. So the intention here is not to skip the zipfs test silently, if > the zipfs is missing from the jdk image. That said, arguably these existing tests are the unit tests > for the zipfs functionality, it might be desired to have separate test(s) for testing the availability > of the zipfs... > > sherman > >> >> Shura >> >>> On May 25, 2016, at 10:49 AM, Xueming Shen wrote: >>> >>> >>> Should it? My understanding is that those tests don't use zipfs directly >>> from zipfs module, it access it via java.base's FileSystemProvider interface. >>> It depends on the jdk runtime to pick up the zipfs "provider" to function. So >>> if the jdk runtime fails to pick up the zipfs module for whatever reason, >>> that's something we want to detect as well? >>> >>> -Sherman >>> >>> On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: >>>> Hi. >>>> >>>> Should the tests also declare ?@modules jdk.zipfs?? >>>> >>>> Shura >>>> >>>>> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please help review the changes for the following zipfs related bug fixes >>>>> >>>>> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >>>>> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >>>>> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >>>>> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >>>>> >>>>> issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8147539 >>>>> https://bugs.openjdk.java.net/browse/JDK-8153248 >>>>> https://bugs.openjdk.java.net/browse/JDK-8146754 >>>>> https://bugs.openjdk.java.net/browse/JDK-8139956 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >>>>> >>>>> The changes are relative easy. >>>>> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >>>>> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >>>>> ZipPath.normalize(byte[], int), but is missed in the "main" method) >>>>> (3) ZipPath.register() should throw PME as suggested. >>>>> >>>>> Thanks, >>>>> Sherman > From xueming.shen at oracle.com Wed May 25 19:01:34 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 May 2016 12:01:34 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> Message-ID: <5745F68E.6020001@oracle.com> On 05/25/2016 11:46 AM, Alexandre (Shura) Iline wrote: >> On May 25, 2016, at 11:31 AM, Xueming Shen wrote: >> >> On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: >>> Sherman, >>> >>> Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? >>> >>> I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. >> Hi Shura, >> >> Yes, the test will fail if the jdk.zipfs is absence. With the assumption that zipfs module should >> be available to the jdk images/runtime by default. If it's not there/available, something is wrong > Well, not necessarily. > > Since JTReg is taking on the burden to select tests for execution based on the available modules, be it -limitmods option or a custom built limited JDK image, the test suite will be used to execute tests for compact profiles, for example. We will be relying on JTReg to select proper tests. The plan is to get rid of the test groups for compact profiles when the test markup is complete. > > Shura > Sure, if there is such "plan". http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev Here is the updated webrev with the @module tag. thanks! Sherman From Alan.Bateman at oracle.com Wed May 25 19:49:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 20:49:13 +0100 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <5745F68E.6020001@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> <5745F68E.6020001@oracle.com> Message-ID: <574601B9.3040704@oracle.com> On 25/05/2016 20:01, Xueming Shen wrote: > : > > Sure, if there is such "plan". > > http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev > > > Here is the updated webrev with the @module tag. > In ZipPath.register then it would be good to include a comment to say something "watcher must be associated with a different provider" as it might not be immediately clear why ProviderMismatchException is thrown. The rest looks good to me. -Alan From xueming.shen at oracle.com Wed May 25 19:47:49 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 25 May 2016 12:47:49 -0700 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <574601B9.3040704@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> <5745F68E.6020001@oracle.com> <574601B9.3040704@oracle.com> Message-ID: <57460165.3030903@oracle.com> On 05/25/2016 12:49 PM, Alan Bateman wrote: > > > On 25/05/2016 20:01, Xueming Shen wrote: >> : >> >> Sure, if there is such "plan". >> >> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev >> >> Here is the updated webrev with the @module tag. >> > In ZipPath.register then it would be good to include a comment to say something "watcher must be associated with a different provider" as it might not be immediately clear why ProviderMismatchException is thrown. > > The rest looks good to me. > > -Alan thanks! updated accordingly. http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev -sherman From Alan.Bateman at oracle.com Wed May 25 19:56:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 20:56:05 +0100 Subject: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: <57460165.3030903@oracle.com> References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> <5745F68E.6020001@oracle.com> <574601B9.3040704@oracle.com> <57460165.3030903@oracle.com> Message-ID: <57460355.80208@oracle.com> On 25/05/2016 20:47, Xueming Shen wrote: > thanks! updated accordingly. > > http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev > Looks good. From sean.coffey at oracle.com Thu May 26 09:52:42 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 26 May 2016 10:52:42 +0100 Subject: (@modules documentation)Re: RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() In-Reply-To: References: <64c0e33c-5d94-9eb0-1349-8978b305265e@oracle.com> <5745E5C2.4090705@oracle.com> <5745EF98.9040002@oracle.com> Message-ID: <97af1957-c3ec-8f92-9698-4d8bb9a471cd@oracle.com> Was our OpenJDK documentation ever updated to highlight the @modules change for JDK 9 ? Could we edit the developer's guide[1] to highlight the @modules tag [2]. The current doc states that an @bug tag should be supplied. It would help to document why/when an @modules tag would be required also. [1] http://openjdk.java.net/guide/changePlanning.html [2] http://openjdk.java.net/jtreg/tag-spec.html Regards, Sean. On 25/05/2016 19:46, Alexandre (Shura) Iline wrote: >> On May 25, 2016, at 11:31 AM, Xueming Shen wrote: >> >> On 5/25/16, 11:06 AM, Alexandre (Shura) Iline wrote: >>> Sherman, >>> >>> Not declaring any module dependencies in test is equivalent to declaring that the test only depends on java.base. In such case, the test will be picked up for execution by JTReg, no matter what modules are available. One way to test such behavior would be to supply -javaoptions:?-limitmods java.base? in the JTReg command line. The tests will be selected for execution, but would they work? >>> >>> I have taken another look on the code now, it looks like with the absence of jdk.zipfs test/jdk/nio/zipfs/Basic.java test will fail. I think it would be good to skip this test altogether if there is no jdk.zipfs available. >> Hi Shura, >> >> Yes, the test will fail if the jdk.zipfs is absence. With the assumption that zipfs module should >> be available to the jdk images/runtime by default. If it's not there/available, something is wrong > Well, not necessarily. > > Since JTReg is taking on the burden to select tests for execution based on the available modules, be it -limitmods option or a custom built limited JDK image, the test suite will be used to execute tests for compact profiles, for example. We will be relying on JTReg to select proper tests. The plan is to get rid of the test groups for compact profiles when the test markup is complete. > > Shura > >> and we would want to know why. So the intention here is not to skip the zipfs test silently, if >> the zipfs is missing from the jdk image. That said, arguably these existing tests are the unit tests >> for the zipfs functionality, it might be desired to have separate test(s) for testing the availability >> of the zipfs... >> >> sherman >> >>> Shura >>> >>>> On May 25, 2016, at 10:49 AM, Xueming Shen wrote: >>>> >>>> >>>> Should it? My understanding is that those tests don't use zipfs directly >>>> from zipfs module, it access it via java.base's FileSystemProvider interface. >>>> It depends on the jdk runtime to pick up the zipfs "provider" to function. So >>>> if the jdk runtime fails to pick up the zipfs module for whatever reason, >>>> that's something we want to detect as well? >>>> >>>> -Sherman >>>> >>>> On 05/25/2016 10:18 AM, Alexandre (Shura) Iline wrote: >>>>> Hi. >>>>> >>>>> Should the tests also declare ?@modules jdk.zipfs?? >>>>> >>>>> Shura >>>>> >>>>>> On May 25, 2016, at 9:39 AM, Xueming Shen wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please help review the changes for the following zipfs related bug fixes >>>>>> >>>>>> JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() >>>>>> JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result >>>>>> JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / >>>>>> JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() >>>>>> >>>>>> issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8147539 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8153248 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146754 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8139956 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ >>>>>> >>>>>> The changes are relative easy. >>>>>> (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does >>>>>> (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at >>>>>> ZipPath.normalize(byte[], int), but is missed in the "main" method) >>>>>> (3) ZipPath.register() should throw PME as suggested. >>>>>> >>>>>> Thanks, >>>>>> Sherman -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri May 27 08:29:34 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 27 May 2016 08:29:34 +0000 Subject: RFR 8158023: SocketExceptions contain too little information sometimes Message-ID: Hi all, please review the following change: Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 During error analysis I stumbled over a place where I encountered a SocketException which was thrown along with some strerror information as message. I found it hard to find the originating code spot with that information. So I looked at the places where we throw exceptions, namely JNU_Throw... and NET_Throw... functions and came up with the following enhancement: - NET_ThrowByNameWithLastError can go completely as it does not provide any benefit over JNU_ThrowByNameWithLastError. - JNU_ThrowByNameWithLastError can be cleaned up. - I added JNU_ThrowByNameWithMessageAndLastError to print out a string like message + ": " + last error. - I went over all places where NET_ThrowByNameWithLastError is used and replaced it appropriately. Do you think this change is desirable/possible? Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as well as JNU_Throw... code affects all. Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon May 30 15:41:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 May 2016 16:41:24 +0100 Subject: 8066258: Re-examine com.sun.nio.file to see if it should be a supported API Message-ID: <574C5F24.4030805@oracle.com> The last remaining JDK-specific API in java.base is the com.sun.nio.file API. This needs to be moved to a JDK-specific module, which one is TDB. For now I'd like to at least get the refactoring done and move this API to jdk.unsupported on a temporary basis. Once the refactoring is in JDK 9 then it will be trivial to move it. The proposed changes are here: http://cr.openjdk.java.net/~alanb/8066258/webrev/ Thanks, -Alan From chris.hegarty at oracle.com Mon May 30 15:54:05 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 May 2016 16:54:05 +0100 Subject: 8066258: Re-examine com.sun.nio.file to see if it should be a supported API In-Reply-To: <574C5F24.4030805@oracle.com> References: <574C5F24.4030805@oracle.com> Message-ID: <574C621D.70000@oracle.com> On 30/05/16 16:41, Alan Bateman wrote: > > The last remaining JDK-specific API in java.base is the com.sun.nio.file > API. This needs to be moved to a JDK-specific module, which one is TDB. > For now I'd like to at least get the refactoring done and move this API > to jdk.unsupported on a temporary basis. Once the refactoring is in JDK > 9 then it will be trivial to move it. The proposed changes are here: > http://cr.openjdk.java.net/~alanb/8066258/webrev/ This look good to me Alan, and a quite clean solution. It will be easy to refactor when a better home is found for it. -Chris.