From Alan.Bateman at oracle.com Tue Nov 5 03:42:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Nov 2013 03:42:04 -0800 (PST) Subject: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" In-Reply-To: <526E7CD7.90906@oracle.com> References: <526E7CD7.90906@oracle.com> Message-ID: <5278D98C.8020807@oracle.com> On 28/10/2013 15:03, Alan Bateman wrote: > : > > Just to double check, are you 100% sure that its the "assert > Thread.holdsLock(this)" that is being being triggered? I ask because > this method method is only every called while holding the lock. I > wonder if instead you are seeing the "assert !result.isDone()" being > triggered. That is what JDK-7052549 is about. Yuri - would you be able to test a patch for this to see if this resolves the issue you are seeing? -Alan. diff --git a/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java b/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java --- a/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java +++ b/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java @@ -228,6 +228,7 @@ @Override public void run() { long overlapped = 0L; + boolean pending = false; try { begin(); @@ -241,6 +242,7 @@ overlapped); if (n == IOStatus.UNAVAILABLE) { // I/O is pending + pending = true; return; } // acquired lock immediately @@ -250,10 +252,10 @@ } catch (Throwable x) { // lock failed or channel closed removeFromFileLockTable(fli); - if (overlapped != 0L) - ioCache.remove(overlapped); result.setFailure(toIOException(x)); } finally { + if (!pending && overlapped != 0L) + ioCache.remove(overlapped); end(); } From ygaevsky at azulsystems.com Tue Nov 5 06:14:19 2013 From: ygaevsky at azulsystems.com (Yuri Gaevsky) Date: Tue, 5 Nov 2013 14:14:19 +0000 Subject: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" In-Reply-To: <5278D98C.8020807@oracle.com> References: <526E7CD7.90906@oracle.com> <5278D98C.8020807@oracle.com> Message-ID: Hi Alan, Sure - I'll start the testing shortly. Thanks, -Yuri -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, November 5, 2013 3:42 PM To: Yuri Gaevsky Cc: nio-dev at openjdk.java.net Subject: Re: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" On 28/10/2013 15:03, Alan Bateman wrote: > : > > Just to double check, are you 100% sure that its the "assert > Thread.holdsLock(this)" that is being being triggered? I ask because > this method method is only every called while holding the lock. I > wonder if instead you are seeing the "assert !result.isDone()" being > triggered. That is what JDK-7052549 is about. Yuri - would you be able to test a patch for this to see if this resolves the issue you are seeing? -Alan. diff --git a/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java b/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java --- a/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java +++ b/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl. +++ java @@ -228,6 +228,7 @@ @Override public void run() { long overlapped = 0L; + boolean pending = false; try { begin(); @@ -241,6 +242,7 @@ overlapped); if (n == IOStatus.UNAVAILABLE) { // I/O is pending + pending = true; return; } // acquired lock immediately @@ -250,10 +252,10 @@ } catch (Throwable x) { // lock failed or channel closed removeFromFileLockTable(fli); - if (overlapped != 0L) - ioCache.remove(overlapped); result.setFailure(toIOException(x)); } finally { + if (!pending && overlapped != 0L) + ioCache.remove(overlapped); end(); } From ygaevsky at azulsystems.com Tue Nov 5 10:29:02 2013 From: ygaevsky at azulsystems.com (Yuri Gaevsky) Date: Tue, 5 Nov 2013 18:29:02 +0000 Subject: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" In-Reply-To: References: <526E7CD7.90906@oracle.com> <5278D98C.8020807@oracle.com> Message-ID: Alan, > Yuri - would you be able to test a patch for this to see if this resolves the issue you are seeing? The failure is not reproducible anymore under fresh JDK-8 build when your patch applied. Thank you, -Yuri -----Original Message----- From: nio-dev-bounces at openjdk.java.net [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Yuri Gaevsky Sent: Tuesday, November 5, 2013 6:14 PM To: Alan Bateman Cc: nio-dev at openjdk.java.net Subject: RE: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" Hi Alan, Sure - I'll start the testing shortly. Thanks, -Yuri -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, November 5, 2013 3:42 PM To: Yuri Gaevsky Cc: nio-dev at openjdk.java.net Subject: Re: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" On 28/10/2013 15:03, Alan Bateman wrote: > : > > Just to double check, are you 100% sure that its the "assert > Thread.holdsLock(this)" that is being being triggered? I ask because > this method method is only every called while holding the lock. I > wonder if instead you are seeing the "assert !result.isDone()" being > triggered. That is what JDK-7052549 is about. Yuri - would you be able to test a patch for this to see if this resolves the issue you are seeing? -Alan. diff --git a/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java b/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java --- a/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java +++ b/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl. +++ java @@ -228,6 +228,7 @@ @Override public void run() { long overlapped = 0L; + boolean pending = false; try { begin(); @@ -241,6 +242,7 @@ overlapped); if (n == IOStatus.UNAVAILABLE) { // I/O is pending + pending = true; return; } // acquired lock immediately @@ -250,10 +252,10 @@ } catch (Throwable x) { // lock failed or channel closed removeFromFileLockTable(fli); - if (overlapped != 0L) - ioCache.remove(overlapped); result.setFailure(toIOException(x)); } finally { + if (!pending && overlapped != 0L) + ioCache.remove(overlapped); end(); } From ajuckel at gmail.com Tue Nov 5 15:59:46 2013 From: ajuckel at gmail.com (Anthony Juckel) Date: Tue, 5 Nov 2013 17:59:46 -0600 Subject: Seeking sponsor for simple typo patch Message-ID: I came across a typo in sun.nio.fs.UnixPath which is fixed by the following changeset. I'm not certain on the proper etiquette for submitting patches like this, but this particular changeset is small enough I figured I would just include it inline. # HG changeset patch # User Anthony W. Juckel # Date 1383574182 21600 # Mon Nov 04 08:09:42 2013 -0600 # Node ID 2705bf37ba1c2b9736d7310be68e662d3f06b4fc # Parent 62982664dc72ec7d0387fcb6027804ac0da1ba54 Fix typo in UnixPath diff -r 62982664dc72 -r 2705bf37ba1c src/solaris/classes/sun/nio/fs/UnixPath.java --- a/src/solaris/classes/sun/nio/fs/UnixPath.java Thu Oct 31 12:36:25 2013 -0700 +++ b/src/solaris/classes/sun/nio/fs/UnixPath.java Mon Nov 04 08:09:42 2013 -0600 @@ -145,7 +145,7 @@ } if (error) { throw new InvalidPathException(input, - "Malformed input or input contains unmappable chacraters"); + "Malformed input or input contains unmappable characters"); } // trim result to actual length if required -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131105/270c8110/attachment.html From dan.xu at oracle.com Tue Nov 5 19:33:38 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 05 Nov 2013 19:33:38 -0800 Subject: Seeking sponsor for simple typo patch In-Reply-To: References: Message-ID: <5279B892.5040905@oracle.com> Hi Anthony, I could not see changes in your patch. Can you explain where the typo is? Thanks! -Dan On 11/05/2013 03:59 PM, Anthony Juckel wrote: > I came across a typo in sun.nio.fs.UnixPath which is fixed by the > following changeset. I'm not certain on the proper etiquette for > submitting patches like this, but this particular changeset is small > enough I figured I would just include it inline. > > # HG changeset patch > # User Anthony W. Juckel > > # Date 1383574182 21600 > # Mon Nov 04 08:09:42 2013 -0600 > # Node ID 2705bf37ba1c2b9736d7310be68e662d3f06b4fc > # Parent 62982664dc72ec7d0387fcb6027804ac0da1ba54 > Fix typo in UnixPath > > diff -r 62982664dc72 -r 2705bf37ba1c > src/solaris/classes/sun/nio/fs/UnixPath.java > --- a/src/solaris/classes/sun/nio/fs/UnixPath.java Thu Oct 31 > 12:36:25 2013 -0700 > +++ b/src/solaris/classes/sun/nio/fs/UnixPath.java Mon Nov 04 > 08:09:42 2013 -0600 > @@ -145,7 +145,7 @@ > } > if (error) { > throw new InvalidPathException(input, > - "Malformed input or input contains unmappable > chacraters"); > + "Malformed input or input contains unmappable > characters"); > } > > // trim result to actual length if required > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131105/1a65b21b/attachment.html From mike.duigou at oracle.com Tue Nov 5 19:53:07 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 5 Nov 2013 19:53:07 -0800 Subject: Seeking sponsor for simple typo patch In-Reply-To: <5279B892.5040905@oracle.com> References: <5279B892.5040905@oracle.com> Message-ID: <7E4A665B-3766-476F-9A9C-83219DD2004B@oracle.com> chacraters -> characters It looks fine to me. Mike On Nov 5 2013, at 19:33 , Dan Xu wrote: > Hi Anthony, > > I could not see changes in your patch. Can you explain where the typo is? Thanks! > > -Dan > > On 11/05/2013 03:59 PM, Anthony Juckel wrote: >> I came across a typo in sun.nio.fs.UnixPath which is fixed by the following changeset. I'm not certain on the proper etiquette for submitting patches like this, but this particular changeset is small enough I figured I would just include it inline. >> >> # HG changeset patch >> # User Anthony W. Juckel >> # Date 1383574182 21600 >> # Mon Nov 04 08:09:42 2013 -0600 >> # Node ID 2705bf37ba1c2b9736d7310be68e662d3f06b4fc >> # Parent 62982664dc72ec7d0387fcb6027804ac0da1ba54 >> Fix typo in UnixPath >> >> diff -r 62982664dc72 -r 2705bf37ba1c src/solaris/classes/sun/nio/fs/UnixPath.java >> --- a/src/solaris/classes/sun/nio/fs/UnixPath.java Thu Oct 31 12:36:25 2013 -0700 >> +++ b/src/solaris/classes/sun/nio/fs/UnixPath.java Mon Nov 04 08:09:42 2013 -0600 >> @@ -145,7 +145,7 @@ >> } >> if (error) { >> throw new InvalidPathException(input, >> - "Malformed input or input contains unmappable chacraters"); >> + "Malformed input or input contains unmappable characters"); >> } >> >> // trim result to actual length if required >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131105/2e1ced61/attachment.html From henry.jen at oracle.com Tue Nov 5 20:02:16 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 5 Nov 2013 20:02:16 -0800 Subject: Seeking sponsor for simple typo patch In-Reply-To: <5279B892.5040905@oracle.com> References: <5279B892.5040905@oracle.com> Message-ID: characters, the last word in that sentence. Cheers, Henry On Nov 5, 2013, at 7:33 PM, Dan Xu wrote: > Hi Anthony, > > I could not see changes in your patch. Can you explain where the typo is? Thanks! > > -Dan > > On 11/05/2013 03:59 PM, Anthony Juckel wrote: >> I came across a typo in sun.nio.fs.UnixPath which is fixed by the following changeset. I'm not certain on the proper etiquette for submitting patches like this, but this particular changeset is small enough I figured I would just include it inline. >> >> # HG changeset patch >> # User Anthony W. Juckel >> # Date 1383574182 21600 >> # Mon Nov 04 08:09:42 2013 -0600 >> # Node ID 2705bf37ba1c2b9736d7310be68e662d3f06b4fc >> # Parent 62982664dc72ec7d0387fcb6027804ac0da1ba54 >> Fix typo in UnixPath >> >> diff -r 62982664dc72 -r 2705bf37ba1c src/solaris/classes/sun/nio/fs/UnixPath.java >> --- a/src/solaris/classes/sun/nio/fs/UnixPath.java Thu Oct 31 12:36:25 2013 -0700 >> +++ b/src/solaris/classes/sun/nio/fs/UnixPath.java Mon Nov 04 08:09:42 2013 -0600 >> @@ -145,7 +145,7 @@ >> } >> if (error) { >> throw new InvalidPathException(input, >> - "Malformed input or input contains unmappable chacraters"); >> + "Malformed input or input contains unmappable characters"); >> } >> >> // trim result to actual length if required >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131105/843fb274/attachment.html From dan.xu at oracle.com Tue Nov 5 20:03:19 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 05 Nov 2013 20:03:19 -0800 Subject: Seeking sponsor for simple typo patch In-Reply-To: <7E4A665B-3766-476F-9A9C-83219DD2004B@oracle.com> References: <5279B892.5040905@oracle.com> <7E4A665B-3766-476F-9A9C-83219DD2004B@oracle.com> Message-ID: <5279BF87.9020802@oracle.com> Ah, I see. Thanks, Mike. Anthony, the change looks good. I can sponsor it. -Dan On 11/05/2013 07:53 PM, Mike Duigou wrote: > chacraters -> characters > > It looks fine to me. > > Mike > > On Nov 5 2013, at 19:33 , Dan Xu > wrote: > >> Hi Anthony, >> >> I could not see changes in your patch. Can you explain where the typo >> is? Thanks! >> >> -Dan >> >> On 11/05/2013 03:59 PM, Anthony Juckel wrote: >>> I came across a typo in sun.nio.fs.UnixPath which is fixed by the >>> following changeset. I'm not certain on the proper etiquette for >>> submitting patches like this, but this particular changeset is small >>> enough I figured I would just include it inline. >>> >>> # HG changeset patch >>> # User Anthony W. Juckel > >>> # Date 1383574182 21600 >>> # Mon Nov 04 08:09:42 2013 -0600 >>> # Node ID 2705bf37ba1c2b9736d7310be68e662d3f06b4fc >>> # Parent 62982664dc72ec7d0387fcb6027804ac0da1ba54 >>> Fix typo in UnixPath >>> >>> diff -r 62982664dc72 -r 2705bf37ba1c >>> src/solaris/classes/sun/nio/fs/UnixPath.java >>> --- a/src/solaris/classes/sun/nio/fs/UnixPath.java Thu Oct 31 >>> 12:36:25 2013 -0700 >>> +++ b/src/solaris/classes/sun/nio/fs/UnixPath.java Mon Nov 04 >>> 08:09:42 2013 -0600 >>> @@ -145,7 +145,7 @@ >>> } >>> if (error) { >>> throw new InvalidPathException(input, >>> - "Malformed input or input contains unmappable >>> chacraters"); >>> + "Malformed input or input contains unmappable >>> characters"); >>> } >>> >>> // trim result to actual length if required >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131105/a41bcea8/attachment-0001.html From weijun.wang at oracle.com Tue Nov 5 20:09:36 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 06 Nov 2013 12:09:36 +0800 Subject: Seeking sponsor for simple typo patch In-Reply-To: <5279B892.5040905@oracle.com> References: <5279B892.5040905@oracle.com> Message-ID: <5279C100.1@oracle.com> - chacraters + characters On 11/6/13, 11:33, Dan Xu wrote: > Hi Anthony, > > I could not see changes in your patch. Can you explain where the typo > is? Thanks! > > -Dan > > On 11/05/2013 03:59 PM, Anthony Juckel wrote: >> I came across a typo in sun.nio.fs.UnixPath which is fixed by the >> following changeset. I'm not certain on the proper etiquette for >> submitting patches like this, but this particular changeset is small >> enough I figured I would just include it inline. >> >> # HG changeset patch >> # User Anthony W. Juckel > >> # Date 1383574182 21600 >> # Mon Nov 04 08:09:42 2013 -0600 >> # Node ID 2705bf37ba1c2b9736d7310be68e662d3f06b4fc >> # Parent 62982664dc72ec7d0387fcb6027804ac0da1ba54 >> Fix typo in UnixPath >> >> diff -r 62982664dc72 -r 2705bf37ba1c >> src/solaris/classes/sun/nio/fs/UnixPath.java >> --- a/src/solaris/classes/sun/nio/fs/UnixPath.java Thu Oct 31 >> 12:36:25 2013 -0700 >> +++ b/src/solaris/classes/sun/nio/fs/UnixPath.java Mon Nov 04 >> 08:09:42 2013 -0600 >> @@ -145,7 +145,7 @@ >> } >> if (error) { >> throw new InvalidPathException(input, >> - "Malformed input or input contains unmappable >> chacraters"); >> + "Malformed input or input contains unmappable >> characters"); >> } >> >> // trim result to actual length if required >> > From Alan.Bateman at oracle.com Wed Nov 6 00:08:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Nov 2013 08:08:15 +0000 Subject: Seeking sponsor for simple typo patch In-Reply-To: <5279BF87.9020802@oracle.com> References: <5279B892.5040905@oracle.com> <7E4A665B-3766-476F-9A9C-83219DD2004B@oracle.com> <5279BF87.9020802@oracle.com> Message-ID: <5279F8EF.4010301@oracle.com> On 06/11/2013 04:03, Dan Xu wrote: > Ah, I see. Thanks, Mike. > > Anthony, the change looks good. I can sponsor it. > > -Dan > Thanks Dan. Someone else noticed it too so there is a bug already: https://bugs.openjdk.java.net/browse/JDK-8025698 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131106/cd8da506/attachment.html From ygaevsky at azulsystems.com Thu Nov 7 05:46:29 2013 From: ygaevsky at azulsystems.com (Yuri Gaevsky) Date: Thu, 7 Nov 2013 13:46:29 +0000 Subject: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" In-Reply-To: References: <526E7CD7.90906@oracle.com> <5278D98C.8020807@oracle.com> Message-ID: FYI: the similar patch fixes the failure in jdk7u too. Thanks, -Yuri -----Original Message----- From: nio-dev-bounces at openjdk.java.net [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Yuri Gaevsky Sent: Tuesday, November 5, 2013 10:29 PM To: Alan Bateman Cc: nio-dev at openjdk.java.net Subject: RE: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" Alan, > Yuri - would you be able to test a patch for this to see if this resolves the issue you are seeing? The failure is not reproducible anymore under fresh JDK-8 build when your patch applied. Thank you, -Yuri -----Original Message----- From: nio-dev-bounces at openjdk.java.net [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Yuri Gaevsky Sent: Tuesday, November 5, 2013 6:14 PM To: Alan Bateman Cc: nio-dev at openjdk.java.net Subject: RE: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" Hi Alan, Sure - I'll start the testing shortly. Thanks, -Yuri -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, November 5, 2013 3:42 PM To: Yuri Gaevsky Cc: nio-dev at openjdk.java.net Subject: Re: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" On 28/10/2013 15:03, Alan Bateman wrote: > : > > Just to double check, are you 100% sure that its the "assert > Thread.holdsLock(this)" that is being being triggered? I ask because > this method method is only every called while holding the lock. I > wonder if instead you are seeing the "assert !result.isDone()" being > triggered. That is what JDK-7052549 is about. Yuri - would you be able to test a patch for this to see if this resolves the issue you are seeing? -Alan. diff --git a/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java b/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java --- a/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java +++ b/src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl. +++ java @@ -228,6 +228,7 @@ @Override public void run() { long overlapped = 0L; + boolean pending = false; try { begin(); @@ -241,6 +242,7 @@ overlapped); if (n == IOStatus.UNAVAILABLE) { // I/O is pending + pending = true; return; } // acquired lock immediately @@ -250,10 +252,10 @@ } catch (Throwable x) { // lock failed or channel closed removeFromFileLockTable(fli); - if (overlapped != 0L) - ioCache.remove(overlapped); result.setFailure(toIOException(x)); } finally { + if (!pending && overlapped != 0L) + ioCache.remove(overlapped); end(); } From yiming.wang at oracle.com Thu Nov 7 07:22:11 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 07 Nov 2013 23:22:11 +0800 Subject: RFR for JDK-8022879 TEST_BUG: sun/nio/cs/MalformedSurrogates.java fails intermittently Message-ID: <527BB023.4080406@oracle.com> Hi Everyone I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022879. The test sun/nio/cs/MalformedSurrogates.java doesn't run if the system default encoding is UTF-8. But unfortunately, UTF-8 is the default charset of most test machines, it means the test get few chances to be executed. Another defect is the test would failed if the default charset is UTF-16 or UTF-32 as the test doesn't take the 2 charsets into consideration. The idea of fix is no matter what system charset it is, the test should always be executed. Here thanks Martin's suggestion that instead of checking byte size, we can use CharsetEncoder.canEncode() and CharsetEncoder.onMalformedInput(CodingErrorAction.REPLACE) to check and replace malformed chars. So the test can be re-designed as below: 1. To use CharsetEncoder.canEncode() to check whether the string includes malformed characters. 2. If a string includes malformed characters e.g. "abc\uD800\uDB00efgh", then set CharsetEncoder.onMalformedInput(CodingErrorAction.REPLACE) to replace the malformed characters to the replacement "?" when calling CharsetEncoder.encode() method. 3. Verified by decoding the encoded ByteBuffer to CharBuffer, check whether it includes replacement "?" and compare it with old string, if not equal, then test passed. 4. If a sting doesn't include malformed characters e.g. "abc\uD800\uDC00efgh", the CharsetEncoder.encode() converts it to ByteBuffer which doesn't include replacement "?" 5. Verified by decoding the encoded ByteBuffer to CharBuffer, confirm that it doesn't include replacment "?" and compare it with old string, if equal, then test passed. Please let me know if you have any comments or suggestions. Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131107/2ed7b472/attachment.html From martinrb at google.com Thu Nov 7 08:23:20 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 7 Nov 2013 08:23:20 -0800 Subject: RFR for JDK-8022879 TEST_BUG: sun/nio/cs/MalformedSurrogates.java fails intermittently In-Reply-To: <527BB023.4080406@oracle.com> References: <527BB023.4080406@oracle.com> Message-ID: I still like my old idea of iterating over all charsets and checking their reasonableness properties. Probably all charsets bundled with the jdk should reject unpaired surrogates when encoding. Check it! Failure to do so might be considered a security bug. I would use CodingErrorAction.REPORT instead of REPLACE and examine that the resulting exception occurs and has reasonable detail. For properly paired surrogates, check that the charset can encode the resulting codepoint using canEncode, and if so, check that encoding succeeds. On Thu, Nov 7, 2013 at 7:22 AM, Eric Wang wrote: > Hi Everyone > > I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022879. > The test sun/nio/cs/MalformedSurrogates.javadoesn't run if the system default encoding is UTF-8. But unfortunately, > UTF-8 is the default charset of most test machines, it means the test get > few chances to be executed. > Another defect is the test would failed if the default charset is UTF-16 > or UTF-32 as the test doesn't take the 2 charsets into consideration. > > The idea of fix is no matter what system charset it is, the test should > always be executed. Here thanks Martin's suggestion that instead of > checking byte size, we can use CharsetEncoder.canEncode() and CharsetEncoder.onMalformedInput(CodingErrorAction.REPLACE) > to check and replace malformed chars. > > So the test can be re-designed as below: > > 1. To use CharsetEncoder.canEncode() to check whether the string includes > malformed characters. > 2. If a string includes malformed characters e.g. "abc\uD800\uDB00efgh", > then set CharsetEncoder.onMalformedInput(CodingErrorAction.REPLACE) to > replace the malformed characters to the replacement "?" when calling > CharsetEncoder.encode() method. > 3. Verified by decoding the encoded ByteBuffer to CharBuffer, check > whether it includes replacement "?" and compare it with old string, if not > equal, then test passed. > 4. If a sting doesn't include malformed characters e.g. > "abc\uD800\uDC00efgh", the CharsetEncoder.encode() converts it to > ByteBuffer which doesn't include replacement "?" > 5. Verified by decoding the encoded ByteBuffer to CharBuffer, confirm that > it doesn't include replacment "?" and compare it with old string, if equal, > then test passed. > > Please let me know if you have any comments or suggestions. > > Thanks, > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131107/f75f5a3c/attachment.html From sergey.lugovoy at oracle.com Sun Nov 10 22:02:47 2013 From: sergey.lugovoy at oracle.com (Sergey Lugovoy) Date: Mon, 11 Nov 2013 10:02:47 +0400 Subject: [nio dev] [8] Review request for 8028049 : Tidy warnings cleanup for packages java.nio/java.io Message-ID: <1929736.jKUYgnqaqV@workland> Hi all, please review the fix http://cr.openjdk.java.net/~yan/8028049/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8028049 This patch cleanup tidy warnings for generated html documentation, and do not affect the appearance of the documentation. Best regards, Serge V. Lugovoy From Alan.Bateman at oracle.com Mon Nov 11 03:27:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Nov 2013 11:27:39 +0000 Subject: [nio dev] [8] Review request for 8028049 : Tidy warnings cleanup for packages java.nio/java.io In-Reply-To: <1929736.jKUYgnqaqV@workland> References: <1929736.jKUYgnqaqV@workland> Message-ID: <5280BF2B.50308@oracle.com> On 11/11/2013 06:02, Sergey Lugovoy wrote: > Hi all, > please review the fix > http://cr.openjdk.java.net/~yan/8028049/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8028049 > > This patch cleanup tidy warnings for generated html documentation, and do not > affect the appearance of the documentation. > Thanks for working on this. I don't understand the need for the breaks (the replacements of

with
), are you sure these are needed? In the package.html you've changed it from .. to .. . I think it would be better to just remove the code tags as we are already in a link (this is the reason why it was originally done as .. ). Otherwise I think it looks okay. I assume you'll run doclint, in addition to tidy, to make sure that we are clean before pushing this. -Alan. From sergey.lugovoy at oracle.com Mon Nov 11 23:06:07 2013 From: sergey.lugovoy at oracle.com (Sergey Lugovoy) Date: Tue, 12 Nov 2013 11:06:07 +0400 Subject: [nio dev] [8] Review request for 8028049 : Tidy warnings cleanup for packages java.nio/java.io In-Reply-To: <52811E17.8000204@oracle.com> References: <1929736.jKUYgnqaqV@workland> <5280BF2B.50308@oracle.com> <52811E17.8000204@oracle.com> Message-ID: <11954436.boXYgDLUUM@workland> Hi all, please look at the second patch http://cr.openjdk.java.net/~yan/8028049/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8028049 As Joe suggested, I removed the tag

at the end of comments; removed tag from link; reran doclint - no new warnings. On Monday, November 11, 2013 10:12:39 AM Joe Darcy wrote: > On 11/11/2013 3:27 AM, Alan Bateman wrote: > > On 11/11/2013 06:02, Sergey Lugovoy wrote: > >> Hi all, > >> please review the fix > >> http://cr.openjdk.java.net/~yan/8028049/webrev.00/ > >> for > >> https://bugs.openjdk.java.net/browse/JDK-8028049 > >> > >> This patch cleanup tidy warnings for generated html documentation, > >> and do not > >> affect the appearance of the documentation. > > > > Thanks for working on this. > > > > I don't understand the need for the breaks (the replacements of

> > with
), are you sure these are needed? > > Yes, I would assume in a situation like > > * end of stream rather than throwing an exception. > - *

> + *
> * > * @author Frank Yellin > > it would suffice just to remove the

tag, resulting in > > * end of stream rather than throwing an exception. > - *

> * > * @author Frank Yellin > > > In the package.html you've changed it from .. to > > .. . I think it would be better to just remove the code tags as > > we are already in a link (this is the reason why it was originally > > done as .. ). > > For this construct, > >

  • A byte buffer can be created by {@link > - java.nio.channels.FileChannel#map mapping} a > region of a > + java.nio.channels.FileChannel#map mapping} a > region of a > > you should replace with the linkplain tag. > > Cheers, > > -Joe > > > Otherwise I think it looks okay. I assume you'll run doclint, in > > addition to tidy, to make sure that we are clean before pushing this. > > > > -Alan. From Alan.Bateman at oracle.com Tue Nov 12 04:19:29 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Nov 2013 12:19:29 +0000 Subject: [nio dev] [8] Review request for 8028049 : Tidy warnings cleanup for packages java.nio/java.io In-Reply-To: <11954436.boXYgDLUUM@workland> References: <1929736.jKUYgnqaqV@workland> <5280BF2B.50308@oracle.com> <52811E17.8000204@oracle.com> <11954436.boXYgDLUUM@workland> Message-ID: <52821CD1.3000605@oracle.com> On 12/11/2013 07:06, Sergey Lugovoy wrote: > Hi all, > please look at the second patch > http://cr.openjdk.java.net/~yan/8028049/webrev.01/ > for https://bugs.openjdk.java.net/browse/JDK-8028049 > > As Joe suggested, I removed the tag

    at the end of comments; removed tag > from link; reran doclint - no new warnings. This looks okay to me (although I think Joe was suggest linkplain). -Alan From Alan.Bateman at oracle.com Tue Nov 12 07:46:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Nov 2013 15:46:17 +0000 Subject: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" In-Reply-To: References: <526E7CD7.90906@oracle.com> <5278D98C.8020807@oracle.com> Message-ID: <52824D49.4030806@oracle.com> On 07/11/2013 13:46, Yuri Gaevsky wrote: > FYI: the similar patch fixes the failure in jdk7u too. > > Thanks, > -Yuri > Thanks for checking jdk7u too. Chris - do you mind reviewing the change. The webrev is here: http://cr.openjdk.java.net/~alanb/8028208/webrev/ Note that I've used a new JIRA issue for this because JDK-7052549 will require other changes that a bit beyond the scope of the async file locking issue. -Alan. From chris.hegarty at oracle.com Tue Nov 12 08:23:51 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 12 Nov 2013 16:23:51 +0000 Subject: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" In-Reply-To: <52824D49.4030806@oracle.com> References: <526E7CD7.90906@oracle.com> <5278D98C.8020807@oracle.com> <52824D49.4030806@oracle.com> Message-ID: <52825617.1000402@oracle.com> From what I can tell, the changes look fine to me. I assume you simply do not want to remove the entry from the cache when the pending operation may complete at some point in the future. -Chris. On 12/11/13 15:46, Alan Bateman wrote: > On 07/11/2013 13:46, Yuri Gaevsky wrote: >> FYI: the similar patch fixes the failure in jdk7u too. >> >> Thanks, >> -Yuri >> > Thanks for checking jdk7u too. > > Chris - do you mind reviewing the change. The webrev is here: > > http://cr.openjdk.java.net/~alanb/8028208/webrev/ > > Note that I've used a new JIRA issue for this because JDK-7052549 will > require other changes that a bit beyond the scope of the async file > locking issue. > > -Alan. From Alan.Bateman at oracle.com Tue Nov 12 08:30:27 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Nov 2013 16:30:27 +0000 Subject: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" In-Reply-To: <52825617.1000402@oracle.com> References: <526E7CD7.90906@oracle.com> <5278D98C.8020807@oracle.com> <52824D49.4030806@oracle.com> <52825617.1000402@oracle.com> Message-ID: <528257A3.2070307@oracle.com> On 12/11/2013 16:23, Chris Hegarty wrote: > From what I can tell, the changes look fine to me. > > I assume you simply do not want to remove the entry from the cache > when the pending operation may complete at some point in the future. The issue is when a file lock is acquired immediately it is leaving an OVERLAPPED structure in the pending I/O cache. That OVERLAPPED structure is recycled via the I/O completion notification but it's possible that a close gets in around this time and attempts to clean up. If it grabs it before the thread handling the I/O completions then it will see it as completed and this is what triggers the assert. I'll push this for now so that Yuri has a fix to work with but I would like to re-visit this area again via the master bug. -Alan From chris.hegarty at oracle.com Tue Nov 12 08:35:44 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 12 Nov 2013 16:35:44 +0000 Subject: [PATCH] 7052549 "(aio) AssertionError in sun.nio.ch.PendingIoCache.clearPendingIoMap (win)" In-Reply-To: <528257A3.2070307@oracle.com> References: <526E7CD7.90906@oracle.com> <5278D98C.8020807@oracle.com> <52824D49.4030806@oracle.com> <52825617.1000402@oracle.com> <528257A3.2070307@oracle.com> Message-ID: <528258E0.1010008@oracle.com> On 12/11/13 16:30, Alan Bateman wrote: > On 12/11/2013 16:23, Chris Hegarty wrote: >> From what I can tell, the changes look fine to me. >> >> I assume you simply do not want to remove the entry from the cache >> when the pending operation may complete at some point in the future. > The issue is when a file lock is acquired immediately it is leaving an > OVERLAPPED structure in the pending I/O cache. That OVERLAPPED structure > is recycled via the I/O completion notification but it's possible that a > close gets in around this time and attempts to clean up. If it grabs it > before the thread handling the I/O completions then it will see it as > completed and this is what triggers the assert. OK, thanks. > I'll push this for now > so that Yuri has a fix to work with but I would like to re-visit this > area again via the master bug. Makes sense. -Chris. > > -Alan From martinrb at google.com Tue Nov 12 13:27:29 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 12 Nov 2013 13:27:29 -0800 Subject: security manager not consulted when reading symbolic link. Message-ID: When UnixFileSystemProvider creates a symbolic link, it does: // permission check SecurityManager sm = System.getSecurityManager(); if (sm != null) { sm.checkPermission(new LinkPermission("symbolic")); link.checkWrite(); } but when it reads a symbolic link, it does: // permission check SecurityManager sm = System.getSecurityManager(); if (sm != null) { FilePermission perm = new FilePermission(link.getPathForPermissionCheck(), SecurityConstants.FILE_READLINK_ACTION); AccessController.checkPermission(perm); } which bypasses the security manager. Which seems like a bug. Why not have parallel code, most obviously sm.checkPermission(perm); link.checkRead(); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131112/6c993301/attachment.html From Alan.Bateman at oracle.com Tue Nov 12 13:50:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Nov 2013 21:50:07 +0000 Subject: security manager not consulted when reading symbolic link. In-Reply-To: References: Message-ID: <5282A28E.6090309@oracle.com> On 12/11/2013 21:27, Martin Buchholz wrote: > : > > which bypasses the security manager. Which seems like a bug. > Yes, this is a bug, it should use the security manager's checkPermission rather than calling the AccessController directly. -Alan From Alan.Bateman at oracle.com Wed Nov 13 04:38:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Nov 2013 12:38:23 +0000 Subject: 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission Message-ID: <528372BF.60305@oracle.com> This is a follow-up to Martin's mail of yesterday where he pointed out that the implementations of readSymbolicLink are doing the permission check by calling AccessController.checkPermission directly. The bug means the security manager doesn't get a chance to grant the permission. Here's the webrev to fix this (and also expand the CheckPermissions test to cover this case, the lack of the a test case is how this one slipped through). http://cr.openjdk.java.net/~alanb/8028270/webrev/ -Alan. From mandy.chung at oracle.com Wed Nov 13 08:00:22 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Nov 2013 08:00:22 -0800 Subject: 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission In-Reply-To: <528372BF.60305@oracle.com> References: <528372BF.60305@oracle.com> Message-ID: <5283A216.707@oracle.com> On 11/13/2013 4:38 AM, Alan Bateman wrote: > > This is a follow-up to Martin's mail of yesterday where he pointed out > that the implementations of readSymbolicLink are doing the permission > check by calling AccessController.checkPermission directly. The bug > means the security manager doesn't get a chance to grant the permission. > > Here's the webrev to fix this (and also expand the CheckPermissions > test to cover this case, the lack of the a test case is how this one > slipped through). > > http://cr.openjdk.java.net/~alanb/8028270/webrev/ > Looks fine with me. Mandy From martinrb at google.com Wed Nov 13 08:01:31 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Nov 2013 08:01:31 -0800 Subject: 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission In-Reply-To: <528372BF.60305@oracle.com> References: <528372BF.60305@oracle.com> Message-ID: If you compare with the analogous code in createSymbolicLink, one would expect in addition a call to link.checkRead, since this is "reading the contents of a file". Users expect their security manager's checkRead method to be called here. On Wed, Nov 13, 2013 at 4:38 AM, Alan Bateman wrote: > > This is a follow-up to Martin's mail of yesterday where he pointed out > that the implementations of readSymbolicLink are doing the permission check > by calling AccessController.checkPermission directly. The bug means the > security manager doesn't get a chance to grant the permission. > > Here's the webrev to fix this (and also expand the CheckPermissions test > to cover this case, the lack of the a test case is how this one slipped > through). > > http://cr.openjdk.java.net/~alanb/8028270/webrev/ > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131113/04ef63ee/attachment.html From Alan.Bateman at oracle.com Wed Nov 13 08:16:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Nov 2013 16:16:18 +0000 Subject: 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission In-Reply-To: References: <528372BF.60305@oracle.com> Message-ID: <5283A5D2.1020705@oracle.com> On 13/11/2013 16:01, Martin Buchholz wrote: > If you compare with the analogous code in createSymbolicLink, one > would expect in addition a call to link.checkRead, since this is > "reading the contents of a file". Users expect their security > manager's checkRead method to be called here. It is specified to check the readlink action rather than read because read also grants permission to the final target of the link (there is awkwardness here due to problems with the way that FilePermission was original designed, it just doesn't mesh well with symbolic links). -Alan. From martinrb at google.com Wed Nov 13 08:20:40 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Nov 2013 08:20:40 -0800 Subject: 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission In-Reply-To: <5283A5D2.1020705@oracle.com> References: <528372BF.60305@oracle.com> <5283A5D2.1020705@oracle.com> Message-ID: OK, looks good to me. On Wed, Nov 13, 2013 at 8:16 AM, Alan Bateman wrote: > On 13/11/2013 16:01, Martin Buchholz wrote: > >> If you compare with the analogous code in createSymbolicLink, one would >> expect in addition a call to link.checkRead, since this is "reading the >> contents of a file". Users expect their security manager's checkRead >> method to be called here. >> > It is specified to check the readlink action rather than read because read > also grants permission to the final target of the link (there is > awkwardness here due to problems with the way that FilePermission was > original designed, it just doesn't mesh well with symbolic links). > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131113/b3b12a50/attachment.html From chris.hegarty at oracle.com Wed Nov 13 08:32:18 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Nov 2013 16:32:18 +0000 Subject: 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission In-Reply-To: <5283A216.707@oracle.com> References: <528372BF.60305@oracle.com> <5283A216.707@oracle.com> Message-ID: <5283A992.4000307@oracle.com> Looks good to me. -Chris. On 11/13/2013 04:00 PM, Mandy Chung wrote: > On 11/13/2013 4:38 AM, Alan Bateman wrote: >> >> This is a follow-up to Martin's mail of yesterday where he pointed out >> that the implementations of readSymbolicLink are doing the permission >> check by calling AccessController.checkPermission directly. The bug >> means the security manager doesn't get a chance to grant the permission. >> >> Here's the webrev to fix this (and also expand the CheckPermissions >> test to cover this case, the lack of the a test case is how this one >> slipped through). >> >> http://cr.openjdk.java.net/~alanb/8028270/webrev/ >> > > Looks fine with me. > Mandy > From shawjef3 at gmail.com Fri Nov 15 11:08:31 2013 From: shawjef3 at gmail.com (Jeffrey Shaw) Date: Fri, 15 Nov 2013 14:08:31 -0500 Subject: SimpleAsynchronousFileChannelImpl implRead() and implWrite() fail for named pipes Message-ID: Hello, I want to perform asynchronous reads and writes on named pipes in a non-Windows environment. Named pipes are not seekable. sun.nio.ch.IOUtil.read() and write() appear to have special behavior defined for when position = -1 that does not involve seeking. Unfortunately, sun.nio.ch.SimpleAsynchronousFileChannelImpl readImpl() and writeImpl() both throw exceptions if position < -1, even though position = -1 is both allowed by the IOUtil functions and required for use with named pipes. Is this a bug I or someone else can file? I haven't checked WindowsAsynchronousFileChannelImpl for the same problem. Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131115/02349c06/attachment.html From Alan.Bateman at oracle.com Fri Nov 15 13:15:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Nov 2013 21:15:12 +0000 Subject: SimpleAsynchronousFileChannelImpl implRead() and implWrite() fail for named pipes In-Reply-To: References: Message-ID: <52868EE0.7050406@oracle.com> On 15/11/2013 19:08, Jeffrey Shaw wrote: > Hello, > I want to perform asynchronous reads and writes on named pipes in a > non-Windows environment. Named pipes are not seekable. > sun.nio.ch.IOUtil.read() and write() appear to have special behavior > defined for when position = -1 that does not involve seeking. > Unfortunately, sun.nio.ch > .SimpleAsynchronousFileChannelImpl readImpl() and > writeImpl() both throw exceptions if position < -1, even though > position = -1 is both allowed by the IOUtil functions and required for > use with named pipes. > > Is this a bug I or someone else can file? > > I haven't checked WindowsAsynchronousFileChannelImpl for the same problem. > > Thanks, > Jeff There isn't really any support for named pipe. It has come up a few times and wouldn't be too hard to have a SocketChannel or AsynchronousSocketChannel to a pipe. AsynchronousFileChannel is about accessing a file by position so I don't think this would be a good fit for pipes. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131115/cd57e51f/attachment.html From yuri.nesterenko at oracle.com Mon Nov 18 01:48:08 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Mon, 18 Nov 2013 13:48:08 +0400 Subject: [nio dev] [8] Review request for 8028049 : Tidy warnings cleanup for packages java.nio/java.io In-Reply-To: <11954436.boXYgDLUUM@workland> References: <1929736.jKUYgnqaqV@workland> <5280BF2B.50308@oracle.com> <52811E17.8000204@oracle.com> <11954436.boXYgDLUUM@workland> Message-ID: <5289E258.4030400@oracle.com> The fix looks OK to me: may I review it being jdk8 Reviewer? I hope I can push it for Sergey to tl repository if there is no objections. Thanks, -yan On 11/12/2013 11:06 AM, Sergey Lugovoy wrote: > Hi all, > please look at the second patch > http://cr.openjdk.java.net/~yan/8028049/webrev.01/ > for https://bugs.openjdk.java.net/browse/JDK-8028049 > > As Joe suggested, I removed the tag

    at the end of comments; removed tag > from link; reran doclint - no new warnings. > > On Monday, November 11, 2013 10:12:39 AM Joe Darcy wrote: >> On 11/11/2013 3:27 AM, Alan Bateman wrote: >>> On 11/11/2013 06:02, Sergey Lugovoy wrote: >>>> Hi all, >>>> please review the fix >>>> http://cr.openjdk.java.net/~yan/8028049/webrev.00/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8028049 >>>> >>>> This patch cleanup tidy warnings for generated html documentation, >>>> and do not >>>> affect the appearance of the documentation. >>> >>> Thanks for working on this. >>> >>> I don't understand the need for the breaks (the replacements of

    >>> with
    ), are you sure these are needed? >> >> Yes, I would assume in a situation like >> >> * end of stream rather than throwing an exception. >> - *

    >> + *
    >> * >> * @author Frank Yellin >> >> it would suffice just to remove the

    tag, resulting in >> >> * end of stream rather than throwing an exception. >> - *

    >> * >> * @author Frank Yellin >> >>> In the package.html you've changed it from .. to >>> .. . I think it would be better to just remove the code tags as >>> we are already in a link (this is the reason why it was originally >>> done as .. ). >> >> For this construct, >> >>

  • A byte buffer can be created by {@link >> - java.nio.channels.FileChannel#map mapping} a >> region of a >> + java.nio.channels.FileChannel#map mapping} a >> region of a >> >> you should replace with the linkplain tag. >> >> Cheers, >> >> -Joe >> >>> Otherwise I think it looks okay. I assume you'll run doclint, in >>> addition to tidy, to make sure that we are clean before pushing this. >>> >>> -Alan. From Alan.Bateman at oracle.com Mon Nov 18 02:29:02 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Nov 2013 10:29:02 +0000 Subject: [nio dev] [8] Review request for 8028049 : Tidy warnings cleanup for packages java.nio/java.io In-Reply-To: <5289E258.4030400@oracle.com> References: <1929736.jKUYgnqaqV@workland> <5280BF2B.50308@oracle.com> <52811E17.8000204@oracle.com> <11954436.boXYgDLUUM@workland> <5289E258.4030400@oracle.com> Message-ID: <5289EBEE.80405@oracle.com> On 18/11/2013 09:48, Yuri Nesterenko wrote: > The fix looks OK to me: may I review it being jdk8 Reviewer? > I hope I can push it for Sergey to tl repository > if there is no objections. > Joe and I did review it. There is one outstanding comment in Joe's original mail suggesting that the link in the package description be changed to a linkplain (the ... usage in the link used to be common to get things to look right). I don't think the webrev was updated so if you are sponsoring this then can you check on that point to make sure that it looks okay in the generated javadoc. -Alan. From yuri.nesterenko at oracle.com Mon Nov 18 04:32:02 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Mon, 18 Nov 2013 16:32:02 +0400 Subject: [nio dev] [8] Review request for 8028049 : Tidy warnings cleanup for packages java.nio/java.io In-Reply-To: <5289EBEE.80405@oracle.com> References: <1929736.jKUYgnqaqV@workland> <5280BF2B.50308@oracle.com> <52811E17.8000204@oracle.com> <11954436.boXYgDLUUM@workland> <5289E258.4030400@oracle.com> <5289EBEE.80405@oracle.com> Message-ID: <528A08C2.9090707@oracle.com> On 11/18/2013 02:29 PM, Alan Bateman wrote: > On 18/11/2013 09:48, Yuri Nesterenko wrote: >> The fix looks OK to me: may I review it being jdk8 Reviewer? >> I hope I can push it for Sergey to tl repository >> if there is no objections. >> > Joe and I did review it. There is one outstanding comment in Joe's > original mail suggesting that the link in the package description be > changed to a linkplain (the ... usage in the link used > to be common to get things to look right). I don't think the webrev was > updated so if you are sponsoring this then can you check on that point > to make sure that it looks okay in the generated javadoc. > > -Alan. Hi Alan, we duly compared: it looked very much the same in this exact place. Somewhere a removed "

    " without "
    " resulted in someway smaller line space -- but it was agreed that's not a problem. So I'm putting you and Joe as the reviewers and pushing the fix. Thanks, -yan From yiming.wang at oracle.com Mon Nov 18 22:25:02 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 19 Nov 2013 14:25:02 +0800 Subject: RFR for JDK-8027212: java/nio/channels/Selector/SelectAfterRead.java fails intermittently Message-ID: <528B043E.4090102@oracle.com> Hi everyone, I'm working on the bug https://bugs.openjdk.java.net/browse/JDK-8027212. after research, it is a test failure. Root Cause: The test is based on bad assumption that the ByteServer thread has finished to write bytes to client before the client SelectAfterRead calls selector.select(TIMEOUT)(TIMEOUT=1000). Suggested Fix: Use CountDownLatch to sync up server and client, The fix looks like below, Please let me know if you have any comments or suggestions. server side: class ByteServer { *CountDownLatch latch = new CountDownLatch(1);* public void start() { serverthread = new Thread() { public void run() { try {... } finally { *latch.countDown();*}*// count down when thread finish to write bytes* } }; serverThread.start(); } * public void await() {**latch.await();**}* *// new api for sync up** *} client side: class SelectAfterRead { public static void main(String[] args) { ... * server.await(); // sync up with server** * if (sel.select(TIMEOUT) != 1) ... } } Thanks. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131119/78068d4e/attachment.html From Alan.Bateman at oracle.com Tue Nov 19 02:36:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 10:36:17 +0000 Subject: RFR for JDK-8027212: java/nio/channels/Selector/SelectAfterRead.java fails intermittently In-Reply-To: <528B043E.4090102@oracle.com> References: <528B043E.4090102@oracle.com> Message-ID: <528B3F21.1050508@oracle.com> On 19/11/2013 06:25, Eric Wang wrote: > Hi everyone, > > I'm working on the bug > https://bugs.openjdk.java.net/browse/JDK-8027212. after research, it > is a test failure. > Root Cause: > The test is based on bad assumption that the ByteServer thread has > finished to write bytes to client before the client SelectAfterRead > calls selector.select(TIMEOUT)(TIMEOUT=1000). > > Suggested Fix: > Use CountDownLatch to sync up server and client, The fix looks like > below, Please let me know if you have any comments or suggestions. Thanks Eric, I think your analysis that the 1000ms is insufficient is right (unfortunately some of the tests from the JDK 1.4 era had issues like this). We can fix this in several ways. Using a CountDownLatch is okay here but it might be simpler for await to do serverthread.join() because the server thread ends when it has written the bytes. What you would think about doing a few other clean-ups to ByteServer? For example the start method shouldn't do a System.exit if it gets an exception Also several of the fields can be final. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131119/09c4a642/attachment.html From jan.schloessin at incasoft.de Tue Nov 19 07:09:03 2013 From: jan.schloessin at incasoft.de (=?UTF-8?B?SmFuIFNjaGzDtsOfaW4=?=) Date: Tue, 19 Nov 2013 16:09:03 +0100 Subject: conformance check for user file systems Message-ID: <528B7F0F.5040802@incasoft.de> Hi, I'm involved in the development of a memory file system as implementation of FileSystemProvider, FileSystem, Path etc. This file system should have a consistent behaviour to a default file system as far as possible. Or it should behave like what is common among UnixFileSystem, WindowsFileSystem and Mac for instance. Is there a test suite to check for such things that should be common among all file systems like: - after successfully creating of a file, this file should exist - after successfully creating of a dir, this dir should exist - a parent of a file should list the file as its content - ... - and the like with file content - ... Regards, Jan From Alan.Bateman at oracle.com Tue Nov 19 07:18:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 15:18:36 +0000 Subject: conformance check for user file systems In-Reply-To: <528B7F0F.5040802@incasoft.de> References: <528B7F0F.5040802@incasoft.de> Message-ID: <528B814C.6080701@oracle.com> On 19/11/2013 15:09, Jan Schl??in wrote: > Hi, > > I'm involved in the development of a memory file system as > implementation of FileSystemProvider, FileSystem, Path etc. > > This file system should have a consistent behaviour to a default file > system as far as possible. Or it should behave like what is common among > UnixFileSystem, WindowsFileSystem and Mac for instance. > > Is there a test suite to check for such things that should be common > among all file systems like: > - after successfully creating of a file, this file should exist > - after successfully creating of a dir, this dir should exist > - a parent of a file should list the file as its content > - ... > - and the like with file content > - ... > > Regards, Jan There isn't but it would be a great project for someone to do. -Alan From Alan.Bateman at oracle.com Wed Nov 20 04:08:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Nov 2013 12:08:07 +0000 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528BFAFC.9010804@oracle.com> References: <528BFAFC.9010804@oracle.com> Message-ID: <528CA627.9000108@oracle.com> On 19/11/2013 23:57, Dan Xu wrote: > Hi All, > > Please review the simple fix towards Size.java testcase. It failed > once on windows platform in the recent same binary run, which is > mostly due to some interferences and the special delete handling on > windows. > > In the fix, I remove the delete operation in initTestFile() method > because FileOutputStream will truncate the file content and it is not > necessary to delete it first. Thanks! > > Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 > Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ > This does look like a case where the test is needlessly deleting and re-creating the file (although still annoying to have interference from virus checkers or other background services). As you point out, FileOutputStream will truncate an existing file so it's not needed. So I think your changes to remove the exist/delete from the init method is good. If you have the cycles then there are probably a few clean-ups that could be done on this test. I don't think blah needs to be static, it could use try-with-resources and delete blah in the finally block. Also test2 looks historical, it may be that this can be enabled on Linux and Windows now (the bug/comments seem to date from JDK 1.4). -Alan From dan.xu at oracle.com Wed Nov 20 17:09:02 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 20 Nov 2013 17:09:02 -0800 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528CA627.9000108@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> Message-ID: <528D5D2E.9080307@oracle.com> Hi All, I have updated my fix based on your suggestions. I have changed to create testing files in the working directory, moved those static member variables into local method variables, and used try-with-resources to read and write the testing files. After the change, the file delete is no longer important. So I just do the clean-up with deleteOnExit() for simplicity. If the test fails, it is better to keep the test file to give more clue. Therefore, I don't put the file clean-up into finally block. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev01/ -Dan On 11/20/2013 04:08 AM, Alan Bateman wrote: > On 19/11/2013 23:57, Dan Xu wrote: >> Hi All, >> >> Please review the simple fix towards Size.java testcase. It failed >> once on windows platform in the recent same binary run, which is >> mostly due to some interferences and the special delete handling on >> windows. >> >> In the fix, I remove the delete operation in initTestFile() method >> because FileOutputStream will truncate the file content and it is not >> necessary to delete it first. Thanks! >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 >> Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ >> > This does look like a case where the test is needlessly deleting and > re-creating the file (although still annoying to have interference > from virus checkers or other background services). As you point out, > FileOutputStream will truncate an existing file so it's not needed. So > I think your changes to remove the exist/delete from the init method > is good. > > If you have the cycles then there are probably a few clean-ups that > could be done on this test. I don't think blah needs to be static, it > could use try-with-resources and delete blah in the finally block. > Also test2 looks historical, it may be that this can be enabled on > Linux and Windows now (the bug/comments seem to date from JDK 1.4). > > -Alan > From Alan.Bateman at oracle.com Thu Nov 21 05:41:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 13:41:18 +0000 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528D5D2E.9080307@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> <528D5D2E.9080307@oracle.com> Message-ID: <528E0D7E.6050706@oracle.com> On 21/11/2013 01:09, Dan Xu wrote: > Hi All, > > I have updated my fix based on your suggestions. I have changed to > create testing files in the working directory, moved those static > member variables into local method variables, and used > try-with-resources to read and write the testing files. After the > change, the file delete is no longer important. So I just do the > clean-up with deleteOnExit() for simplicity. If the test fails, it is > better to keep the test file to give more clue. Therefore, I don't put > the file clean-up into finally block. Thanks! > > Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev01/ > > -Dan Just one thing about testLargeFile, I see that it additionally creates a file-mapping and it's not clear that this is needed (I don't see anything in JDK-4563125 to explain this). I suspect this can be removed. Otherwise it looks okay to me. -Alan. From dan.xu at oracle.com Thu Nov 21 09:02:56 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 21 Nov 2013 09:02:56 -0800 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528E0D7E.6050706@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> <528D5D2E.9080307@oracle.com> <528E0D7E.6050706@oracle.com> Message-ID: <528E3CC0.1070907@oracle.com> On 11/21/2013 05:41 AM, Alan Bateman wrote: > On 21/11/2013 01:09, Dan Xu wrote: >> Hi All, >> >> I have updated my fix based on your suggestions. I have changed to >> create testing files in the working directory, moved those static >> member variables into local method variables, and used >> try-with-resources to read and write the testing files. After the >> change, the file delete is no longer important. So I just do the >> clean-up with deleteOnExit() for simplicity. If the test fails, it is >> better to keep the test file to give more clue. Therefore, I don't >> put the file clean-up into finally block. Thanks! >> >> Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev01/ >> >> -Dan > Just one thing about testLargeFile, I see that it additionally creates > a file-mapping and it's not clear that this is needed (I don't see > anything in JDK-4563125 to explain this). I suspect this can be removed. > > Otherwise it looks okay to me. > > -Alan. > > Hi Alan, I think the map is used to enlarge the size of the largeFile to testSize + 10. In initTestFile(), it initiates the file with size 10. My understanding is that it avoids writing large amount of data into the largeFile by using the map. Thanks! -Dan From dan.xu at oracle.com Thu Nov 21 11:29:20 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 21 Nov 2013 11:29:20 -0800 Subject: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root Message-ID: <528E5F10.8090508@oracle.com> Hi All, Please review the simple fix towards test/java/nio/file/Files/Misc.java. It only fails when it is run by root. As Alan commented in the bug, the root has all permissions, so the test assumptions are wrong. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-7065902 Webrev: http://cr.openjdk.java.net/~dxu/7065902/webrev/ -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131121/0a6bb88f/attachment.html From Alan.Bateman at oracle.com Thu Nov 21 11:51:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 19:51:28 +0000 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528E3CC0.1070907@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> <528D5D2E.9080307@oracle.com> <528E0D7E.6050706@oracle.com> <528E3CC0.1070907@oracle.com> Message-ID: <528E6440.4070306@oracle.com> On 21/11/2013 17:02, Dan Xu wrote: > > Hi Alan, > > I think the map is used to enlarge the size of the largeFile to > testSize + 10. In initTestFile(), it initiates the file with size 10. > My understanding is that it avoids writing large amount of data into > the largeFile by using the map. Thanks! > > -Dan Okay, I guess I was really just wondering about the reliability on Windows as sometimes tests that use memory mapped files are troublesome when it comes to clean-up after the test. Also as this test hasn't run on Windows before then I wonder about how long initTestFile will take to create the 4GB file. You've probably measured already but if you need a speed up then you could change initTestFile to use a FIleChannel and create the file with the SPARSE option. Then just position to size-1 and write 1 byte. That should be faster than writing "e" 4 billion times. -Alan. From Alan.Bateman at oracle.com Thu Nov 21 12:22:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 20:22:44 +0000 Subject: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root In-Reply-To: <528E5F10.8090508@oracle.com> References: <528E5F10.8090508@oracle.com> Message-ID: <528E6B94.1030209@oracle.com> On 21/11/2013 19:29, Dan Xu wrote: > Hi All, > > Please review the simple fix towards > test/java/nio/file/Files/Misc.java. It only fails when it is run by > root. As Alan commented in the bug, the root has all permissions, so > the test assumptions are wrong. Thanks! > > Bug: https://bugs.openjdk.java.net/browse/JDK-7065902 > Webrev: http://cr.openjdk.java.net/~dxu/7065902/webrev/ This looks okay although it's possible for users other than root to be a superuser. I think we have at least one other test that checks if /etc/passwd is writable as a crude indication as to whether the test is being run by root or not. -Alan From dan.xu at oracle.com Thu Nov 21 12:42:51 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 21 Nov 2013 12:42:51 -0800 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528E6440.4070306@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> <528D5D2E.9080307@oracle.com> <528E0D7E.6050706@oracle.com> <528E3CC0.1070907@oracle.com> <528E6440.4070306@oracle.com> Message-ID: <528E704B.2030705@oracle.com> Hi Alan, When looking at the FileChannel.map() method, it seems that it will not write "e" 4 billion times. Instead, it only extends the file size to testSize+10. It uses ftruncate() in linux and uses SetFilePointer() in Windows, which causes the file offset different on different platforms. But the performance should be good. On windows, this test runs for around 0.14 seconds in jprt machines. Thanks! -Dan On Thu 21 Nov 2013 11:51:28 AM PST, Alan Bateman wrote: > On 21/11/2013 17:02, Dan Xu wrote: >> >> Hi Alan, >> >> I think the map is used to enlarge the size of the largeFile to >> testSize + 10. In initTestFile(), it initiates the file with size 10. >> My understanding is that it avoids writing large amount of data into >> the largeFile by using the map. Thanks! >> >> -Dan > Okay, I guess I was really just wondering about the reliability on > Windows as sometimes tests that use memory mapped files are > troublesome when it comes to clean-up after the test. Also as this > test hasn't run on Windows before then I wonder about how long > initTestFile will take to create the 4GB file. You've probably > measured already but if you need a speed up then you could change > initTestFile to use a FIleChannel and create the file with the SPARSE > option. Then just position to size-1 and write 1 byte. That should be > faster than writing "e" 4 billion times. > > -Alan. > From rob.mckenna at oracle.com Thu Nov 21 12:48:20 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 21 Nov 2013 20:48:20 +0000 Subject: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root In-Reply-To: <528E6B94.1030209@oracle.com> References: <528E5F10.8090508@oracle.com> <528E6B94.1030209@oracle.com> Message-ID: <528E7194.9010202@oracle.com> Util.java in: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da14e2c90bcb does this. -Rob On 21/11/13 20:22, Alan Bateman wrote: > On 21/11/2013 19:29, Dan Xu wrote: >> Hi All, >> >> Please review the simple fix towards >> test/java/nio/file/Files/Misc.java. It only fails when it is run by >> root. As Alan commented in the bug, the root has all permissions, so >> the test assumptions are wrong. Thanks! >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-7065902 >> Webrev: http://cr.openjdk.java.net/~dxu/7065902/webrev/ > This looks okay although it's possible for users other than root to be > a superuser. I think we have at least one other test that checks if > /etc/passwd is writable as a crude indication as to whether the test > is being run by root or not. > > -Alan From dan.xu at oracle.com Thu Nov 21 13:10:05 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 21 Nov 2013 13:10:05 -0800 Subject: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root In-Reply-To: <528E7194.9010202@oracle.com> References: <528E5F10.8090508@oracle.com> <528E6B94.1030209@oracle.com> <528E7194.9010202@oracle.com> Message-ID: <528E76AD.8080602@oracle.com> Thank you, Rob and Alan. I have a new version for this, http://cr.openjdk.java.net/~dxu/7065902/webrev01/ . Please review it. -Dan On 11/21/2013 12:48 PM, Rob McKenna wrote: > Util.java in: > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da14e2c90bcb > > does this. > > -Rob > > On 21/11/13 20:22, Alan Bateman wrote: >> On 21/11/2013 19:29, Dan Xu wrote: >>> Hi All, >>> >>> Please review the simple fix towards >>> test/java/nio/file/Files/Misc.java. It only fails when it is run by >>> root. As Alan commented in the bug, the root has all permissions, so >>> the test assumptions are wrong. Thanks! >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-7065902 >>> Webrev: http://cr.openjdk.java.net/~dxu/7065902/webrev/ >> This looks okay although it's possible for users other than root to >> be a superuser. I think we have at least one other test that checks >> if /etc/passwd is writable as a crude indication as to whether the >> test is being run by root or not. >> >> -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131121/647fc94b/attachment.html From Alan.Bateman at oracle.com Thu Nov 21 13:43:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 21:43:44 +0000 Subject: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root In-Reply-To: <528E76AD.8080602@oracle.com> References: <528E5F10.8090508@oracle.com> <528E6B94.1030209@oracle.com> <528E7194.9010202@oracle.com> <528E76AD.8080602@oracle.com> Message-ID: <528E7E90.9060307@oracle.com> On 21/11/2013 21:10, Dan Xu wrote: > Thank you, Rob and Alan. > > I have a new version for this, > http://cr.openjdk.java.net/~dxu/7065902/webrev01/ > . Please review it. > > -Dan This look like good (a small refinement would be to drop the Files.exist in isRoot as it isn't needed). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131121/e526640b/attachment.html From dan.xu at oracle.com Thu Nov 21 13:50:19 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 21 Nov 2013 13:50:19 -0800 Subject: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root In-Reply-To: <528E7E90.9060307@oracle.com> References: <528E5F10.8090508@oracle.com> <528E6B94.1030209@oracle.com> <528E7194.9010202@oracle.com> <528E76AD.8080602@oracle.com> <528E7E90.9060307@oracle.com> Message-ID: <528E801B.1030801@oracle.com> Thanks, Alan. I have removed the Files.exist in the new version, http://cr.openjdk.java.net/~dxu/7065902/webrev02/ -Dan On 11/21/2013 01:43 PM, Alan Bateman wrote: > On 21/11/2013 21:10, Dan Xu wrote: >> Thank you, Rob and Alan. >> >> I have a new version for this, >> http://cr.openjdk.java.net/~dxu/7065902/webrev01/ >> . Please review it. >> >> -Dan > This look like good (a small refinement would be to drop the > Files.exist in isRoot as it isn't needed). > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131121/487f5d1a/attachment.html From Alan.Bateman at oracle.com Thu Nov 21 13:52:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 21:52:43 +0000 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528E704B.2030705@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> <528D5D2E.9080307@oracle.com> <528E0D7E.6050706@oracle.com> <528E3CC0.1070907@oracle.com> <528E6440.4070306@oracle.com> <528E704B.2030705@oracle.com> Message-ID: <528E80AB.6090900@oracle.com> On 21/11/2013 20:42, Dan Xu wrote: > Hi Alan, > > When looking at the FileChannel.map() method, it seems that it will > not write "e" 4 billion times. Instead, it only extends the file size > to testSize+10. It uses ftruncate() in linux and uses SetFilePointer() > in Windows, which causes the file offset different on different > platforms. But the performance should be good. On windows, this test > runs for around 0.14 seconds in jprt machines. Thanks! Okay, what you have is fine and in time we will see whether it reliable. -Alan From Alan.Bateman at oracle.com Thu Nov 21 13:53:21 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 21:53:21 +0000 Subject: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root In-Reply-To: <528E801B.1030801@oracle.com> References: <528E5F10.8090508@oracle.com> <528E6B94.1030209@oracle.com> <528E7194.9010202@oracle.com> <528E76AD.8080602@oracle.com> <528E7E90.9060307@oracle.com> <528E801B.1030801@oracle.com> Message-ID: <528E80D1.3000702@oracle.com> On 21/11/2013 21:50, Dan Xu wrote: > Thanks, Alan. I have removed the Files.exist in the new version, > http://cr.openjdk.java.net/~dxu/7065902/webrev02/ > > Looks good (I didn't mean you to have to create another webrev). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131121/adb3e44d/attachment-0001.html From dan.xu at oracle.com Thu Nov 21 14:02:38 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 21 Nov 2013 14:02:38 -0800 Subject: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root In-Reply-To: <528E80D1.3000702@oracle.com> References: <528E5F10.8090508@oracle.com> <528E6B94.1030209@oracle.com> <528E7194.9010202@oracle.com> <528E76AD.8080602@oracle.com> <528E7E90.9060307@oracle.com> <528E801B.1030801@oracle.com> <528E80D1.3000702@oracle.com> Message-ID: <528E82FE.4050302@oracle.com> It is not that hard to create the webrev. :) Thanks for your review. I will push those changes. -Dan On 11/21/2013 01:53 PM, Alan Bateman wrote: > On 21/11/2013 21:50, Dan Xu wrote: >> Thanks, Alan. I have removed the Files.exist in the new version, >> http://cr.openjdk.java.net/~dxu/7065902/webrev02/ >> >> > Looks good (I didn't mean you to have to create another webrev). > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131121/08934a4d/attachment.html From yiming.wang at oracle.com Mon Nov 25 01:15:26 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Mon, 25 Nov 2013 17:15:26 +0800 Subject: RFR for JDK-8027212: java/nio/channels/Selector/SelectAfterRead.java fails intermittently In-Reply-To: <528B3F21.1050508@oracle.com> References: <528B043E.4090102@oracle.com> <528B3F21.1050508@oracle.com> Message-ID: <5293152E.9060703@oracle.com> Hi Alan & All, I finally finished the internal discussion about the fix. Please review the webrev below, I also make some cleanup jobs, so other 3 tests which uses ByteServer are changed. http://cr.openjdk.java.net/~ewang/JDK-8027212/webrev.00/ Thanks, Eric On 2013/11/19 18:36, Alan Bateman wrote: > On 19/11/2013 06:25, Eric Wang wrote: >> Hi everyone, >> >> I'm working on the bug >> https://bugs.openjdk.java.net/browse/JDK-8027212. after research, it >> is a test failure. >> Root Cause: >> The test is based on bad assumption that the ByteServer thread has >> finished to write bytes to client before the client SelectAfterRead >> calls selector.select(TIMEOUT)(TIMEOUT=1000). >> >> Suggested Fix: >> Use CountDownLatch to sync up server and client, The fix looks like >> below, Please let me know if you have any comments or suggestions. > Thanks Eric, I think your analysis that the 1000ms is insufficient is > right (unfortunately some of the tests from the JDK 1.4 era had issues > like this). > > We can fix this in several ways. Using a CountDownLatch is okay here > but it might be simpler for await to do serverthread.join() because > the server thread ends when it has written the bytes. > > What you would think about doing a few other clean-ups to ByteServer? > For example the start method shouldn't do a System.exit if it gets an > exception Also several of the fields can be final. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131125/9d9fa476/attachment.html From Alan.Bateman at oracle.com Mon Nov 25 04:46:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Nov 2013 12:46:24 +0000 Subject: RFR for JDK-8027212: java/nio/channels/Selector/SelectAfterRead.java fails intermittently In-Reply-To: <5293152E.9060703@oracle.com> References: <528B043E.4090102@oracle.com> <528B3F21.1050508@oracle.com> <5293152E.9060703@oracle.com> Message-ID: <529346A0.30808@oracle.com> On 25/11/2013 09:15, Eric Wang wrote: > Hi Alan & All, > > I finally finished the internal discussion about the fix. Please > review the webrev below, I also make some cleanup jobs, so other 3 > tests which uses ByteServer are changed. > http://cr.openjdk.java.net/~ewang/JDK-8027212/webrev.00/ > > This looks much better (and more extensive that the original proposal). Two comments on ByteServer: 1. It looks like socket is no longer closed. 2. You have removed savedException but that would be useful for the run method to set so that it can be re-thrown by the close method. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20131125/d0891c81/attachment.html From joe.darcy at oracle.com Mon Nov 11 10:12:56 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 11 Nov 2013 18:12:56 -0000 Subject: [nio dev] [8] Review request for 8028049 : Tidy warnings cleanup for packages java.nio/java.io In-Reply-To: <5280BF2B.50308@oracle.com> References: <1929736.jKUYgnqaqV@workland> <5280BF2B.50308@oracle.com> Message-ID: <52811E17.8000204@oracle.com> On 11/11/2013 3:27 AM, Alan Bateman wrote: > On 11/11/2013 06:02, Sergey Lugovoy wrote: >> Hi all, >> please review the fix >> http://cr.openjdk.java.net/~yan/8028049/webrev.00/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8028049 >> >> This patch cleanup tidy warnings for generated html documentation, >> and do not >> affect the appearance of the documentation. >> > Thanks for working on this. > > I don't understand the need for the breaks (the replacements of

    > with
    ), are you sure these are needed? Yes, I would assume in a situation like * end of stream rather than throwing an exception. - *

    + *
    * * @author Frank Yellin it would suffice just to remove the

    tag, resulting in * end of stream rather than throwing an exception. - *

    * * @author Frank Yellin > > In the package.html you've changed it from .. to > .. . I think it would be better to just remove the code tags as > we are already in a link (this is the reason why it was originally > done as .. ). For this construct,

  • A byte buffer can be created by {@link - java.nio.channels.FileChannel#map mapping} a region of a + java.nio.channels.FileChannel#map mapping} a region of a you should replace with the linkplain tag. Cheers, -Joe > > Otherwise I think it looks okay. I assume you'll run doclint, in > addition to tidy, to make sure that we are clean before pushing this. > > -Alan. From joe.darcy at oracle.com Tue Nov 12 15:16:35 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Tue, 12 Nov 2013 23:16:35 -0000 Subject: [nio dev] [8] Review request for 8028049 : Tidy warnings cleanup for packages java.nio/java.io In-Reply-To: <52821CD1.3000605@oracle.com> References: <1929736.jKUYgnqaqV@workland> <5280BF2B.50308@oracle.com> <52811E17.8000204@oracle.com> <11954436.boXYgDLUUM@workland> <52821CD1.3000605@oracle.com> Message-ID: <5282B6EB.8030704@oracle.com> On 11/12/2013 4:19 AM, Alan Bateman wrote: > On 12/11/2013 07:06, Sergey Lugovoy wrote: >> Hi all, >> please look at the second patch >> http://cr.openjdk.java.net/~yan/8028049/webrev.01/ >> for https://bugs.openjdk.java.net/browse/JDK-8028049 >> >> As Joe suggested, I removed the tag

    at the end of comments; >> removed tag >> from link; reran doclint - no new warnings. > This looks okay to me (although I think Joe was suggest linkplain). > > Right; I was suggesting something like {@linkplain java.nio.channels.FileChannel#map mapping} or {@linkplain java.nio.channels.FileChannel#map mapping} if the latter would render properly. -Joe