From huaming.li at oracle.com Thu Feb 1 01:56:18 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 1 Feb 2018 09:56:18 +0800 Subject: [9] RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock In-Reply-To: <50FAAADC-9E1E-43A1-B910-141CB386FFFF@oracle.com> References: <1D32417F-2DAA-4C83-9D63-71D58C2028DE@oracle.com> <14b4340f-cf69-efcd-53ea-8bb956e6105e@oracle.com> <6b81d498-0bf9-6ad7-53e1-3cc28a379cbb@oracle.com> <133A7B5F-B095-41AF-954C-EE0909D33B47@oracle.com> <3FF43CDD-5C98-48DA-B1B0-B7BC1DDF535F@oracle.com> <55570635-e7e8-ae21-87e3-5e1b46930058@oracle.com> <50FAAADC-9E1E-43A1-B910-141CB386FFFF@oracle.com> Message-ID: Hi Brian, Thank you for explanation. Yes, you're right, . -Hamlin On 01/02/2018 12:01 AM, Brian Burkhalter wrote: > Hi Hamlin, > > On Jan 30, 2018, at 9:32 PM, Hamlin Li > wrote: > >>> http://cr.openjdk.java.net/~bpb/8166253/webrev.04/ >>> >> Second, although it will solve JDK-8166253, it will introduce a new >> issue by line 290("if (!ref.isValid()) {") in FileLockTable.java. I >> think all the refs in queue will satisfy the condition "ref.isValid()?, > > I don?t think so because of lines 210 and 234 which are invoked during > the explicit release of the lock or the channel close. > > Thanks, > > Brian > >> so there will be no ref be removed by removeStaleEntries, it will >> increase queue infinitely, finally could get out of memory if long >> enough. And seems there is workaround for this new issue, because >> line 290 is the key point to fix the JDK-8166253. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 1 01:56:56 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 31 Jan 2018 17:56:56 -0800 Subject: [9] RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock In-Reply-To: <133A7B5F-B095-41AF-954C-EE0909D33B47@oracle.com> References: <1D32417F-2DAA-4C83-9D63-71D58C2028DE@oracle.com> <14b4340f-cf69-efcd-53ea-8bb956e6105e@oracle.com> <6b81d498-0bf9-6ad7-53e1-3cc28a379cbb@oracle.com> <133A7B5F-B095-41AF-954C-EE0909D33B47@oracle.com> Message-ID: On Jan 30, 2018, at 12:58 AM, Alan Bateman wrote: >> The proposed fix is: >> >> http://cr.openjdk.java.net/~bpb/8166253/webrev.03/ >> > I think it would be simpler if FileChannel maintained a set of the valid locks obtained via the channel, the the unlock can remove the lock from the set. I created and tested an updated version which maintains a set of hard references to the locks for the channel inside the FileLockTable itself: http://cr.openjdk.java.net/~bpb/8166253/webrev.05/ Given that the set is always accessed inside a block synchronized on the list corresponding to the FileKey in the global FileKey-to-FileLockReference table, I think the Set could probably be initialized at line 124 to a simple HashSet instead of a ConcurrentHashMap.KeySetView but I wanted to solicit comments on that point. On Jan 30, 2018, at 9:32 PM, Hamlin Li wrote: > From the spec, we can conclude that a java file-lock object should have the same lifetime as its channel except it's release or closed explicitly. So it's reasonable for the channel object to just have strong references to the file-lock objects, and delete references if file-lock objects are released or the channel is closed. I think in this way no new interface like FileLockListener needs to be added, and no modification is needed in FileLockImpl and FileLockTable, just needs to add/remove file-lock objects in FileChannelImpl and AsynchronousFileChannelImpl accordingly. I agree with you now. The hanging / timeout problem I observed was due to the test itself and has been corrected. > And by this way, file-lock objects referred / weak-referred in FileChannelImpl.SimpleFileLockTable / FileLockTable.SharedFileLockTable have the same lifetime, so FileChannelImpl.SimpleFileLockTable can be simply removed. This is the subject of a separate issue which I have already filed and hope to address this week. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Thu Feb 1 03:05:48 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 1 Feb 2018 11:05:48 +0800 Subject: [9] RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock In-Reply-To: References: <1D32417F-2DAA-4C83-9D63-71D58C2028DE@oracle.com> <14b4340f-cf69-efcd-53ea-8bb956e6105e@oracle.com> <6b81d498-0bf9-6ad7-53e1-3cc28a379cbb@oracle.com> <133A7B5F-B095-41AF-954C-EE0909D33B47@oracle.com> Message-ID: On 01/02/2018 9:56 AM, Brian Burkhalter wrote: > On Jan 30, 2018, at 12:58 AM, Alan Bateman > wrote: > >>> The proposed fix is: >>> >>> http://cr.openjdk.java.net/~bpb/8166253/webrev.03/ >>> >>> >> I think it would be simpler if FileChannel maintained a set of the >> valid locks obtained via the channel, the the unlock can remove the >> lock from the set. > > I created and tested an updated version which maintains a set of hard > references to the locks for the channel inside the FileLockTable itself: > > http://cr.openjdk.java.net/~bpb/8166253/webrev.05/ > > > Given that the set is always accessed inside a block synchronized on > the list corresponding to the FileKey in the global > FileKey-to-FileLockReference table, I think the Set could probably be > initialized at line 124 to a simple HashSet instead of a > ConcurrentHashMap.KeySetView but I wanted to solicit > comments on that point. It looks much clear. I'm not sure if an ConcurrentHashMap.KeySetView instance is necessary, as "locks" will be protected from concurrent access by "synchronized (list)", even if several channels might share a single list, I think it still works well. In FileLockGC.java, "A hypothetical 'GC_THEN_RELEASE' case is infeasible", I agree. But something like below would not harm, although it seems unnecessary: System.gc(); lock1.release(); > > On Jan 30, 2018, at 9:32 PM, Hamlin Li > wrote: > >> From the spec, we can conclude that a java file-lock object should >> have the same lifetime as its channel except it's release or closed >> explicitly. So it's reasonable for the channel object to just have >> strong references to the file-lock objects, and delete references if >> file-lock objects are released or the channel is closed. I think in >> this way no new interface like FileLockListener needs to be added, >> and no modification is needed in FileLockImpl and FileLockTable, just >> needs to add/remove file-lock objects in FileChannelImpl and >> AsynchronousFileChannelImpl accordingly. > > I agree with you now. The hanging / timeout problem I observed was due > to the test itself and has been corrected. good to know > >> And by this way, file-lock objects referred / weak-referred in >> FileChannelImpl.SimpleFileLockTable / >> FileLockTable.SharedFileLockTable have the same lifetime, so >> FileChannelImpl.SimpleFileLockTable can be simply removed. > > This is the subject of a separate issue which I have already filed and > hope to address this week. OK Thank you -Hamlin > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 1 23:40:43 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Feb 2018 15:40:43 -0800 Subject: RFR 8196535: Remove support for pre-Java 6 non-JVM-wide file locking Message-ID: <78730167-1EC3-4195-B275-4AD30269388F@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8196535 http://cr.openjdk.java.net/~bpb/8196535/webrev.00/ This patch would remove support for the sun.nio.ch.disableSystemWideOverlappingFileLockCheck system property introduced in Java 6 to allow enabling pre-Java 6 behavior of checking for overlapping FileLocks opened on a FileChannel. Please note that this patch follows in sequence the patch proposed in [1] which still needs to pass review. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004667.html From brian.burkhalter at oracle.com Thu Feb 1 23:54:20 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 1 Feb 2018 15:54:20 -0800 Subject: RFR 8196622: Add java/nio/Buffer/EqualsCompareTest.java to ProblemList Message-ID: https://bugs.openjdk.java.net/browse/JDK-8196622 This test is consistently failing on solaris-sparcv9. It would be good to suppress it on Solaris to reduce the noise until the underlying issue is resolved. # jdk_nio +java/nio/Buffer/EqualsCompareTest.java 8193917 solaris-all + java/nio/channels/Selector/Wakeup.java 6963118 windows-all java/nio/channels/DatagramChannel/ChangingAddress.java 7141822 macosx-all ? Thanks, Brian From Alan.Bateman at oracle.com Fri Feb 2 09:13:29 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Feb 2018 09:13:29 +0000 Subject: RFR 8196622: Add java/nio/Buffer/EqualsCompareTest.java to ProblemList In-Reply-To: References: Message-ID: <45fcd764-bec1-d99a-1cf3-0f144e983553@oracle.com> On 01/02/2018 23:54, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8196622 > > This test is consistently failing on solaris-sparcv9. It would be good to suppress it on Solaris to reduce the noise until the underlying issue is resolved. > > Looks okay and would be good to track down this crash, I think was looking at it at one point. -Alan From Alan.Bateman at oracle.com Fri Feb 2 11:15:08 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Feb 2018 11:15:08 +0000 Subject: RFR 8196535: Remove support for pre-Java 6 non-JVM-wide file locking In-Reply-To: <78730167-1EC3-4195-B275-4AD30269388F@oracle.com> References: <78730167-1EC3-4195-B275-4AD30269388F@oracle.com> Message-ID: <14363f5f-5519-b66b-04ad-c1fbd6db7795@oracle.com> On 01/02/2018 23:40, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8196535 > http://cr.openjdk.java.net/~bpb/8196535/webrev.00/ > > This patch would remove support for the sun.nio.ch.disableSystemWideOverlappingFileLockCheck system property introduced in Java 6 to allow enabling pre-Java 6 behavior of checking for overlapping FileLocks opened on a FileChannel. > > Please note that this patch follows in sequence the patch proposed in [1] which still needs to pass review. > Good to see this going away. You can probably get rid of the static factory method (newFileLockTable) too if you also. Also the methods implemented the now-deleted interface no longer need to be public. Minor nit, line break at FileChannel L1097 looks ugly so I assume you don't need that. -Alan From david.buck at oracle.com Fri Feb 2 14:16:49 2018 From: david.buck at oracle.com (David Buck) Date: Fri, 2 Feb 2018 23:16:49 +0900 Subject: [8u] RFR(M): 8168628/8171452: (fc) SIGBUS when extending file size to map it Message-ID: Hi! I would really appreciate a review of my backport of jdk8168628 to JDK 8. As jdk8168628 introduced a regression (jdk8171452), I have also included the small fix for that in my backport as it makes sense to push them both at the same time. bug report (original bug): [ (fc) SIGBUS when extending file size to map it ] https://bugs.openjdk.java.net/browse/JDK-8168628 JDK 9 code review thread: http://mail.openjdk.java.net/pipermail/nio-dev/2016-December/003997.html JDK 9 changset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c0af0f58d538 bug report (minor regression fix added to above fix): [ (ch) linux io_util_md: Operation not supported exception after 8168628 ] https://bugs.openjdk.java.net/browse/JDK-8171452 JDK 9 code review thread (December 2016 and January 2017): http://mail.openjdk.java.net/pipermail/nio-dev/2016-December/004031.html http://mail.openjdk.java.net/pipermail/nio-dev/2017-January/004048.html JDK 9 changset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8b55846dd69d webrev combining above two fixes for review: http://cr.openjdk.java.net/~dbuck/8168628_jdk8_ver00/ The only non-trivial difference from the JDK 9 version of the fix is that the glibc shipped with some older Linux distributions still supported by JDK 8 (e.g. RHEL 5) do not have fallocate()/fallocate64(). Fortunately, they do have posix_fallocate(), which works fine for us because we were passing the default mode flags to fallocate64() anyway. The only complication is we need to define _FILE_OFFSET_BITS=64 to get gcc to call posix_fallocate64() in the resulting object file. I carefully examined both object files for any other changes as a result of adding this define, and the only other difference is that the open() of "/dev/null" at io_util_md.c:143 (see webrev) has been converted to an open64() call, which is equivalent to adding O_LARGEFILE to the flags parameter of open(), a very benign change given the code in question. I have tested the backport extensively, including building all platforms supported by JPRT for JDK 8, several runs of the "core" jprt testset, and manually confirming the fix with the test case included in the changeset itself (both with and without RAF). Cheers, -Buck From Roger.Riggs at Oracle.com Fri Feb 2 15:29:06 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 2 Feb 2018 10:29:06 -0500 Subject: RFR 8196535: Remove support for pre-Java 6 non-JVM-wide file locking In-Reply-To: <78730167-1EC3-4195-B275-4AD30269388F@oracle.com> References: <78730167-1EC3-4195-B275-4AD30269388F@oracle.com> Message-ID: <0c878732-db87-5f37-b56a-042cd2300ed0@Oracle.com> Hi Brian, Nice cleanup. FileLockTable: line 80: typo "the a" -> "the" FileLockTable:89:? the constructor should be private to avoid an end-run around the factory method. While editing FileLockTable.java perhaps convert imports to single imports instead of .*... your call. I'm assuming there were no tests for the old setting since there none in the review. FileChannelImpl.java:1096: if the line doesn't need to be continued, maybe all on 1 line Thanks, Roger On 2/1/2018 6:40 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8196535 > http://cr.openjdk.java.net/~bpb/8196535/webrev.00/ > > This patch would remove support for the sun.nio.ch.disableSystemWideOverlappingFileLockCheck system property introduced in Java 6 to allow enabling pre-Java 6 behavior of checking for overlapping FileLocks opened on a FileChannel. > > Please note that this patch follows in sequence the patch proposed in [1] which still needs to pass review. > > Thanks, > > Brian > > [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004667.html From paul.sandoz at oracle.com Fri Feb 2 16:47:40 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 2 Feb 2018 08:47:40 -0800 Subject: RFR 8196622: Add java/nio/Buffer/EqualsCompareTest.java to ProblemList In-Reply-To: <45fcd764-bec1-d99a-1cf3-0f144e983553@oracle.com> References: <45fcd764-bec1-d99a-1cf3-0f144e983553@oracle.com> Message-ID: <5B5AAFC7-0208-4CBB-A551-C72A2C141F08@oracle.com> > On Feb 2, 2018, at 1:13 AM, Alan Bateman wrote: > > On 01/02/2018 23:54, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8196622 >> >> This test is consistently failing on solaris-sparcv9. It would be good to suppress it on Solaris to reduce the noise until the underlying issue is resolved. >> >> > Looks okay and would be good to track down this crash, I think was looking at it at one point. > I was hesitant to support the addition to the problem list as it might be forgotten, the noise kept reminding me :-) and it was useful data to see if the crash was consistent in some way. I wish there was a way to flag a test as keep it running, report results, but if it fails don?t flag it as such. I have had no time to investigate, but my suspicion is it might be some method handle compilation bug rather than some memory corruption bug due to the buffer changes to support optimized comparison (the test writes to buffers to set up test data, then its just reads, there were no changes to buffer writes for this enhancement). Paul. From brian.burkhalter at oracle.com Fri Feb 2 16:55:04 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Feb 2018 08:55:04 -0800 Subject: RFR 8196535: Remove support for pre-Java 6 non-JVM-wide file locking In-Reply-To: <14363f5f-5519-b66b-04ad-c1fbd6db7795@oracle.com> References: <78730167-1EC3-4195-B275-4AD30269388F@oracle.com> <14363f5f-5519-b66b-04ad-c1fbd6db7795@oracle.com> Message-ID: <03861E5B-6C10-4073-99B5-90812261426F@oracle.com> On Feb 2, 2018, at 3:15 AM, Alan Bateman wrote: > Good to see this going away. You can probably get rid of the static factory method (newFileLockTable) too if you also. Yeah I had thought of that but did not do it. > Also the methods implemented the now-deleted interface no longer need to be public. > > Minor nit, line break at FileChannel L1097 looks ugly so I assume you don't need that. Will make the above changes. On Feb 2, 2018, at 7:29 AM, Roger Riggs wrote: > Nice cleanup. Thanks to Alan and Hamlin. I did not like the earlier versions either. > FileLockTable: line 80: typo "the a" -> "the" > > FileLockTable:89: the constructor should be private to avoid an end-run around the factory method. > > While editing FileLockTable.java perhaps convert imports to single imports instead of .*... your call. I did that in a prior version. > I'm assuming there were no tests for the old setting since there none in the review. I don?t think so but I will double check. > FileChannelImpl.java:1096: if the line doesn't need to be continued, maybe all on 1 line Will make the above changes. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Feb 2 17:56:59 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Feb 2018 17:56:59 +0000 Subject: [9] RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock In-Reply-To: References: <1D32417F-2DAA-4C83-9D63-71D58C2028DE@oracle.com> <14b4340f-cf69-efcd-53ea-8bb956e6105e@oracle.com> <6b81d498-0bf9-6ad7-53e1-3cc28a379cbb@oracle.com> <133A7B5F-B095-41AF-954C-EE0909D33B47@oracle.com> Message-ID: <1abef289-6e3f-1ea1-eec0-e253f06b3cf3@oracle.com> On 01/02/2018 01:56, Brian Burkhalter wrote: > > I created and tested an updated version which maintains a set of hard > references to the locks for the channel inside the FileLockTable itself: > > http://cr.openjdk.java.net/~bpb/8166253/webrev.05/ > > > Given that the set is always accessed inside a block synchronized on > the list corresponding to the FileKey in the global > FileKey-to-FileLockReference table, I think the Set could probably be > initialized at line 124 to a simple HashSet instead of a > ConcurrentHashMap.KeySetView but I wanted to solicit > comments on that point. > Yes, it can be a HashSet. Also in the case of removeAll then you can invoke locks.clear(). In the case of replace then I think it would be more understandable if the remove+add are together. -Alan From brian.burkhalter at oracle.com Fri Feb 2 17:58:30 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Feb 2018 09:58:30 -0800 Subject: [9] RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock In-Reply-To: <1abef289-6e3f-1ea1-eec0-e253f06b3cf3@oracle.com> References: <1D32417F-2DAA-4C83-9D63-71D58C2028DE@oracle.com> <14b4340f-cf69-efcd-53ea-8bb956e6105e@oracle.com> <6b81d498-0bf9-6ad7-53e1-3cc28a379cbb@oracle.com> <133A7B5F-B095-41AF-954C-EE0909D33B47@oracle.com> <1abef289-6e3f-1ea1-eec0-e253f06b3cf3@oracle.com> Message-ID: <06DF72B1-C11A-43AA-A83B-3DA74C8CF071@oracle.com> On Feb 2, 2018, at 9:56 AM, Alan Bateman wrote: >> I think the Set could probably be initialized at line 124 to a simple HashSet instead of a ConcurrentHashMap.KeySetView but I wanted to solicit comments on that point. >> > Yes, it can be a HashSet. Also in the case of removeAll then you can invoke locks.clear(). In the case of replace then I think it would be more understandable if the remove+add are together. I was unsure about this latter. Otherwise does this look OK? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Feb 2 18:03:34 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Feb 2018 18:03:34 +0000 Subject: [9] RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock In-Reply-To: <06DF72B1-C11A-43AA-A83B-3DA74C8CF071@oracle.com> References: <1D32417F-2DAA-4C83-9D63-71D58C2028DE@oracle.com> <14b4340f-cf69-efcd-53ea-8bb956e6105e@oracle.com> <6b81d498-0bf9-6ad7-53e1-3cc28a379cbb@oracle.com> <133A7B5F-B095-41AF-954C-EE0909D33B47@oracle.com> <1abef289-6e3f-1ea1-eec0-e253f06b3cf3@oracle.com> <06DF72B1-C11A-43AA-A83B-3DA74C8CF071@oracle.com> Message-ID: On 02/02/2018 17:58, Brian Burkhalter wrote: > > On Feb 2, 2018, at 9:56 AM, Alan Bateman > wrote: > >>> I think the Set could probably be initialized at line 124 to a >>> simple HashSet instead of a >>> ConcurrentHashMap.KeySetView but I wanted to >>> solicit comments on that point. >>> >> Yes, it can be a HashSet. Also in the case of removeAll then you can >> invoke locks.clear(). In the case of replace then I think it would be >> more understandable if the remove+add are together. > > I was unsure about this latter. Otherwise does this look OK? > Yes, I think so. Also combined with the other patch will make it a lot better. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 2 22:52:23 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 Feb 2018 14:52:23 -0800 Subject: RFR 8196535: Remove support for pre-Java 6 non-JVM-wide file locking In-Reply-To: <03861E5B-6C10-4073-99B5-90812261426F@oracle.com> References: <78730167-1EC3-4195-B275-4AD30269388F@oracle.com> <14363f5f-5519-b66b-04ad-c1fbd6db7795@oracle.com> <03861E5B-6C10-4073-99B5-90812261426F@oracle.com> Message-ID: Updated version http://cr.openjdk.java.net/~bpb/8196535/webrev.01/ which includes all the changes suggested below except making the constructor private which is not done because the factory method is removed. I could not locate any existing tests specific to the system property being removed. Thanks, Brian On Feb 2, 2018, at 8:55 AM, Brian Burkhalter wrote: > On Feb 2, 2018, at 3:15 AM, Alan Bateman wrote: > >> Good to see this going away. You can probably get rid of the static factory method (newFileLockTable) too if you also. > > Yeah I had thought of that but did not do it. > >> Also the methods implemented the now-deleted interface no longer need to be public. >> >> Minor nit, line break at FileChannel L1097 looks ugly so I assume you don't need that. > > Will make the above changes. > > On Feb 2, 2018, at 7:29 AM, Roger Riggs wrote: > >> Nice cleanup. > > Thanks to Alan and Hamlin. I did not like the earlier versions either. > >> FileLockTable: line 80: typo "the a" -> "the" >> >> FileLockTable:89: the constructor should be private to avoid an end-run around the factory method. >> >> While editing FileLockTable.java perhaps convert imports to single imports instead of .*... your call. > > I did that in a prior version. > >> I'm assuming there were no tests for the old setting since there none in the review. > > I don?t think so but I will double check. > >> FileChannelImpl.java:1096: if the line doesn't need to be continued, maybe all on 1 line > > > Will make the above changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Feb 3 09:51:54 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 3 Feb 2018 09:51:54 +0000 Subject: RFR 8196535: Remove support for pre-Java 6 non-JVM-wide file locking In-Reply-To: References: <78730167-1EC3-4195-B275-4AD30269388F@oracle.com> <14363f5f-5519-b66b-04ad-c1fbd6db7795@oracle.com> <03861E5B-6C10-4073-99B5-90812261426F@oracle.com> Message-ID: On 02/02/2018 22:52, Brian Burkhalter wrote: > Updated version > > http://cr.openjdk.java.net/~bpb/8196535/webrev.01/ > > > which includes all the changes suggested below except making the > constructor private which is not done because the factory method is > removed. > > I could not locate any existing tests specific to the system property > being removed. > The changes looks good. The broken behavior in JDK 1.4/5 was hard to test as it was so platform specific, that may why the tests no longer exist. -Alan From Alan.Bateman at oracle.com Mon Feb 5 15:05:13 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Feb 2018 15:05:13 +0000 Subject: [8u] RFR(M): 8168628/8171452: (fc) SIGBUS when extending file size to map it In-Reply-To: References: Message-ID: On 02/02/2018 14:16, David Buck wrote: > Hi! > > I would really appreciate a review of my backport of jdk8168628 to JDK > 8. As jdk8168628 introduced a regression (jdk8171452), I have also > included the small fix for that in my backport as it makes sense to > push them both at the same time. > > bug report (original bug): > [ (fc) SIGBUS when extending file size to map it ] > https://bugs.openjdk.java.net/browse/JDK-8168628 > > JDK 9 code review thread: > http://mail.openjdk.java.net/pipermail/nio-dev/2016-December/003997.html > > JDK 9 changset: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c0af0f58d538 > > bug report (minor regression fix added to above fix): > [ (ch) linux io_util_md: Operation not supported exception after > 8168628 ] > https://bugs.openjdk.java.net/browse/JDK-8171452 > > JDK 9 code review thread (December 2016 and January 2017): > http://mail.openjdk.java.net/pipermail/nio-dev/2016-December/004031.html > http://mail.openjdk.java.net/pipermail/nio-dev/2017-January/004048.html > > JDK 9 changset: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8b55846dd69d > > webrev combining above two fixes for review: > http://cr.openjdk.java.net/~dbuck/8168628_jdk8_ver00/ > I've looked through the combined changes and they look okay to me. -Alan. From Alan.Bateman at oracle.com Mon Feb 5 16:27:34 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Feb 2018 16:27:34 +0000 Subject: 8196787: (ch) Moving network channels to use j.u.c locks Message-ID: <84cfb7c5-ed9a-604e-dd66-26bd24dd0f03@oracle.com> I have a number of patches in the works that re-work some of the locking in the NIO networking channels and also split the blocking and non-blocking code paths. Part of the motivation is the complexity/overhead dealing with async close and interrupt of blocking operations, another part is preliminary work to prepare the implementations for fibers. To get started, I'd like to replace the read/write locks used in the networking channels to use j.u.c. locks. The changes are easy to review: ?? http://cr.openjdk.java.net/~alanb/8196787/webrev/ There are a few small clean-ups in the patch, this is mostly to keep as much noise out of the follow-up changes. The dropping of the ready parameter from the native checkConnect is clean-up as the readyToConnect flag (dates from 1.4) isn't always reliable to use. -Alan From pavel.rappo at oracle.com Mon Feb 5 16:38:58 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 5 Feb 2018 16:38:58 +0000 Subject: 8196787: (ch) Moving network channels to use j.u.c locks In-Reply-To: <84cfb7c5-ed9a-604e-dd66-26bd24dd0f03@oracle.com> References: <84cfb7c5-ed9a-604e-dd66-26bd24dd0f03@oracle.com> Message-ID: <57DB14B4-DC7C-40DE-9342-1D1A7EAD922F@oracle.com> This seems to be out of sync (no pun intended) with the writeLock becoming a j.u.c.Lock and previous locks/unlocks on it. 821 readLock.lock(); 822 try { -> 823 synchronized(writeLock) { 824 synchronized (stateLock) { 825 if (!isConnected() || !isOpen()) > On 5 Feb 2018, at 16:27, Alan Bateman wrote: > > > I have a number of patches in the works that re-work some of the locking in the NIO networking channels and also split the blocking and non-blocking code paths. Part of the motivation is the complexity/overhead dealing with async close and interrupt of blocking operations, another part is preliminary work to prepare the implementations for fibers. > > To get started, I'd like to replace the read/write locks used in the networking channels to use j.u.c. locks. The changes are easy to review: > http://cr.openjdk.java.net/~alanb/8196787/webrev/ > > There are a few small clean-ups in the patch, this is mostly to keep as much noise out of the follow-up changes. The dropping of the ready parameter from the native checkConnect is clean-up as the readyToConnect flag (dates from 1.4) isn't always reliable to use. > > -Alan > From pavel.rappo at oracle.com Mon Feb 5 17:00:40 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 5 Feb 2018 17:00:40 +0000 Subject: 8196787: (ch) Moving network channels to use j.u.c locks In-Reply-To: <84cfb7c5-ed9a-604e-dd66-26bd24dd0f03@oracle.com> References: <84cfb7c5-ed9a-604e-dd66-26bd24dd0f03@oracle.com> Message-ID: <254D5E65-D170-4F84-8C3D-C271EEA6EAEC@oracle.com> It's not immediately obvious why the ensureOpen method went into the critical section in SinkChannelImpl (x2): 161 public int write(ByteBuffer src) throws IOException { 162 writeLock.lock(); 163 try { -> 164 ensureOpen(); and in SourceChannelImpl (x2) 161 public int read(ByteBuffer dst) throws IOException { 162 163 readLock.lock(); 164 try { -> 165 ensureOpen(); From what I can see in the ensureOpen body, the close field doesn't seem to be guarded by neither of those locks, on the other hand the visibility is fully ensured by the close field being volatile. I feel like I definitely missing something though. > On 5 Feb 2018, at 16:27, Alan Bateman wrote: > > > I have a number of patches in the works that re-work some of the locking in the NIO networking channels and also split the blocking and non-blocking code paths. Part of the motivation is the complexity/overhead dealing with async close and interrupt of blocking operations, another part is preliminary work to prepare the implementations for fibers. > > To get started, I'd like to replace the read/write locks used in the networking channels to use j.u.c. locks. The changes are easy to review: > http://cr.openjdk.java.net/~alanb/8196787/webrev/ > > There are a few small clean-ups in the patch, this is mostly to keep as much noise out of the follow-up changes. The dropping of the ready parameter from the native checkConnect is clean-up as the readyToConnect flag (dates from 1.4) isn't always reliable to use. > > -Alan > From Alan.Bateman at oracle.com Mon Feb 5 17:04:57 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Feb 2018 17:04:57 +0000 Subject: 8196787: (ch) Moving network channels to use j.u.c locks In-Reply-To: <254D5E65-D170-4F84-8C3D-C271EEA6EAEC@oracle.com> References: <84cfb7c5-ed9a-604e-dd66-26bd24dd0f03@oracle.com> <254D5E65-D170-4F84-8C3D-C271EEA6EAEC@oracle.com> Message-ID: On 05/02/2018 17:00, Pavel Rappo wrote: > It's not immediately obvious why the ensureOpen method went into the critical > section in SinkChannelImpl (x2): > > 161 public int write(ByteBuffer src) throws IOException { > 162 writeLock.lock(); > 163 try { > -> 164 ensureOpen(); > > and in SourceChannelImpl (x2) > > 161 public int read(ByteBuffer dst) throws IOException { > 162 > 163 readLock.lock(); > 164 try { > -> 165 ensureOpen(); > > From what I can see in the ensureOpen body, the close field doesn't seem to be > guarded by neither of those locks, on the other hand the visibility is fully > ensured by the close field being volatile. I feel like I definitely missing > something though. The async close of these Pipe source/sink classes has been incorrect since 1.4. It will be fixed in a follow-up patch that re-works the async close where it will be clearer why the isOpen must be checked while holding the readLock. -Alan From brian.burkhalter at oracle.com Mon Feb 5 19:51:55 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 5 Feb 2018 11:51:55 -0800 Subject: [8u] RFR(M): 8168628/8171452: (fc) SIGBUS when extending file size to map it In-Reply-To: References: Message-ID: <9D1BDC30-566E-4D8A-9440-E0E1365829D8@oracle.com> On Feb 5, 2018, at 7:05 AM, Alan Bateman wrote: >> webrev combining above two fixes for review: >> http://cr.openjdk.java.net/~dbuck/8168628_jdk8_ver00/ >> > I've looked through the combined changes and they look okay to me. Likewise +1 Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Mon Feb 5 19:52:06 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 5 Feb 2018 14:52:06 -0500 Subject: 8196787: (ch) Moving network channels to use j.u.c locks In-Reply-To: References: <84cfb7c5-ed9a-604e-dd66-26bd24dd0f03@oracle.com> <254D5E65-D170-4F84-8C3D-C271EEA6EAEC@oracle.com> Message-ID: <947ccf93-006b-969d-4f15-9b2aab8f8a13@Oracle.com> Hi ALan, Looks fine as a straightforward replacement of synchronized. SocketChannelImpl.java: 764-5: re-wrap like 777? Regards, Roger Alan Bateman wrote: > > > On 05/02/2018 17:00, Pavel Rappo wrote: >> It's not immediately obvious why the ensureOpen method went into the >> critical >> section in SinkChannelImpl (x2): >> >> ??? 161???? public int write(ByteBuffer src) throws IOException { >> ??? 162???????? writeLock.lock(); >> ??? 163???????? try { >> -> 164???????????? ensureOpen(); >> >> and in SourceChannelImpl (x2) >> >> ????? 161???? public int read(ByteBuffer dst) throws IOException { >> ????? 162 >> ????? 163???????? readLock.lock(); >> ????? 164???????? try { >> ->?? 165???????????? ensureOpen(); >> >> ?From what I can see in the ensureOpen body, the close field doesn't >> seem to be >> guarded by neither of those locks, on the other hand the visibility >> is fully >> ensured by the close field being volatile. I feel like I definitely >> missing >> something though. > The async close of these Pipe source/sink classes has been incorrect > since 1.4. It will be fixed in a follow-up patch that re-works the > async close where it will be clearer why the isOpen must be checked > while holding the readLock. > > -Alan From brian.burkhalter at oracle.com Tue Feb 6 01:17:04 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 5 Feb 2018 17:17:04 -0800 Subject: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests Message-ID: https://bugs.openjdk.java.net/browse/JDK-8191416 http://cr.openjdk.java.net/~bpb/8191416/webrev.00/ As suggested in the issue description, change force(), load(), and isLoaded() to be no-ops when there is no backing file instead of throwing UnsupportedOperationException. Thanks, Brian From pavel.rappo at oracle.com Tue Feb 6 15:31:46 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 6 Feb 2018 15:31:46 +0000 Subject: 8196787: (ch) Moving network channels to use j.u.c locks In-Reply-To: References: <84cfb7c5-ed9a-604e-dd66-26bd24dd0f03@oracle.com> <254D5E65-D170-4F84-8C3D-C271EEA6EAEC@oracle.com> Message-ID: <53978F4A-470F-40EE-9967-121893F5AF6A@oracle.com> > On 5 Feb 2018, at 17:04, Alan Bateman wrote: > > The async close of these Pipe source/sink classes has been incorrect since 1.4. It will be fixed in a follow-up patch that re-works the async close where it will be clearer why the isOpen must be checked while holding the readLock. > > -Alan I'm fine with the changes. Thanks. From Roger.Riggs at Oracle.com Tue Feb 6 16:42:52 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Feb 2018 11:42:52 -0500 Subject: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests In-Reply-To: References: Message-ID: Hi Brian, Looks fine. (I'm not sure I would describe the behavior as a no-op; since I think they do achieve the invariant as defined). Roger On 2/5/2018 8:17 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8191416 > http://cr.openjdk.java.net/~bpb/8191416/webrev.00/ > > As suggested in the issue description, change force(), load(), and isLoaded() to be no-ops when there is no backing file instead of throwing UnsupportedOperationException. > > Thanks, > > Brian From Alan.Bateman at oracle.com Tue Feb 6 16:41:23 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 6 Feb 2018 16:41:23 +0000 Subject: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests In-Reply-To: References: Message-ID: <1d060c03-0615-8eff-2b28-2e44742a2eb5@oracle.com> On 06/02/2018 01:17, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8191416 > http://cr.openjdk.java.net/~bpb/8191416/webrev.00/ > > As suggested in the issue description, change force(), load(), and isLoaded() to be no-ops when there is no backing file instead of throwing UnsupportedOperationException. > It's an undocumented implementation detail that a direct buffer is a MappedByteBuffer. This dates back to the original implementation, is complicated to change, and maybe we should put the effort re-visiting it.? I read this patch as a short term mitigation for those that test if a buffer is a MappedByteBuffer so they can call force. I guess it's okay although I do wonder if this mitigation should be limited to force and don't touch loaded/isLoaded. Minor comment is that the other methods uses "mapping" in the name so maybe hasFileMapping might be better. -Alan From brian.burkhalter at oracle.com Tue Feb 6 19:41:01 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 6 Feb 2018 11:41:01 -0800 Subject: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests In-Reply-To: <1d060c03-0615-8eff-2b28-2e44742a2eb5@oracle.com> References: <1d060c03-0615-8eff-2b28-2e44742a2eb5@oracle.com> Message-ID: On Feb 6, 2018, at 8:41 AM, Alan Bateman wrote: > On 06/02/2018 01:17, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8191416 >> http://cr.openjdk.java.net/~bpb/8191416/webrev.00/ >> >> As suggested in the issue description, change force(), load(), and isLoaded() to be no-ops when there is no backing file instead of throwing UnsupportedOperationException. >> > It's an undocumented implementation detail that a direct buffer is a MappedByteBuffer. This dates back to the original implementation, is complicated to change, and maybe we should put the effort re-visiting it. So skip this mitigation or go ahead with it and follow with a more thorough re-visiting under a separate issue? > I read this patch as a short term mitigation for those that test if a buffer is a MappedByteBuffer so they can call force. I guess it's okay although I do wonder if this mitigation should be limited to force and don't touch loaded/isLoaded. These seem harmless however. > Minor comment is that the other methods uses "mapping" in the name so maybe hasFileMapping might be better. I?ll change it. On Feb 6, 2018, at 8:42 AM, Roger Riggs wrote: > (I'm not sure I would describe the behavior as a no-op; since I think they do achieve the invariant as defined). OK can change the description. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Feb 6 20:33:38 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 6 Feb 2018 21:33:38 +0100 (CET) Subject: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests In-Reply-To: <1d060c03-0615-8eff-2b28-2e44742a2eb5@oracle.com> References: <1d060c03-0615-8eff-2b28-2e44742a2eb5@oracle.com> Message-ID: <1503893560.1028489.1517949218041.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "Brian Burkhalter" , "nio-dev" > Envoy?: Mardi 6 F?vrier 2018 17:41:23 > Objet: Re: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests > On 06/02/2018 01:17, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8191416 >> http://cr.openjdk.java.net/~bpb/8191416/webrev.00/ >> >> As suggested in the issue description, change force(), load(), and isLoaded() to >> be no-ops when there is no backing file instead of throwing >> UnsupportedOperationException. >> > It's an undocumented implementation detail that a direct buffer is a > MappedByteBuffer. This dates back to the original implementation, is > complicated to change, and maybe we should put the effort re-visiting > it.? I read this patch as a short term mitigation for those that test if > a buffer is a MappedByteBuffer so they can call force. I guess it's okay > although I do wonder if this mitigation should be limited to force and > don't touch loaded/isLoaded. Revisiting this hack without introducing a perf penalty is not obvious, with a DirectByteBuffer being a MappedByteBuffer and if you do not use read-only buffers, DirectByteBuffer is the only implementation that will be loaded, so the JIT will not insert any typechecks before invoking a method on a ByteBuffer thanks to the class hierarchy analysis optimization. > > Minor comment is that the other methods uses "mapping" in the name so > maybe hasFileMapping might be better. or remove the method hasMappedFile and inline the body in all the calling methods given it's now a simple == test. > > -Alan R?mi From pavel.rappo at oracle.com Wed Feb 7 11:29:08 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 7 Feb 2018 11:29:08 +0000 Subject: RFR 8196908: (ch, fs) Safe publication of monitor objects and some others Message-ID: Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8196908/webrev.00/ This change addresses a number of issues with safe publication and covers some trivial typos. It seems that there are more similar issues in that area. However, I believe it is better to be rather conservative and firstly address issues that are pretty straightforward. Thanks, -Pavel From Alan.Bateman at oracle.com Wed Feb 7 12:07:42 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Feb 2018 12:07:42 +0000 Subject: RFR 8196908: (ch, fs) Safe publication of monitor objects and some others In-Reply-To: References: Message-ID: <452a316d-61a8-cef0-76c1-60af400b342a@oracle.com> On 07/02/2018 11:29, Pavel Rappo wrote: > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8196908/webrev.00/ > > This change addresses a number of issues with safe publication and covers some > trivial typos. It seems that there are more similar issues in that area. > However, I believe it is better to be rather conservative and firstly address > issues that are pretty straightforward. > This look good, the only thing to check is the new asserts in SelectorImpl.implRegister and whether they push the method size over an inlining threshold. As they are useful when changing this area then you could add them commented out if you want. -Alan From daniel.fuchs at oracle.com Wed Feb 7 12:33:20 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 7 Feb 2018 12:33:20 +0000 Subject: RFR 8196908: (ch, fs) Safe publication of monitor objects and some others In-Reply-To: References: Message-ID: <827b5d50-1873-9e1f-fa7e-9637660080e5@oracle.com> Hi Pavel, KQueueArrayWrapper.java: I think you can make is64bit final. cheers, -- daniel On 07/02/2018 11:29, Pavel Rappo wrote: > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8196908/webrev.00/ > > This change addresses a number of issues with safe publication and covers some > trivial typos. It seems that there are more similar issues in that area. > However, I believe it is better to be rather conservative and firstly address > issues that are pretty straightforward. > > Thanks, > -Pavel > From Alan.Bateman at oracle.com Wed Feb 7 14:45:09 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Feb 2018 14:45:09 +0000 Subject: 8196956: (ch) More channels cleanup Message-ID: This is a further small patch to the network channels in advance of more complicated changes to split the blocking/non-blocking code paths. The changes in this patch are very simple and amount to: - AbstractSelectableChannel::isBlocking changed to not block on regLock - the ServerSocketChannel socket adaptors now consistently checks the blocking mode - fix DatagramChannelImpl constructor to consistency track the the UDP socket usage The webrev is here: ? http://cr.openjdk.java.net/~alanb/8196956/webrev/index.html (ignore the change to make/autoconf/lib-bundled.m4 in the patch, this is to workaround temporary build breakage with build changes pushed to jdk/jdk yesterday). -Alan From Roger.Riggs at Oracle.com Wed Feb 7 18:03:16 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Feb 2018 13:03:16 -0500 Subject: 8196956: (ch) More channels cleanup In-Reply-To: References: Message-ID: <3980c09c-ddb5-9956-0851-ce9555a1c2c1@Oracle.com> Hi Alan, AbstractSelectableChannel.java: 78:? Keeping the boolean consistent with the methods will make the code a bit easier to maintain. And configureBlocking logic would be clearer. Otherwise, Looks fine. Roger On 2/7/2018 9:45 AM, Alan Bateman wrote: > > This is a further small patch to the network channels in advance of > more complicated changes to split the blocking/non-blocking code > paths. The changes in this patch are very simple and amount to: > > - AbstractSelectableChannel::isBlocking changed to not block on regLock > - the ServerSocketChannel socket adaptors now consistently checks the > blocking mode > - fix DatagramChannelImpl constructor to consistency track the the UDP > socket usage > > The webrev is here: > ? http://cr.openjdk.java.net/~alanb/8196956/webrev/index.html > > (ignore the change to make/autoconf/lib-bundled.m4 in the patch, this > is to workaround temporary build breakage with build changes pushed to > jdk/jdk yesterday). > > -Alan From Alan.Bateman at oracle.com Wed Feb 7 18:09:17 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Feb 2018 18:09:17 +0000 Subject: 8196956: (ch) More channels cleanup In-Reply-To: <3980c09c-ddb5-9956-0851-ce9555a1c2c1@Oracle.com> References: <3980c09c-ddb5-9956-0851-ce9555a1c2c1@Oracle.com> Message-ID: On 07/02/2018 18:03, Roger Riggs wrote: > Hi Alan, > > > AbstractSelectableChannel.java: 78:? Keeping the boolean consistent > with the methods > will make the code a bit easier to maintain. It is inverted to avoid the volatile write at initialization time. It makes configureBlocking a bit harder to read but I think we can live with that. -Alan From pavel.rappo at oracle.com Wed Feb 7 18:09:31 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 7 Feb 2018 18:09:31 +0000 Subject: 8196956: (ch) More channels cleanup In-Reply-To: References: Message-ID: Looks good. > On 7 Feb 2018, at 14:45, Alan Bateman wrote: > > > This is a further small patch to the network channels in advance of more complicated changes to split the blocking/non-blocking code paths. The changes in this patch are very simple and amount to: > > - AbstractSelectableChannel::isBlocking changed to not block on regLock > - the ServerSocketChannel socket adaptors now consistently checks the blocking mode > - fix DatagramChannelImpl constructor to consistency track the the UDP socket usage > > The webrev is here: > http://cr.openjdk.java.net/~alanb/8196956/webrev/index.html > > (ignore the change to make/autoconf/lib-bundled.m4 in the patch, this is to workaround temporary build breakage with build changes pushed to jdk/jdk yesterday). > > -Alan From brian.burkhalter at oracle.com Thu Feb 8 00:40:15 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Feb 2018 16:40:15 -0800 Subject: RFR 8197141: Add java/nio/file/WatchService/LotsOfCancels.java to ProblemList on Solaris Message-ID: <8DC6AB22-054F-4CB4-909A-BDE84383E0CC@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8197141 --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -341,6 +341,7 @@ java/nio/file/WatchService/Basic.java 7158947 solaris-all Solaris 11 java/nio/file/WatchService/MayFlies.java 7158947 solaris-all Solaris 11 +java/nio/file/WatchService/LotsOfCancels.java 8188039 solaris-all Solaris 11 java/nio/file/WatchService/LotsOfEvents.java 7158947 solaris-all Solaris 11 Thanks, Brian From brian.burkhalter at oracle.com Thu Feb 8 01:17:08 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Feb 2018 17:17:08 -0800 Subject: 8196956: (ch) More channels cleanup In-Reply-To: References: Message-ID: +1 On Feb 7, 2018, at 10:09 AM, Pavel Rappo wrote: > Looks good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 8 01:22:02 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Feb 2018 17:22:02 -0800 Subject: RFR 8196908: (ch, fs) Safe publication of monitor objects and some others In-Reply-To: <452a316d-61a8-cef0-76c1-60af400b342a@oracle.com> References: <452a316d-61a8-cef0-76c1-60af400b342a@oracle.com> Message-ID: Hi Pavel, +1 Brian On Feb 7, 2018, at 4:07 AM, Alan Bateman wrote: > On 07/02/2018 11:29, Pavel Rappo wrote: >> Hello, >> >> Please review the following change: >> >> http://cr.openjdk.java.net/~prappo/8196908/webrev.00/ >> >> This change addresses a number of issues with safe publication and covers some >> trivial typos. It seems that there are more similar issues in that area. >> However, I believe it is better to be rather conservative and firstly address >> issues that are pretty straightforward. >> > This look good, the only thing to check is the new asserts in SelectorImpl.implRegister and whether they push the method size over an inlining threshold. As they are useful when changing this area then you could add them commented out if you want. On Feb 7, 2018, at 4:33 AM, Daniel Fuchs wrote: > Hi Pavel, > > KQueueArrayWrapper.java: I think you can make is64bit final. > > cheers, > > -- daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.riggs at oracle.com Thu Feb 8 02:07:53 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 7 Feb 2018 21:07:53 -0500 Subject: RFR 8197141: Add java/nio/file/WatchService/LotsOfCancels.java to ProblemList on Solaris In-Reply-To: <8DC6AB22-054F-4CB4-909A-BDE84383E0CC@oracle.com> References: <8DC6AB22-054F-4CB4-909A-BDE84383E0CC@oracle.com> Message-ID: <7e55baf2-9e8a-b09e-4a60-cedf16c043d5@oracle.com> +1 On 2/7/18 7:40 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8197141 > > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -341,6 +341,7 @@ > > java/nio/file/WatchService/Basic.java 7158947 solaris-all Solaris 11 > java/nio/file/WatchService/MayFlies.java 7158947 solaris-all Solaris 11 > +java/nio/file/WatchService/LotsOfCancels.java 8188039 solaris-all Solaris 11 > java/nio/file/WatchService/LotsOfEvents.java 7158947 solaris-all Solaris 11 > > Thanks, > > Brian From brian.burkhalter at oracle.com Thu Feb 8 19:44:36 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 8 Feb 2018 11:44:36 -0800 Subject: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests In-Reply-To: <1503893560.1028489.1517949218041.JavaMail.zimbra@u-pem.fr> References: <1d060c03-0615-8eff-2b28-2e44742a2eb5@oracle.com> <1503893560.1028489.1517949218041.JavaMail.zimbra@u-pem.fr> Message-ID: <3AB3E102-FF93-495F-9566-774D9A233E37@oracle.com> On Feb 6, 2018, at 12:33 PM, Remi Forax wrote: >> Minor comment is that the other methods uses "mapping" in the name so >> maybe hasFileMapping might be better. > > or remove the method hasMappedFile and inline the body in all the calling methods given it's now a simple == test. Updated patch with hasMappedFile() inlined: http://cr.openjdk.java.net/~bpb/8191416/webrev.01/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Thu Feb 8 20:05:16 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Feb 2018 15:05:16 -0500 Subject: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests In-Reply-To: <3AB3E102-FF93-495F-9566-774D9A233E37@oracle.com> References: <1d060c03-0615-8eff-2b28-2e44742a2eb5@oracle.com> <1503893560.1028489.1517949218041.JavaMail.zimbra@u-pem.fr> <3AB3E102-FF93-495F-9566-774D9A233E37@oracle.com> Message-ID: +1 On 2/8/2018 2:44 PM, Brian Burkhalter wrote: > On Feb 6, 2018, at 12:33 PM, Remi Forax > wrote: > >>> Minor comment is that the other methods uses "mapping" in the name so >>> maybe hasFileMapping might be better. >> >> or remove the method hasMappedFile and inline the body in all the >> calling methods given it's now a simple == test. > > Updated patch with hasMappedFile() inlined: > > http://cr.openjdk.java.net/~bpb/8191416/webrev.01/ > > > Thanks, > > Brian From Alan.Bateman at oracle.com Fri Feb 9 08:41:58 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Feb 2018 08:41:58 +0000 Subject: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests In-Reply-To: <3AB3E102-FF93-495F-9566-774D9A233E37@oracle.com> References: <1d060c03-0615-8eff-2b28-2e44742a2eb5@oracle.com> <1503893560.1028489.1517949218041.JavaMail.zimbra@u-pem.fr> <3AB3E102-FF93-495F-9566-774D9A233E37@oracle.com> Message-ID: On 08/02/2018 19:44, Brian Burkhalter wrote: > > Updated patch with hasMappedFile() inlined: > > http://cr.openjdk.java.net/~bpb/8191416/webrev.01/ > > The changes to MBB are okay (I probably should drop the braces to keep it consistent with the existing code but it doesn't matter). I assume the test should pass if the direct buffer is not a sub-class of MBB - maybe you've put that check in there to force the test to be updated in the that the class hierarchy is fixed? The @summary line should probably be clear that it tests the MBB methods when a direct buffer is cast to a MBB. Future maintainers will not know what "UOE" is about. -Alan From forax at univ-mlv.fr Fri Feb 9 08:52:07 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 9 Feb 2018 09:52:07 +0100 (CET) Subject: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests In-Reply-To: <3AB3E102-FF93-495F-9566-774D9A233E37@oracle.com> References: <1d060c03-0615-8eff-2b28-2e44742a2eb5@oracle.com> <1503893560.1028489.1517949218041.JavaMail.zimbra@u-pem.fr> <3AB3E102-FF93-495F-9566-774D9A233E37@oracle.com> Message-ID: <712176058.2179420.1518166327256.JavaMail.zimbra@u-pem.fr> Looks good. R?mi > De: "Brian Burkhalter" > ?: "Remi Forax" > Cc: "Alan Bateman" , "nio-dev" > > Envoy?: Jeudi 8 F?vrier 2018 20:44:36 > Objet: Re: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses > instanceof tests > On Feb 6, 2018, at 12:33 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >>> Minor comment is that the other methods uses "mapping" in the name so >>> maybe hasFileMapping might be better. >> or remove the method hasMappedFile and inline the body in all the calling >> methods given it's now a simple == test. > Updated patch with hasMappedFile() inlined: > [ http://cr.openjdk.java.net/~bpb/8191416/webrev.01/ | > http://cr.openjdk.java.net/~bpb/8191416/webrev.01/ ] > Thanks, > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 9 15:29:08 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 9 Feb 2018 07:29:08 -0800 Subject: RFR 8191416: (bf) DirectByteBuffer extends MappedByteBuffer, confuses instanceof tests In-Reply-To: References: <1d060c03-0615-8eff-2b28-2e44742a2eb5@oracle.com> <1503893560.1028489.1517949218041.JavaMail.zimbra@u-pem.fr> <3AB3E102-FF93-495F-9566-774D9A233E37@oracle.com> Message-ID: <58D3CE7E-0C6B-44B0-981F-472A74A553D7@oracle.com> On Feb 9, 2018, at 12:41 AM, Alan Bateman wrote: > The changes to MBB are okay (I probably should drop the braces to keep it consistent with the existing code but it doesn't matter). > > I assume the test should pass if the direct buffer is not a sub-class of MBB - maybe you've put that check in there to force the test to be updated in the that the class hierarchy is fixed? The test fails (lines 36-37) if the DBB is not an instance of MBB. > The @summary line should probably be clear that it tests the MBB methods when a direct buffer is cast to a MBB. Future maintainers will not know what "UOE" is about. Will change once all other changes are agreed. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 9 15:33:05 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 9 Feb 2018 07:33:05 -0800 Subject: RFR 8019806: (se) kqueue implementation of Selector does not handle EINTR Message-ID: <15AF0E54-4D86-4D23-A8F9-CDF3896A2417@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8019806 https://bugs.openjdk.java.net/browse/JDK-8179307 http://cr.openjdk.java.net/~bpb/8019806/webrev.00/ Re-try kevent() if its return value is negative and errno is EINTR. Also change the exception message for the case where the return value is negative and errno is not EINTR. I was thinking that the issue should probably be noreg-hard but maybe there?s another idea. Thanks, Brian From brian.burkhalter at oracle.com Fri Feb 9 17:57:19 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 9 Feb 2018 09:57:19 -0800 Subject: RFR 8019806: (se) kqueue implementation of Selector does not handle EINTR In-Reply-To: <15AF0E54-4D86-4D23-A8F9-CDF3896A2417@oracle.com> References: <15AF0E54-4D86-4D23-A8F9-CDF3896A2417@oracle.com> Message-ID: On Feb 9, 2018, at 7:33 AM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8019806 > https://bugs.openjdk.java.net/browse/JDK-8179307 > > http://cr.openjdk.java.net/~bpb/8019806/webrev.00/ > > Re-try kevent() if its return value is negative and errno is EINTR. Also change the exception message for the case where the return value is negative and errno is not EINTR. > > I was thinking that the issue should probably be noreg-hard but maybe there?s another idea. This has been moved to a different issue https://bugs.openjdk.java.net/browse/JDK-8197498 and updated to use the RESTARTABLE macro http://cr.openjdk.java.net/~bpb/8197498/webrev.00/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Feb 9 19:28:12 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Feb 2018 19:28:12 +0000 Subject: RFR 8019806: (se) kqueue implementation of Selector does not handle EINTR In-Reply-To: References: <15AF0E54-4D86-4D23-A8F9-CDF3896A2417@oracle.com> Message-ID: <674db4bc-6fac-d9f8-098f-5b9ac39d4d7a@oracle.com> On 09/02/2018 17:57, Brian Burkhalter wrote: > > and updated to use the RESTARTABLE macro > > http://cr.openjdk.java.net/~bpb/8197498/webrev.00/ > > Looks good. From brian.burkhalter at oracle.com Wed Feb 14 00:09:24 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 13 Feb 2018 16:09:24 -0800 Subject: RFR 8144672: (ch) PipeImpl should use localhost instead of loopback address Message-ID: https://bugs.openjdk.java.net/browse/JDK-8144672 Replace the hard-coded IPv4 loopback address: --- a/src/java.base/windows/classes/sun/nio/ch/PipeImpl.java +++ b/src/java.base/windows/classes/sun/nio/ch/PipeImpl.java @@ -110,7 +110,7 @@ ByteBuffer bb = ByteBuffer.allocate(NUM_SECRET_BYTES); // Loopback address - InetAddress lb = InetAddress.getByName("127.0.0.1"); + InetAddress lb = InetAddress.getLoopbackAddress(); assert(lb.isLoopbackAddress()); Or would it be better to replace getLoopbackAddress() in the above with getLocalHost()? Doing the latter may impose a security manager check. Thanks, Brian From martinrb at google.com Wed Feb 14 02:01:11 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 13 Feb 2018 18:01:11 -0800 Subject: RFR 8144672: (ch) PipeImpl should use localhost instead of loopback address In-Reply-To: References: Message-ID: At least in tests, we've been replacing "127.0.0.1" with InetAddress.getLoopbackAddress().getHostAddress() On Tue, Feb 13, 2018 at 4:09 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > https://bugs.openjdk.java.net/browse/JDK-8144672 > > Replace the hard-coded IPv4 loopback address: > > --- a/src/java.base/windows/classes/sun/nio/ch/PipeImpl.java > +++ b/src/java.base/windows/classes/sun/nio/ch/PipeImpl.java > @@ -110,7 +110,7 @@ > ByteBuffer bb = ByteBuffer.allocate(NUM_ > SECRET_BYTES); > > // Loopback address > - InetAddress lb = InetAddress.getByName("127.0.0.1"); > + InetAddress lb = InetAddress.getLoopbackAddress(); > assert(lb.isLoopbackAddress()); > > Or would it be better to replace getLoopbackAddress() in the above with > getLocalHost()? Doing the latter may impose a security manager check. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 14 04:23:11 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 13 Feb 2018 20:23:11 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension Message-ID: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8057113 http://cr.openjdk.java.net/~bpb/8057113/webrev.00/ As a first cut at this problem, this patch would add a new method hasExtension() to the java.nio.file.Path interface with a default implementation. The implementation is overridden only by UnixPath. ZipPath does not override it but perhaps should. Regression tests passed on all platforms both with and without the UnixPath changes (in order to verify the default implementation on all platforms). Obviously a CSR will be in order. Thanks, Brian From Alan.Bateman at oracle.com Wed Feb 14 07:42:32 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Feb 2018 07:42:32 +0000 Subject: RFR 8144672: (ch) PipeImpl should use localhost instead of loopback address In-Reply-To: References: Message-ID: <3572c758-aa4d-6590-189d-04c24245ff28@oracle.com> On 14/02/2018 00:09, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8144672 > > Replace the hard-coded IPv4 loopback address: > > --- a/src/java.base/windows/classes/sun/nio/ch/PipeImpl.java > +++ b/src/java.base/windows/classes/sun/nio/ch/PipeImpl.java > @@ -110,7 +110,7 @@ > ByteBuffer bb = ByteBuffer.allocate(NUM_SECRET_BYTES); > > // Loopback address > - InetAddress lb = InetAddress.getByName("127.0.0.1"); > + InetAddress lb = InetAddress.getLoopbackAddress(); > assert(lb.isLoopbackAddress()); > > This looks okay to me. (I don't get Martin's comment about using getHostAddress, maybe useful for tests but you need an InetAddress here, not a String). -Alan From Alan.Bateman at oracle.com Wed Feb 14 07:38:56 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Feb 2018 07:38:56 +0000 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> Message-ID: <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> On 14/02/2018 04:23, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8057113 > http://cr.openjdk.java.net/~bpb/8057113/webrev.00/ > > As a first cut at this problem, this patch would add a new method hasExtension() to the java.nio.file.Path interface with a default implementation. The implementation is overridden only by UnixPath. ZipPath does not override it but perhaps should. > > Regression tests passed on all platforms both with and without the UnixPath changes (in order to verify the default implementation on all platforms). > > Obviously a CSR will be in order. I don't think this is the right API to add. While it has issues, I think we need to look at getExtension that returns as String. An important point is that the API will need to define what an extension is because it currently doesn't have this notion. -Alan From forax at univ-mlv.fr Wed Feb 14 08:24:06 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 14 Feb 2018 09:24:06 +0100 (CET) Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> Message-ID: <155375175.1288141.1518596646831.JavaMail.zimbra@u-pem.fr> I agree with Alan, getExtension() is better than hasExtension() which solidify how the extension matching is done, the user code should decide how the matching is done. for the definition, everything after the last '.' is good for me. R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Brian Burkhalter" , "nio-dev" > Envoy?: Mercredi 14 F?vrier 2018 08:38:56 > Objet: Re: RFR 8057113: (fs) Path should have a method to test the filename extension > On 14/02/2018 04:23, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8057113 >> http://cr.openjdk.java.net/~bpb/8057113/webrev.00/ >> >> As a first cut at this problem, this patch would add a new method hasExtension() >> to the java.nio.file.Path interface with a default implementation. The >> implementation is overridden only by UnixPath. ZipPath does not override it but >> perhaps should. >> >> Regression tests passed on all platforms both with and without the UnixPath >> changes (in order to verify the default implementation on all platforms). >> >> Obviously a CSR will be in order. > I don't think this is the right API to add. While it has issues, I think > we need to look at getExtension that returns as String. An important > point is that the API will need to define what an extension is because > it currently doesn't have this notion. > > -Alan From christoph.langer at sap.com Wed Feb 14 08:24:58 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 14 Feb 2018 08:24:58 +0000 Subject: RFR 8144672: (ch) PipeImpl should use localhost instead of loopback address In-Reply-To: <3572c758-aa4d-6590-189d-04c24245ff28@oracle.com> References: <3572c758-aa4d-6590-189d-04c24245ff28@oracle.com> Message-ID: <99878661b1f7428287d8d710e0588f7e@sap.com> +1 Best regards Christoph > -----Original Message----- > From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of > Alan Bateman > Sent: Mittwoch, 14. Februar 2018 08:43 > To: Brian Burkhalter ; nio-dev dev at openjdk.java.net> > Subject: Re: RFR 8144672: (ch) PipeImpl should use localhost instead of > loopback address > > On 14/02/2018 00:09, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8144672 > > > > Replace the hard-coded IPv4 loopback address: > > > > --- a/src/java.base/windows/classes/sun/nio/ch/PipeImpl.java > > +++ b/src/java.base/windows/classes/sun/nio/ch/PipeImpl.java > > @@ -110,7 +110,7 @@ > > ByteBuffer bb = ByteBuffer.allocate(NUM_SECRET_BYTES); > > > > // Loopback address > > - InetAddress lb = InetAddress.getByName("127.0.0.1"); > > + InetAddress lb = InetAddress.getLoopbackAddress(); > > assert(lb.isLoopbackAddress()); > > > > > This looks okay to me. > > (I don't get Martin's comment about using getHostAddress, maybe useful > for tests but you need an InetAddress here, not a String). > > -Alan From david.lloyd at redhat.com Wed Feb 14 14:11:18 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 14 Feb 2018 08:11:18 -0600 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <155375175.1288141.1518596646831.JavaMail.zimbra@u-pem.fr> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <155375175.1288141.1518596646831.JavaMail.zimbra@u-pem.fr> Message-ID: ...unless maybe the last '.' is the first character in the path, or immediately follows a sequence of '.' that starts with the first character in the path? On Wed, Feb 14, 2018 at 2:24 AM, Remi Forax wrote: > I agree with Alan, > getExtension() is better than hasExtension() which solidify how the extension matching is done, the user code should decide how the matching is done. > > for the definition, everything after the last '.' is good for me. > > R?mi > > ----- Mail original ----- >> De: "Alan Bateman" >> ?: "Brian Burkhalter" , "nio-dev" >> Envoy?: Mercredi 14 F?vrier 2018 08:38:56 >> Objet: Re: RFR 8057113: (fs) Path should have a method to test the filename extension > >> On 14/02/2018 04:23, Brian Burkhalter wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8057113 >>> http://cr.openjdk.java.net/~bpb/8057113/webrev.00/ >>> >>> As a first cut at this problem, this patch would add a new method hasExtension() >>> to the java.nio.file.Path interface with a default implementation. The >>> implementation is overridden only by UnixPath. ZipPath does not override it but >>> perhaps should. >>> >>> Regression tests passed on all platforms both with and without the UnixPath >>> changes (in order to verify the default implementation on all platforms). >>> >>> Obviously a CSR will be in order. >> I don't think this is the right API to add. While it has issues, I think >> we need to look at getExtension that returns as String. An important >> point is that the API will need to define what an extension is because >> it currently doesn't have this notion. >> >> -Alan -- - DML From Roger.Riggs at Oracle.com Wed Feb 14 15:00:09 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 14 Feb 2018 10:00:09 -0500 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <155375175.1288141.1518596646831.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, The java.nio.Files.probeContentType(Path) definition of extension should be consistent with this. (Or vise-versa) AbstractFileTypeDetector.getExtension(): * Returns the extension of a file name, specifically the portion of the * parameter string after the first dot. I agree getExtension() is more generally useful and leave the matching to the caller. $.02, Roger On 2/14/2018 9:11 AM, David Lloyd wrote: > ...unless maybe the last '.' is the first character in the path, or > immediately follows a sequence of '.' that starts with the first > character in the path? > > On Wed, Feb 14, 2018 at 2:24 AM, Remi Forax wrote: >> I agree with Alan, >> getExtension() is better than hasExtension() which solidify how the extension matching is done, the user code should decide how the matching is done. >> >> for the definition, everything after the last '.' is good for me. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Alan Bateman" >>> ?: "Brian Burkhalter" , "nio-dev" >>> Envoy?: Mercredi 14 F?vrier 2018 08:38:56 >>> Objet: Re: RFR 8057113: (fs) Path should have a method to test the filename extension >>> On 14/02/2018 04:23, Brian Burkhalter wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8057113 >>>> http://cr.openjdk.java.net/~bpb/8057113/webrev.00/ >>>> >>>> As a first cut at this problem, this patch would add a new method hasExtension() >>>> to the java.nio.file.Path interface with a default implementation. The >>>> implementation is overridden only by UnixPath. ZipPath does not override it but >>>> perhaps should. >>>> >>>> Regression tests passed on all platforms both with and without the UnixPath >>>> changes (in order to verify the default implementation on all platforms). >>>> >>>> Obviously a CSR will be in order. >>> I don't think this is the right API to add. While it has issues, I think >>> we need to look at getExtension that returns as String. An important >>> point is that the API will need to define what an extension is because >>> it currently doesn't have this notion. >>> >>> -Alan > > From brian.burkhalter at oracle.com Wed Feb 14 15:49:02 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 14 Feb 2018 07:49:02 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> Message-ID: <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> Hi All and thanks for the comments. On Feb 13, 2018, at 11:38 PM, Alan Bateman wrote: > I don't think this is the right API to add. While it has issues, I think we need to look at getExtension that returns as String. The idea here was to allow matching multiple versions of the extension which correspond to a given format, for example, jpg, JPG, and jpeg. This could be useful to avoid multiple calls for cases where the file content can correspond to multiple extensions. > An important point is that the API will need to define what an extension is because it currently doesn't have this notion. I defined it in the hasExtension() javadoc. On Feb 14, 2018, at 12:24 AM, Remi Forax wrote: > I agree with Alan, > getExtension() is better than hasExtension() which solidify how the extension matching is done, the user code should decide how the matching is done. I suppose one could have both methods were there justification. > for the definition, everything after the last '.' is good for me. Good. On Feb 14, 2018, at 6:11 AM, David Lloyd wrote: > ...unless maybe the last '.' is the first character in the path, or > immediately follows a sequence of '.' that starts with the first > character in the path? This case to me would map to no extension, i.e., either null or empty as one prefers. On Feb 14, 2018, at 7:00 AM, Roger Riggs wrote: > The java.nio.Files.probeContentType(Path) definition of extension should be consistent with this. > (Or vise-versa) > > AbstractFileTypeDetector.getExtension(): > * Returns the extension of a file name, specifically the portion of the > * parameter string after the first dot. > > I agree getExtension() is more generally useful and leave the matching to the caller. I read that before doing this. In the use case prompting this issue the foregoing definition would not work. I have always considered the extension to be that portion of the path after the last dot: "usually the extension is the substring which follows the last occurrence, if any, of the dot character? [1]. Thanks, Brian [1] https://en.wikipedia.org/wiki/Filename_extension -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Wed Feb 14 16:40:19 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 14 Feb 2018 08:40:19 -0800 Subject: RFR 8144672: (ch) PipeImpl should use localhost instead of loopback address In-Reply-To: <3572c758-aa4d-6590-189d-04c24245ff28@oracle.com> References: <3572c758-aa4d-6590-189d-04c24245ff28@oracle.com> Message-ID: On Tue, Feb 13, 2018 at 11:42 PM, Alan Bateman wrote: > > (I don't get Martin's comment about using getHostAddress, maybe useful for > tests but you need an InetAddress here, not a String). Yeah, I was focused on what we've done to replace the String "127.0.0.1" and I saw that String here. TL;DR - use InetAddress.getLoopbackAddress() (as this change proposes) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Wed Feb 14 18:14:30 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 14 Feb 2018 13:14:30 -0500 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> Message-ID: <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> Hi Brian, Ok, but perhaps we should (separately) fix probeContentType to use the same rule (last occurrence of dot). Thanks, Roger On 2/14/2018 10:49 AM, Brian Burkhalter wrote: > >> The java.nio.Files.probeContentType(Path) definition of extension >> should be consistent with this. >> (Or vise-versa) >> >> ??AbstractFileTypeDetector.getExtension(): >> ??* Returns the extension of a file name, specifically the portion of the >> ??* parameter string after the first dot. >> >> I agree getExtension() is more generally useful and leave the >> matching to the caller. > > > I read that before doing this. In the use case prompting this issue > the foregoing definition would not work. I have always considered the > extension to be that portion of the path after the last dot: "usually > the extension is the substring which follows the last occurrence, if > any, of the dot character? [1]. > > Thanks, > > Brian > > [1] https://en.wikipedia.org/wiki/Filename_extension From Alan.Bateman at oracle.com Wed Feb 14 18:25:30 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Feb 2018 18:25:30 +0000 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> Message-ID: <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> On 14/02/2018 18:14, Roger Riggs wrote: > Hi Brian, > > Ok, but perhaps we should (separately) fix probeContentType to use the > same rule > (last occurrence of dot). Files.probeContentType doesn't depend on file extensions so I don't think it needs anything. -Alan From brian.burkhalter at oracle.com Wed Feb 14 18:59:23 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 14 Feb 2018 10:59:23 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> Message-ID: <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> Roger / Alan, On Feb 14, 2018, at 10:25 AM, Alan Bateman wrote: > On 14/02/2018 18:14, Roger Riggs wrote: >> Hi Brian, >> >> Ok, but perhaps we should (separately) fix probeContentType to use the same rule >> (last occurrence of dot). That seems appropriate. To me using the first dot is incorrect. Would need to investigate why it?s that way at least for that one method. > Files.probeContentType doesn't depend on file extensions so I don't think it needs anything. I don?t believe that is true. It looks as if the extension is used to key into the appropriate mapping (~/.mime.types, /etc/mime.types, macOS UTI, Windows registry, or the URLConnection database) to find the content type. In any case this probe area is somewhat problematic as we know. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Feb 15 16:54:48 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 15 Feb 2018 08:54:48 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> Message-ID: <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> http://cr.openjdk.java.net/~bpb/8057113/webrev.01/ I updated the patch to add to j.n.f.Path String getExtension() instead of boolean hasExtension(String?). The previously mentioned use case of a given file type having multiple possible extensions may be trivially handled for example as Set.of(?jpg?, ?JPG?, ?jpeg?).contains(path.getExtension()) The class javadoc of Path was also updated to put the concept of extension in context. Thanks, Brian From daniel.fuchs at oracle.com Thu Feb 15 17:04:58 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 15 Feb 2018 17:04:58 +0000 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> Message-ID: Hi Brian, 185 String path = toString(); shouldn't this be String path = getFileName().toString()? I wonder if the specification of getExtension() should be defined has being a substring of getFileName()? best regards, -- daniel On 15/02/2018 16:54, Brian Burkhalter wrote: > http://cr.openjdk.java.net/~bpb/8057113/webrev.01/ > > I updated the patch to add to j.n.f.Path > > String getExtension() > > instead of > > boolean hasExtension(String?). > > The previously mentioned use case of a given file type having multiple possible extensions may be trivially handled for example as > > Set.of(?jpg?, ?JPG?, ?jpeg?).contains(path.getExtension()) > > The class javadoc of Path was also updated to put the concept of extension in context. > > Thanks, > > Brian > From Alan.Bateman at oracle.com Thu Feb 15 17:22:29 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Feb 2018 17:22:29 +0000 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> Message-ID: <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> On 15/02/2018 17:04, Daniel Fuchs wrote: > Hi Brian, > > 185???????? String path = toString(); > > shouldn't this be > > String path = getFileName().toString()? > > I wonder if the specification of getExtension() should > be defined has being a substring of getFileName()? Right, there are a couple of issues that follow on from that, esp. when you get into Path objects that only have a root component (C: or / for example). -Alan From brian.burkhalter at oracle.com Thu Feb 15 17:59:18 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 15 Feb 2018 09:59:18 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> Message-ID: <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> Daniel / Alan, On Feb 15, 2018, at 9:22 AM, Alan Bateman wrote: > On 15/02/2018 17:04, Daniel Fuchs wrote: >> Hi Brian, >> >> 185 String path = toString(); >> >> shouldn't this be >> >> String path = getFileName().toString()? That would simplify things. >> I wonder if the specification of getExtension() should >> be defined has being a substring of getFileName()? Seems like a good idea. > Right, there are a couple of issues that follow on from that, esp. when you get into Path objects that only have a root component (C: or / for example). If getFileName() is null then the extension would be empty, at least according to the direction in which I?ve been going. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Thu Feb 15 20:18:47 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 15 Feb 2018 15:18:47 -0500 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> Message-ID: Hi Brian, Possibly a premature optimization but the API spec should say "as if getFileName()". Perhaps the implementation can avoid actually creating a new Path and just look at the last element to extract the extension. $.02, Roger On 2/15/2018 12:59 PM, Brian Burkhalter wrote: > Daniel / Alan, > > On Feb 15, 2018, at 9:22 AM, Alan Bateman > wrote: > >> On 15/02/2018 17:04, Daniel Fuchs wrote: >>> Hi Brian, >>> >>> 185???????? String path = toString(); >>> >>> shouldn't this be >>> >>> String path = getFileName().toString()? > > That would simplify things. > >>> I wonder if the specification of getExtension() should >>> be defined has being a substring of getFileName()? > > Seems like a good idea. > >> Right, there are a couple of issues that follow on from that, esp. >> when you get into Path objects that only have a root component (C: or >> / for example). > > If getFileName() is null then the extension would be empty, at least > according to the direction in which I?ve been going. > > Thanks, > > Brian From brian.burkhalter at oracle.com Thu Feb 15 20:50:50 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 15 Feb 2018 12:50:50 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> Message-ID: <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> Hi Roger, On Feb 15, 2018, at 12:18 PM, Roger Riggs wrote: > Possibly a premature optimization but the API spec should say "as if getFileName()". > Perhaps the implementation can avoid actually creating a new Path and just look > at the last element to extract the extension That?s what I was thinking as well inspired by Daniel?s comment. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 16 02:53:37 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 15 Feb 2018 18:53:37 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> Message-ID: On Feb 15, 2018, at 12:50 PM, Brian Burkhalter wrote: >> Perhaps the implementation can avoid actually creating a new Path and just look >> at the last element to extract the extension > > That?s what I was thinking as well inspired by Daniel?s comment. Here is an updated version which changes the specification and implementation to define things in terms of the file name element instead of the entire Path. http://cr.openjdk.java.net/~bpb/8057113/webrev.02/ One question is whether the extension should instead be specified in terms of the *normalized* path. This is how the code already behaves. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Feb 16 07:21:07 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Feb 2018 07:21:07 +0000 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> Message-ID: <3b36bf35-2431-fe86-cb41-e1ad7f42398c@oracle.com> On 16/02/2018 02:53, Brian Burkhalter wrote: > > One question is whether the extension should instead be specified in > terms of the *normalized* path. This is how the ?code already behaves. > No, it has to specified on the string representation of the file name. I think we should initially confine the definition to the getExtension method and not attempt to put it in the class description at this time (as it will take several rounds to get the javadoc for this method agreed I think). -Alan. From david.lloyd at redhat.com Fri Feb 16 14:26:46 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 16 Feb 2018 08:26:46 -0600 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> Message-ID: On Thu, Feb 15, 2018 at 8:53 PM, Brian Burkhalter wrote: > Here is an updated version which changes the specification and > implementation to define things in terms of the file name element instead of > the entire Path. + default String getExtension() { + Path fname = getFileName(); + if (fname == null) { + return ""; + } + + String name = fname.toString(); + int lastDot = name.lastIndexOf("."); + if (lastDot == -1 || lastDot == name.length() - 1) { + return ""; + } + + return name.substring(lastDot + 1); + } If lastDot is 0 or all the characters preceding lastDot are '.' then "" should be returned as well; this for example will not only return wrong results for ".." but also e.g. ".vimrc". -- - DML From david.lloyd at redhat.com Fri Feb 16 14:27:34 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 16 Feb 2018 08:27:34 -0600 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> Message-ID: On Fri, Feb 16, 2018 at 8:26 AM, David Lloyd wrote: > On Thu, Feb 15, 2018 at 8:53 PM, Brian Burkhalter > wrote: >> Here is an updated version which changes the specification and >> implementation to define things in terms of the file name element instead of >> the entire Path. > > + default String getExtension() { > + Path fname = getFileName(); > + if (fname == null) { > + return ""; > + } > + > + String name = fname.toString(); > + int lastDot = name.lastIndexOf("."); > + if (lastDot == -1 || lastDot == name.length() - 1) { > + return ""; > + } > + > + return name.substring(lastDot + 1); > + } > > If lastDot is 0 or all the characters preceding lastDot are '.' then > "" should be returned as well; this for example will not only return > wrong results for ".." but also e.g. ".vimrc". Also you could do "name.lastIndexOf('.')" instead. -- - DML From brian.burkhalter at oracle.com Fri Feb 16 16:48:45 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 16 Feb 2018 08:48:45 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> Message-ID: <22E7EC04-EF35-4A43-AB6D-F26C95B45617@oracle.com> On Feb 16, 2018, at 6:26 AM, David Lloyd wrote: > If lastDot is 0 or all the characters preceding lastDot are '.' then > "" should be returned as well; this for example will not only return > wrong results for ".." but also e.g. ".vimrc". You are correct about ?.vimrc? but the other cases appear to pass (expected result in the test is ?? for these four cases): . -> . test getExtension Expected: true Actual: true ..... -> ..... test getExtension Expected: true Actual: true .. -> .. test getExtension Expected: true Actual: true .vimrc -> .vimrc test getExtension Expected: true Actual: false Looks at least as if ?? should be returned if the only dot in getFileName() is the first character. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Feb 16 18:06:37 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 16 Feb 2018 10:06:37 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <22E7EC04-EF35-4A43-AB6D-F26C95B45617@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> <22E7EC04-EF35-4A43-AB6D-F26C95B45617@oracle.com> Message-ID: <539CBD75-4F0A-42D0-8F98-AF781DB245CD@oracle.com> On Feb 16, 2018, at 8:48 AM, Brian Burkhalter wrote: > On Feb 16, 2018, at 6:26 AM, David Lloyd wrote: > >> If lastDot is 0 or all the characters preceding lastDot are '.' then >> "" should be returned as well; this for example will not only return >> wrong results for ".." but also e.g. ".vimrc". > > You are correct about ?.vimrc? but the other cases appear to pass (expected result in the test is ?? for these four cases): This seems to be getting too complicated with all the special cases. Perhaps this should just be re-specified simply always to return getFileName().substring(getFileName().lastIndexOf(?.?) + 1) unless getFileName() returns null or lastIndexOf(?.?) returns -1 in which cases ?? would be returned? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Feb 16 18:32:41 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 16 Feb 2018 18:32:41 +0000 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <539CBD75-4F0A-42D0-8F98-AF781DB245CD@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> <22E7EC04-EF35-4A43-AB6D-F26C95B45617@oracle.com> <539CBD75-4F0A-42D0-8F98-AF781DB245CD@oracle.com> Message-ID: <9d32ef6e-4bb0-4480-eeea-143ab5ec39aa@oracle.com> Hi Brian, As David noted, .vimrc is a filename - not an extension, and the Unix/Linux basename command will treat it as such: $ basename ~/.vimrc .vimrc .vimrc I think we should try to honor this expectation. However: $ basename ~/.vimrc.vimrc .vimrc .vimrc So would the code below work? String filename = Optional.ofNullable(getFilename()) .map(Object::toString).orElse(""); int index = filename.lastIndexOf('.'); if (index > 0) return filename.substring(index+1); else return "" best regards, -- daniel On 16/02/2018 18:06, Brian Burkhalter wrote: > On Feb 16, 2018, at 8:48 AM, Brian Burkhalter > > wrote: > >> On Feb 16, 2018, at 6:26 AM, David Lloyd > > wrote: >> >>> If lastDot is 0 or all the characters preceding lastDot are '.' then >>> "" should be returned as well; this for example will not only return >>> wrong results for ".." but also e.g. ".vimrc". >> >> You are correct about ?.vimrc? but the other cases appear to pass >> (expected result in the test is ?? for these four cases): > > This seems to be getting too complicated with all the special cases. > Perhaps this should just be re-specified simply always to return > > getFileName().substring(getFileName().lastIndexOf(?.?) + 1) > > unless getFileName() returns null or lastIndexOf(?.?) returns -1 in > which cases ?? would be returned? > > Thanks, > > Brian From brian.burkhalter at oracle.com Fri Feb 16 20:20:29 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 16 Feb 2018 12:20:29 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <9d32ef6e-4bb0-4480-eeea-143ab5ec39aa@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> <22E7EC04-EF35-4A43-AB6D-F26C95B45617@oracle.com> <539CBD75-4F0A-42D0-8F98-AF781DB245CD@oracle.com> <9d32ef6e-4bb0-4480-eeea-143ab5ec39aa@oracle.com> Message-ID: <82C8E4B7-B0EF-4D41-B371-B9636493F0B7@oracle.com> Hi Daniel, On Feb 16, 2018, at 10:32 AM, Daniel Fuchs wrote: > As David noted, .vimrc is a filename - not an extension, > and the Unix/Linux basename command will treat it as such: > > $ basename ~/.vimrc .vimrc > .vimrc > > I think we should try to honor this expectation. > However: > > $ basename ~/.vimrc.vimrc .vimrc > .vimrc Extrapolating it seems that maybe the extension should be empty if the prefix is one or more dots and there are no more dots in what the basename would return. What then do we do about cases such as .java.policy? It seems the result might better be ?policy? than empty. > So would the code below work? > > String filename = Optional.ofNullable(getFilename()) > .map(Object::toString).orElse(""); > int index = filename.lastIndexOf('.'); > if (index > 0) return filename.substring(index+1); > else return "" It looks like for the aberration ?..foo? the above would return ?foo? which I am not sure we would want. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Fri Feb 16 21:34:48 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 16 Feb 2018 16:34:48 -0500 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <82C8E4B7-B0EF-4D41-B371-B9636493F0B7@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> <22E7EC04-EF35-4A43-AB6D-F26C95B45617@oracle.com> <539CBD75-4F0A-42D0-8F98-AF781DB245CD@oracle.com> <9d32ef6e-4bb0-4480-eeea-143ab5ec39aa@oracle.com> <82C8E4B7-B0EF-4D41-B371-B9636493F0B7@oracle.com> Message-ID: <4007d096-f982-f810-ab78-160f7b138d62@Oracle.com> Hi, On 2/16/2018 3:20 PM, Brian Burkhalter wrote: > Hi Daniel, > > On Feb 16, 2018, at 10:32 AM, Daniel Fuchs > wrote: > >> As David noted, .vimrc is a filename - not an extension, >> and the Unix/Linux basename command will treat it as such: >> >> $ basename ~/.vimrc .vimrc >> .vimrc >> >> I think we should try to honor this expectation. >> However: >> >> $ basename ~/.vimrc.vimrc .vimrc >> .vimrc > > Extrapolating it seems that maybe the extension should be empty if the > prefix is one or more dots and there are no more dots in what the > basename would return. What then do we do about cases such as > .java.policy? It seems the result might better be ?policy? than empty. > >> So would the code below work? >> >> String filename = Optional.ofNullable(getFilename()) >> .map(Object::toString).orElse(""); >> int index = filename.lastIndexOf('.'); >> if (index > 0) return filename.substring(index+1); >> else return "" > > It looks like for the aberration ?..foo? the above would return ?foo? > which I am not sure we would want. The convention for a single leading "." to indicate a hidden file is fine. To keep it simple, the last "." that is not the first character can be the delimiter for the extension. ? "."? ext? "" ? ".." ext "" ? ".a.b" ext "b" ? "......." ext "" ? ".....a" ext "a" ? "....a.b" ext "b" ? "..foo" ext "foo" It might be useful to check how native unix utilities parse these cases. Roger > > Thanks, > > Brian From brian.burkhalter at oracle.com Fri Feb 16 22:00:43 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 16 Feb 2018 14:00:43 -0800 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <4007d096-f982-f810-ab78-160f7b138d62@Oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> <22E7EC04-EF35-4A43-AB6D-F26C95B45617@oracle.com> <539CBD75-4F0A-42D0-8F98-AF781DB245CD@oracle.com> <9d32ef6e-4bb0-4480-eeea-143ab5ec39aa@oracle.com> <82C8E4B7-B0EF-4D41-B371-B9636493F0B7@oracle.com> <4007d096-f982-f810-ab78-160f7b138d62@Oracle.com> Message-ID: <2A02EDCD-179E-471D-8DC6-F83EBEDB470F@oracle.com> Hi Roger, On Feb 16, 2018, at 1:34 PM, Roger Riggs wrote: > The convention for a single leading "." to indicate a hidden file is fine. > To keep it simple, the last "." that is not the first character can be the delimiter for the extension. > > "." ext "" > ".." ext "" > ".a.b" ext "b" > "......." ext "" > ".....a" ext "a" > "....a.b" ext "b" > "..foo" ext "foo" > > It might be useful to check how native unix utilities parse these cases. I did check some of those. In particular $ basename ..foo gives ?..foo?. I?ve kept picking away at this and the revised verbiage du moment is * Returns the extension of this {@code Path} as a {@code String}. The * extension is the suffix of the {@link #getFileName file name} element * after the last dot ({@code '.'}). If however the file name is * {@code null}, does not contain a dot, has a dot as its first character, * the last dot is preceded only by dots, or the last character is a dot, * then this method returns an empty {@code String}. I hope that makes better sense. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Feb 19 08:39:49 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Feb 2018 08:39:49 +0000 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <4007d096-f982-f810-ab78-160f7b138d62@Oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <8cb98ca4-63a2-d686-4f63-1e3628a774e9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> <22E7EC04-EF35-4A43-AB6D-F26C95B45617@oracle.com> <539CBD75-4F0A-42D0-8F98-AF781DB245CD@oracle.com> <9d32ef6e-4bb0-4480-eeea-143ab5ec39aa@oracle.com> <82C8E4B7-B0EF-4D41-B371-B9636493F0B7@oracle.com> <4007d096-f982-f810-ab78-160f7b138d62@Oracle.com> Message-ID: On 16/02/2018 21:34, Roger Riggs wrote: > > To keep it simple, the last "." that is not the first character can be > the delimiter for the extension. > > ? "."? ext? "" > ? ".." ext "" > ? ".a.b" ext "b" > ? "......." ext "" > ? ".....a" ext "a" > ? "....a.b" ext "b" > ? "..foo" ext "foo" > > It might be useful to check how native unix utilities parse these cases Yes, a small survey is needed before proposing how some of the corner cases should work. In the above, you'll find that Python splitpath will split "..foo" into "..foo" and "".? I believe .NET's Path.GetExtension is simply the equivalent of lastIndexOf. The need for a survey is something that came up when this issue was look into a long time ago. One other thing is to consider whether getExtension is the right way to expose this. I've no doubt it will be followed by a request to add a method that returns the file name without the extension so we need to see how that will work. At one point we had a prototype of a split method that returned the name + extension pair, as 2 element String array - I'm not saying that is the best solution of course. -Alan From daniel.fuchs at oracle.com Mon Feb 19 10:23:07 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 19 Feb 2018 10:23:07 +0000 Subject: RFR 8057113: (fs) Path should have a method to test the filename extension In-Reply-To: <2A02EDCD-179E-471D-8DC6-F83EBEDB470F@oracle.com> References: <5F541718-B4C0-49D7-8B7D-9E29914EDBB9@oracle.com> <76719CFE-223A-4710-B3BD-EA47958B4DBA@oracle.com> <4ad053fa-5396-694a-ff5b-45bfc363914c@Oracle.com> <715c3774-acb8-ed74-4c05-cf16dd9fe777@oracle.com> <3CC653B2-FE05-45E3-95F1-131E10456F25@oracle.com> <2FE1FE28-F6D4-4562-98F1-88F54E2C4211@oracle.com> <783b8575-69a6-5cd4-8c11-7c97a349a609@oracle.com> <4A29E747-1269-4233-9094-66D0139E4971@oracle.com> <01D5EDB9-B127-4C3B-9045-DE598932A35A@oracle.com> <22E7EC04-EF35-4A43-AB6D-F26C95B45617@oracle.com> <539CBD75-4F0A-42D0-8F98-AF781DB245CD@oracle.com> <9d32ef6e-4bb0-4480-eeea-143ab5ec39aa@oracle.com> <82C8E4B7-B0EF-4D41-B371-B9636493F0B7@oracle.com> <4007d096-f982-f810-ab78-160f7b138d62@Oracle.com> <2A02EDCD-179E-471D-8DC6-F83EBEDB470F@oracle.com> Message-ID: <3aaaff56-6233-d0b7-c1a5-a7c32cc21f5e@oracle.com> Hi Brian, On 16/02/2018 22:00, Brian Burkhalter wrote: > I did check some of those. In particular > > $ basename ..foo > > gives ?..foo?. > To my great dismay: $ basename ..foo .foo . But I'm not sure we want to go this route. This seems very misleading. I'd prefer it returned "..foo". > I?ve kept picking away at this and the revised verbiage du moment is > > * Returns the extension of this {@code Path} as a {@code String}. The > * extension is the suffix of the {@link #getFileName file name} element > * after the last dot ({@code '.'}). If however the file name is > * {@code null}, does not contain a dot, has a dot as its first character, > * the last dot is preceded only by dots, or the last character is a dot, > * then this method returns an empty {@code String}. > > I hope that makes better sense. > So if I read this correctly getExtension(".x.y") would yield "" by virtue of finding a dot as first character? (which I think is fine) But in this case wouldn't "the last dot is preceded only by dots, or the last character is a dot" be redundant? Because ".....foo" also has a dot as first character, and "" is the suffix after the last dot in "blah." best regards, -- daniel From Alan.Bateman at oracle.com Thu Feb 22 19:08:41 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 Feb 2018 19:08:41 +0000 Subject: 8198562: (ch) Separate blocking and non-blocking code paths (part 1) Message-ID: I mentioned in a thread here earlier this month that I have a number of patches to reduce the complexity and overhead of supporting async close and interrupt in the selectable channel implementations.? All combined, there are a lot of changes but are easy to split into a series of smaller patches that are easier to test and review. The patch here changes the SocketChannel and ServerSocketChannel implementations so that channels configured non-blocking don't set the hook for Thread.interrupt or don't track the threads potentially blocking in I/O operations. The blocking case is improved too by reducing, at least for the SocketChannel implementation, the locking around the blocking calls. All the locking is consistent now, something that will be clearer once the changes to DatagramChannel and the Pipe.* implementations are discussed. Simplification of the read/write/accept/connect/finishConnect methods means that the implCloseSelectableChannel has to handle both the blocking and non-blocking cases but it's not too complicated. The socket adaptors have also changed so that they do timed operations (Socket setSoTimeout and friends) with the channel configured blocking. This it to avoid an explosion of scenarios (and complexity) that arises when trying to be both blocking and non-blocking at the same time. In terms of compatibility, there are two behavioral changes: 1. If a thread's interrupt status is set and it invokes an I/O method on a channel configured non-blocking then the channel will not be closed. The original specification was vague on this point as it focused on threads blocking in I/O operations. Several people have complained bitterly over the years about the existing behavior so they will welcome this change. I haven't found anything yet that depends on long standing behavior but we will need to track this in a CSR anyway. 2. configureBlocking will now block if there are pending I/O operations. The spec has always stated that it may block so it should not be a surprise but there may be some cases where code attempts to change a channel to non-blocking while another thread is doing on a blocking I/O operation on the channel. This method now coordinates with channel closing, something that has never been right in the implementation. The webrev with the patch is here: ?? http://cr.openjdk.java.net/~alanb/8198562/webrev/ -Alan From claes.redestad at oracle.com Fri Feb 23 13:45:27 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 23 Feb 2018 14:45:27 +0100 Subject: 8198562: (ch) Separate blocking and non-blocking code paths (part 1) In-Reply-To: References: Message-ID: <494b55b9-cfc5-663a-6929-f731d710d79d@oracle.com> Hi, while there are certainly things in the neighborhood that is in want of a cleanup, these changes looks good to me. /Claes On 2018-02-22 20:08, Alan Bateman wrote: > > I mentioned in a thread here earlier this month that I have a number > of patches to reduce the complexity and overhead of supporting async > close and interrupt in the selectable channel implementations.? All > combined, there are a lot of changes but are easy to split into a > series of smaller patches that are easier to test and review. > > The patch here changes the SocketChannel and ServerSocketChannel > implementations so that channels configured non-blocking don't set the > hook for Thread.interrupt or don't track the threads potentially > blocking in I/O operations. The blocking case is improved too by > reducing, at least for the SocketChannel implementation, the locking > around the blocking calls. All the locking is consistent now, > something that will be clearer once the changes to DatagramChannel and > the Pipe.* implementations are discussed. > > Simplification of the read/write/accept/connect/finishConnect methods > means that the implCloseSelectableChannel has to handle both the > blocking and non-blocking cases but it's not too complicated. > > The socket adaptors have also changed so that they do timed operations > (Socket setSoTimeout and friends) with the channel configured > blocking. This it to avoid an explosion of scenarios (and complexity) > that arises when trying to be both blocking and non-blocking at the > same time. > > In terms of compatibility, there are two behavioral changes: > > 1. If a thread's interrupt status is set and it invokes an I/O method > on a channel configured non-blocking then the channel will not be > closed. The original specification was vague on this point as it > focused on threads blocking in I/O operations. Several people have > complained bitterly over the years about the existing behavior so they > will welcome this change. I haven't found anything yet that depends on > long standing behavior but we will need to track this in a CSR anyway. > > 2. configureBlocking will now block if there are pending I/O > operations. The spec has always stated that it may block so it should > not be a surprise but there may be some cases where code attempts to > change a channel to non-blocking while another thread is doing on a > blocking I/O operation on the channel. This method now coordinates > with channel closing, something that has never been right in the > implementation. > > The webrev with the patch is here: > ?? http://cr.openjdk.java.net/~alanb/8198562/webrev/ > > -Alan From forax at univ-mlv.fr Fri Feb 23 20:48:07 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 23 Feb 2018 21:48:07 +0100 (CET) Subject: 8198562: (ch) Separate blocking and non-blocking code paths (part 1) In-Reply-To: References: Message-ID: <1497091316.2429027.1519418887216.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "nio-dev" > Envoy?: Jeudi 22 F?vrier 2018 20:08:41 > Objet: 8198562: (ch) Separate blocking and non-blocking code paths (part 1) > I mentioned in a thread here earlier this month that I have a number of > patches to reduce the complexity and overhead of supporting async close > and interrupt in the selectable channel implementations.? All combined, > there are a lot of changes but are easy to split into a series of > smaller patches that are easier to test and review. > > The patch here changes the SocketChannel and ServerSocketChannel > implementations so that channels configured non-blocking don't set the > hook for Thread.interrupt or don't track the threads potentially > blocking in I/O operations. The blocking case is improved too by > reducing, at least for the SocketChannel implementation, the locking > around the blocking calls. All the locking is consistent now, something > that will be clearer once the changes to DatagramChannel and the Pipe.* > implementations are discussed. > > Simplification of the read/write/accept/connect/finishConnect methods > means that the implCloseSelectableChannel has to handle both the > blocking and non-blocking cases but it's not too complicated. > > The socket adaptors have also changed so that they do timed operations > (Socket setSoTimeout and friends) with the channel configured blocking. > This it to avoid an explosion of scenarios (and complexity) that arises > when trying to be both blocking and non-blocking at the same time. > > In terms of compatibility, there are two behavioral changes: > > 1. If a thread's interrupt status is set and it invokes an I/O method on > a channel configured non-blocking then the channel will not be closed. > The original specification was vague on this point as it focused on > threads blocking in I/O operations. Several people have complained > bitterly over the years about the existing behavior so they will welcome > this change. I haven't found anything yet that depends on long standing > behavior but we will need to track this in a CSR anyway. I agree with the people that have complained bitterly, i've seen several ugly half broken workarounds because of this undocumented behavior. I'm happy to see this bug been fixed ! > > 2. configureBlocking will now block if there are pending I/O operations. > The spec has always stated that it may block so it should not be a > surprise but there may be some cases where code attempts to change a > channel to non-blocking while another thread is doing on a blocking I/O > operation on the channel. This method now coordinates with channel > closing, something that has never been right in the implementation. > > The webrev with the patch is here: > ?? http://cr.openjdk.java.net/~alanb/8198562/webrev/ > > -Alan R?mi From brian.burkhalter at oracle.com Sat Feb 24 01:24:22 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 23 Feb 2018 17:24:22 -0800 Subject: 8198562: (ch) Separate blocking and non-blocking code paths (part 1) In-Reply-To: References: Message-ID: <2E4FA83B-4168-457C-B236-4AA94EDFE570@oracle.com> On Feb 22, 2018, at 11:08 AM, Alan Bateman wrote: > The webrev with the patch is here: > http://cr.openjdk.java.net/~alanb/8198562/webrev/ I think that this looks good, much cleaner and with better consistency. I do have a few minor suggestions which if accepted don?t necessitate any further review. 1. ServerSocketAdaptor Use System.nanoTime() instead of System.currentTimeMillis() as in SocketAdaptor? 2. ServerSocketChannelImpl and SocketChannelImpl In various locations replace "if (x == null) throw new NullPointerException();? with "Objects.requireNonNull();". 3. SocketChannelImpl Lines 347-348 change to Objects.checkFromIndexSize(offset, length, dsts.length); Lines 458-459 change to Objects.checkFromIndexSize(offset, length, srcs.length); Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Feb 24 09:01:50 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 24 Feb 2018 09:01:50 +0000 Subject: 8198562: (ch) Separate blocking and non-blocking code paths (part 1) In-Reply-To: <2E4FA83B-4168-457C-B236-4AA94EDFE570@oracle.com> References: <2E4FA83B-4168-457C-B236-4AA94EDFE570@oracle.com> Message-ID: <070f6af5-72a9-eb62-360e-b3b74baf4679@oracle.com> On 24/02/2018 01:24, Brian Burkhalter wrote: > > I think that this looks good, much cleaner and with better > consistency. I do have a few minor suggestions which if accepted don?t > necessitate any further review. > > 1. ServerSocketAdaptor > > Use System.nanoTime() instead of System.currentTimeMillis() as in > SocketAdaptor? Right, and there is also an issue with the existing code in the adaptors where they don't adjust the timeout specified to poll correctly. I think this may date back to when this code was changed to not use a temporary Selector. So yes, definitely needs to be cleaned up but I'd prefer to do it with a separate issue. > > 2. ServerSocketChannelImpl and SocketChannelImpl > > In various locations replace "if (x == null) throw new > NullPointerException();? with "Objects.requireNonNull();". I can include this cleanup. > > 3. SocketChannelImpl > > Lines 347-348 change to Objects.checkFromIndexSize(offset, length, > dsts.length); > > Lines 458-459 change to Objects.checkFromIndexSize(offset, length, > srcs.length); > I can include this cleanup too. Thanks for going through the changes. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Feb 26 22:09:51 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 26 Feb 2018 14:09:51 -0800 Subject: 8198562: (ch) Separate blocking and non-blocking code paths (part 1) In-Reply-To: <070f6af5-72a9-eb62-360e-b3b74baf4679@oracle.com> References: <2E4FA83B-4168-457C-B236-4AA94EDFE570@oracle.com> <070f6af5-72a9-eb62-360e-b3b74baf4679@oracle.com> Message-ID: <6B690D56-335C-4010-8FFC-EC644CD1CF9F@oracle.com> On Feb 24, 2018, at 1:01 AM, Alan Bateman wrote: > On 24/02/2018 01:24, Brian Burkhalter wrote: >> >> I think that this looks good, much cleaner and with better consistency. I do have a few minor suggestions which if accepted don?t necessitate any further review. >> >> 1. ServerSocketAdaptor >> >> Use System.nanoTime() instead of System.currentTimeMillis() as in SocketAdaptor? > Right, and there is also an issue with the existing code in the adaptors where they don't adjust the timeout specified to poll correctly. I think this may date back to when this code was changed to not use a temporary Selector. So yes, definitely needs to be cleaned up but I'd prefer to do it with a separate issue. Sure. >> 2. ServerSocketChannelImpl and SocketChannelImpl >> >> In various locations replace "if (x == null) throw new NullPointerException();? with "Objects.requireNonNull();". > I can include this cleanup. > >> 3. SocketChannelImpl >> >> Lines 347-348 change to Objects.checkFromIndexSize(offset, length, dsts.length); >> >> Lines 458-459 change to Objects.checkFromIndexSize(offset, length, srcs.length); >> > I can include this cleanup too. > > Thanks for going through the changes. You?re welcome. I looked over the refreshed-in-place webrev as well a diff between the previous and current patches and insofar as I can tell it looks good, including the changes used for the state constant definitions in the Channel classes, the updates to the two implCloseSelectableChannel() implementations, and the correction of the timeout calculation in SocketAdaptor. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Feb 27 14:22:01 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Feb 2018 14:22:01 +0000 Subject: 8198754: (ch) Separate blocking and non-blocking code paths (part 2) Message-ID: This is the follow-up to JDK-8198562 to cover the refactoring of the DatagramChannel and Pipe.* implementations. As with JDK-8198562, I've done some cleanup while in the area but I didn't want to do too much as it will take from the core changes. I will create a few issues in the JIRA for follow-up cleaned up to be done in this area, esp. where spec and implementation aren't aligned. The webrev with the changes for part 2 are here: ?? http://cr.openjdk.java.net/~alanb/8198754/webrev/index.html -Alan From brian.burkhalter at oracle.com Wed Feb 28 00:29:29 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 27 Feb 2018 16:29:29 -0800 Subject: 8198754: (ch) Separate blocking and non-blocking code paths (part 2) In-Reply-To: References: Message-ID: <52230E5C-C085-4102-ACC2-98BDA1BD1B03@oracle.com> On Feb 27, 2018, at 6:22 AM, Alan Bateman wrote: > The webrev with the changes for part 2 are here: > http://cr.openjdk.java.net/~alanb/8198754/webrev/index.html I think that these changes look good and are consistent with what was done in part 1 of this sequence. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 28 15:59:42 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 28 Feb 2018 07:59:42 -0800 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 Message-ID: https://bugs.openjdk.java.net/browse/JDK-8198834 This changes the Makefile so that libLauncher.so is built for 64-bit Linux. The change has been tested successfully. The Makefile diff is included below; libLauncher.so will also be part of the change but is not posted here. Thanks, Brian --- a/test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Makefile +++ b/test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Makefile @@ -33,20 +33,23 @@ ifeq ($(uname), Linux) PLATFORM = linux archExpr = case "`$(UNAME) -m`" in \ i[3-6]86) \ $(ECHO) i586 \ ;; \ sparc*) \ $(ECHO) sparc \ ;; \ + x86_64) \ + $(ECHO) amd64 \ + ;; \ *) \ $(UNAME) -m \ ;; \ esac ARCH := $(shell $(archExpr) ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Feb 28 16:34:49 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Feb 2018 16:34:49 +0000 Subject: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64 In-Reply-To: References: Message-ID: On 28/02/2018 15:59, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8198834 > > This changes the Makefile so that libLauncher.so is built for 64-bit > Linux. The change has been tested successfully. The Makefile diff is > included below; libLauncher.so will also be part of the change but is > not posted here. > This look okay but I think we should looking at creating this .so in the build, like we do for libDirectIO.so to create the shared library needed for the direct I/O tests. All the details in test/JtregNativeJdk.gmk. -Alan From Alan.Bateman at oracle.com Wed Feb 28 18:00:42 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Feb 2018 18:00:42 +0000 Subject: FileChannel implements InterruptibleChannel, help or hindrance? Message-ID: As we all know here, FileChannel implements InterruptibleChannel so it's asynchronously closeable and interrupting threads doing I/O operations on a file channel cause it to be closed. I've never been comfortable with the FileChannel being closed by Thread.interrupt and I'm wondering whether it would be worth providing a way for file I/O operations to not being interruptible. A case in point is class loading from the jimage container file, another is class loading from modules exploded on the file system. The former hacks into FileChannel implementation to prevent closing and spurious NoClassDefFoundErrors, the latter is pondering doing the same. We also have Files.readAllBytes and Files.newXXXStream ultimately using a FileChannel where a thread interrupt might cause usage to fail with ClosedByInterruptException. One potential approach is to add an OpenOption (maybe StandardOpenOption.UNINTERRUPTIBLE) that can be specified to FileChannel.open. This seem preferable to providing a way to toggle interruptibility dynamically, esp. in cases where a FileChannel is used by several concurrent threads. There are wider scope ways to do this too but it would mean re-visiting InterruptibleChannel and its base implementation in the spi package with potential knock on impact in other areas of the API. -Alan From brian.burkhalter at oracle.com Wed Feb 28 19:22:35 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 28 Feb 2018 11:22:35 -0800 Subject: FileChannel implements InterruptibleChannel, help or hindrance? In-Reply-To: References: Message-ID: <35972439-CF12-4D7E-BD70-01126181AEE2@oracle.com> On Feb 28, 2018, at 10:00 AM, Alan Bateman wrote: > One potential approach is to add an OpenOption (maybe StandardOpenOption.UNINTERRUPTIBLE) that can be specified to FileChannel.open. This seem preferable to providing a way to toggle interruptibility dynamically, esp. in cases where a FileChannel is used by several concurrent threads. There are wider scope ways to do this too but it would mean re-visiting InterruptibleChannel and its base implementation in the spi package with potential knock on impact in other areas of the API. Providing dynamic toggling of interruptibility would introduce complexity that we probably don?t want. The OpenOption approach is appealing but the InterruptibleChannel specification does not appear to admit much flexibility on this point: [Interrupting a thread] blocked in an I/O operation on an interruptible channel [?] will cause the channel to be closed, the blocked thread to receive a ClosedByInterruptException, and the blocked thread's interrupt status to be set. Other solutions as you observed would however have much broader impact. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Feb 28 19:34:34 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Feb 2018 19:34:34 +0000 Subject: 8198562: (ch) Separate blocking and non-blocking code paths (part 1) In-Reply-To: References: Message-ID: <1c50a4f4-b068-4c2d-f95e-d3d983dba0bb@oracle.com> David Holmes pointed out off-list that the change to Thread.interrupt creates a potential issue when the nterrupt status is cleared just before a blocking I/O operations is start, e.g. try { Thread.sleep(duration); } catch (InterruptedException e) { } channel.read(..) If something interrupts the sleep then it will race with the above as it clears the interrupt status and sets the blocker for the I/O operation. This may mean the blocking I/O operation completes with ClosedByInterruptedException and without the interrupt status being set. To fix this then we need to go back to setting the interrupt status whilst holding the blockerLock. This means it works the same as JDK 1.4-10 except that it handles the case where attempts its own interrupt status whilst in a blocking I/O (a source of potential deadlocks as we know from other discussions here). http://cr.openjdk.java.net/~alanb/8198841/webrev/index.html -Alan From Alan.Bateman at oracle.com Wed Feb 28 19:58:28 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Feb 2018 19:58:28 +0000 Subject: FileChannel implements InterruptibleChannel, help or hindrance? In-Reply-To: <35972439-CF12-4D7E-BD70-01126181AEE2@oracle.com> References: <35972439-CF12-4D7E-BD70-01126181AEE2@oracle.com> Message-ID: On 28/02/2018 19:22, Brian Burkhalter wrote: > > Providing dynamic toggling of interruptibility would introduce > complexity that we probably don?t want. The OpenOption approach is > appealing but the InterruptibleChannel specification does not appear > to admit much flexibility on this point: > > [Interrupting a thread] blocked in an I/O operation on an > interruptible channel [?] will cause the channel to be closed, the > blocked thread to receive a |ClosedByInterruptException| > , > and the blocked thread's interrupt status to be set. > Yes, it would mean clarifications to allow that, maybe even an isInterruptible method on this interface to allow for testing. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Feb 28 21:29:16 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 28 Feb 2018 13:29:16 -0800 Subject: 8198562: (ch) Separate blocking and non-blocking code paths (part 1) In-Reply-To: <1c50a4f4-b068-4c2d-f95e-d3d983dba0bb@oracle.com> References: <1c50a4f4-b068-4c2d-f95e-d3d983dba0bb@oracle.com> Message-ID: On Feb 28, 2018, at 11:34 AM, Alan Bateman wrote: > To fix this then we need to go back to setting the interrupt status whilst holding the blockerLock. This means it works the same as JDK 1.4-10 except that it handles the case where attempts its own interrupt status whilst in a blocking I/O (a source of potential deadlocks as we know from other discussions here). > > http://cr.openjdk.java.net/~alanb/8198841/webrev/index.html A webrev for Thread.java only versus the revision prior to the 8198562 changeset makes the overall change clearer: http://cr.openjdk.java.net/~bpb/thread-8198841/webrev/ To me this change looks good. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: