From mik3hall at gmail.com Sun Apr 3 04:15:25 2011 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 3 Apr 2011 06:15:25 -0500 Subject: Documentation typo Message-ID: I believe there is a typo in the javadoc here... http://download.oracle.com/javase/7/docs/api/java/nio/file/Files.html The typo being... direcregular filetory Although I might not mind working with a filetory sometime, it took me a little thought to be sure this wasn't some new jargon I wasn't familiar with. From Alan.Bateman at oracle.com Mon Apr 4 06:31:01 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Apr 2011 14:31:01 +0100 Subject: Documentation typo In-Reply-To: References: Message-ID: <4D99C815.6040900@oracle.com> Michael Hall wrote: > I believe there is a typo in the javadoc here... > http://download.oracle.com/javase/7/docs/api/java/nio/file/Files.html > > The typo being... > direcregular filetory > > Although I might not mind working with a filetory sometime, it took me a little thought to be sure this wasn't some new jargon I wasn't familiar with. Thanks Michael. I've created 7033568 to track this. I also see a typo in the isSymbolicLink and isDirectory methods. Can I get a reviewer for the attached? Thanks, Alan. diff --git a/src/share/classes/java/nio/file/Files.java b/src/share/classes/java/nio/file/Files.java --- a/src/share/classes/java/nio/file/Files.java +++ b/src/share/classes/java/nio/file/Files.java @@ -2067,7 +2067,7 @@ public final class Files { * * @return {@code true} if the file is a symbolic link; {@code false} if * the file does not exist, is not a symbolic link, or it cannot - * be determined if the file is symbolic link or not. + * be determined if the file is a symbolic link or not. * * @throws SecurityException * In the case of the default provider, and a security manager is @@ -2106,7 +2106,7 @@ public final class Files { * * @return {@code true} if the file is a directory; {@code false} if * the file does not exist, is not a directory, or it cannot - * be determined if the file is directory or not. + * be determined if the file is a directory or not. * * @throws SecurityException * In the case of the default provider, and a security manager is @@ -2142,8 +2142,8 @@ public final class Files { * options indicating how symbolic links are handled * * @return {@code true} if the file is a regular file; {@code false} if - * the file does not exist, is not a direcregular filetory, or it - * cannot be determined if the file is regular file or not. + * the file does not exist, is not a regular file, or it + * cannot be determined if the file is a regular file or not. * * @throws SecurityException * In the case of the default provider, and a security manager is From michael.x.mcmahon at oracle.com Mon Apr 4 07:03:05 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 04 Apr 2011 15:03:05 +0100 Subject: Documentation typo In-Reply-To: <4D99C815.6040900@oracle.com> References: <4D99C815.6040900@oracle.com> Message-ID: <4D99CF99.6090105@oracle.com> That looks fine Alan. - Michael. Alan Bateman wrote: > Michael Hall wrote: >> I believe there is a typo in the javadoc here... >> http://download.oracle.com/javase/7/docs/api/java/nio/file/Files.html >> >> The typo being... >> direcregular filetory >> >> Although I might not mind working with a filetory sometime, it took >> me a little thought to be sure this wasn't some new jargon I wasn't >> familiar with. > Thanks Michael. > > I've created 7033568 to track this. I also see a typo in the > isSymbolicLink and isDirectory methods. Can I get a reviewer for the > attached? Thanks, Alan. > > > diff --git a/src/share/classes/java/nio/file/Files.java > b/src/share/classes/java/nio/file/Files.java > --- a/src/share/classes/java/nio/file/Files.java > +++ b/src/share/classes/java/nio/file/Files.java > @@ -2067,7 +2067,7 @@ public final class Files { > * > * @return {@code true} if the file is a symbolic link; {@code > false} if > * the file does not exist, is not a symbolic link, or it > cannot > - * be determined if the file is symbolic link or not. > + * be determined if the file is a symbolic link or not. > * > * @throws SecurityException > * In the case of the default provider, and a security > manager is > @@ -2106,7 +2106,7 @@ public final class Files { > * > * @return {@code true} if the file is a directory; {@code false} if > * the file does not exist, is not a directory, or it cannot > - * be determined if the file is directory or not. > + * be determined if the file is a directory or not. > * > * @throws SecurityException > * In the case of the default provider, and a security > manager is > @@ -2142,8 +2142,8 @@ public final class Files { > * options indicating how symbolic links are handled > * > * @return {@code true} if the file is a regular file; {@code > false} if > - * the file does not exist, is not a direcregular > filetory, or it > - * cannot be determined if the file is regular file or not. > + * the file does not exist, is not a regular file, or it > + * cannot be determined if the file is a regular file or > not. > * > * @throws SecurityException > * In the case of the default provider, and a security > manager is From mike.duigou at oracle.com Mon Apr 4 09:08:51 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 4 Apr 2011 09:08:51 -0700 Subject: Documentation typo In-Reply-To: <4D99C815.6040900@oracle.com> References: <4D99C815.6040900@oracle.com> Message-ID: <55B1A879-BB0E-4D69-BB9E-565C85A5B049@oracle.com> These changes look fine to me. On Apr 4 2011, at 06:31 , Alan Bateman wrote: > Michael Hall wrote: >> I believe there is a typo in the javadoc here... >> http://download.oracle.com/javase/7/docs/api/java/nio/file/Files.html >> >> The typo being... >> direcregular filetory >> >> Although I might not mind working with a filetory sometime, it took me a little thought to be sure this wasn't some new jargon I wasn't familiar with. > Thanks Michael. > > I've created 7033568 to track this. I also see a typo in the isSymbolicLink and isDirectory methods. Can I get a reviewer for the attached? Thanks, Alan. > > > diff --git a/src/share/classes/java/nio/file/Files.java b/src/share/classes/java/nio/file/Files.java > --- a/src/share/classes/java/nio/file/Files.java > +++ b/src/share/classes/java/nio/file/Files.java > @@ -2067,7 +2067,7 @@ public final class Files { > * > * @return {@code true} if the file is a symbolic link; {@code false} if > * the file does not exist, is not a symbolic link, or it cannot > - * be determined if the file is symbolic link or not. > + * be determined if the file is a symbolic link or not. > * > * @throws SecurityException > * In the case of the default provider, and a security manager is > @@ -2106,7 +2106,7 @@ public final class Files { > * > * @return {@code true} if the file is a directory; {@code false} if > * the file does not exist, is not a directory, or it cannot > - * be determined if the file is directory or not. > + * be determined if the file is a directory or not. > * > * @throws SecurityException > * In the case of the default provider, and a security manager is > @@ -2142,8 +2142,8 @@ public final class Files { > * options indicating how symbolic links are handled > * > * @return {@code true} if the file is a regular file; {@code false} if > - * the file does not exist, is not a direcregular filetory, or it > - * cannot be determined if the file is regular file or not. > + * the file does not exist, is not a regular file, or it > + * cannot be determined if the file is a regular file or not. > * > * @throws SecurityException > * In the case of the default provider, and a security manager is From mik3hall at gmail.com Mon Apr 4 14:41:20 2011 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 4 Apr 2011 16:41:20 -0500 Subject: Documentation typo In-Reply-To: <4D99C815.6040900@oracle.com> References: <4D99C815.6040900@oracle.com> Message-ID: <183595E4-1738-4071-8346-580D86269CC0@gmail.com> On Apr 4, 2011, at 8:31 AM, Alan Bateman wrote: > Michael Hall wrote: >> I believe there is a typo in the javadoc here... >> http://download.oracle.com/javase/7/docs/api/java/nio/file/Files.html >> >> The typo being... >> direcregular filetory >> >> Although I might not mind working with a filetory sometime, it took me a little thought to be sure this wasn't some new jargon I wasn't familiar with. > Thanks Michael. Thanks Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110404/7d0e4703/attachment.html From Alan.Bateman at oracle.com Wed Apr 6 03:21:19 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Apr 2011 11:21:19 +0100 Subject: 7034155: (ch) NullPointerException in sun.io.ch.IOUtil when OOM is thrown Message-ID: <4D9C3E9F.1020204@oracle.com> A bug report was submitted with the following stack trace: java.lang.NullPointerException at sun.nio.ch.Util.free(Util.java:199) at sun.nio.ch.Util.offerFirstTemporaryDirectBuffer(Util.java:176) at sun.nio.ch.IOUtil.read(IOUtil.java:181) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:243) The NPE arises with code such as following when it's not possible to allocate a temporary direct buffer : ByteBuffer bb = null; try { bb = Util.getTemporaryDirectBuffer(...); : } finally { Util.releaseTemporaryDirectBuffer(bb); } Trivially fixed by changing this to: ByteBuffer bb = Util.getTemporaryDirectBuffer(...); try { : } finally { Util.releaseTemporaryDirectBuffer(bb); } An alternative would have been to change the Util methods to check for null, which is how it was handled originally. While changing DatagramChannelImpl I noticed that the exception thrown by the join is a bit confusing so I fixed that too. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7034155/webrev/ Thanks, Alan. From forax at univ-mlv.fr Wed Apr 6 05:42:54 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 06 Apr 2011 14:42:54 +0200 Subject: 7034155: (ch) NullPointerException in sun.io.ch.IOUtil when OOM is thrown In-Reply-To: <4D9C3E9F.1020204@oracle.com> References: <4D9C3E9F.1020204@oracle.com> Message-ID: <4D9C5FCE.3060005@univ-mlv.fr> On 04/06/2011 12:21 PM, Alan Bateman wrote: > > A bug report was submitted with the following stack trace: > > java.lang.NullPointerException > at sun.nio.ch.Util.free(Util.java:199) > at sun.nio.ch.Util.offerFirstTemporaryDirectBuffer(Util.java:176) > at sun.nio.ch.IOUtil.read(IOUtil.java:181) > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:243) > > The NPE arises with code such as following when it's not possible to > allocate a temporary direct buffer : > > ByteBuffer bb = null; > try { > bb = Util.getTemporaryDirectBuffer(...); > : > } finally { > Util.releaseTemporaryDirectBuffer(bb); > } > > Trivially fixed by changing this to: > > > ByteBuffer bb = Util.getTemporaryDirectBuffer(...); > try { > : > } finally { > Util.releaseTemporaryDirectBuffer(bb); > } > > An alternative would have been to change the Util methods to check for > null, which is how it was handled originally. > > While changing DatagramChannelImpl I noticed that the exception thrown > by the join is a bit confusing so I fixed that too. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/7034155/webrev/ > > Thanks, > Alan. Hi Alan, patch looks fine, just nitpicking, in innerJoin, the second exception message can be misleading if the socket use a proprietary protocol which is not IPV4 (a non StandardProtocolFamily). So I propose to change: "IPv4 socket cannot join IPv6 multicast group" to: "non IPv6 socket cannot join IPv6 multicast group" cheers, R?mi From Alan.Bateman at oracle.com Wed Apr 6 07:51:42 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Apr 2011 15:51:42 +0100 Subject: 7034155: (ch) NullPointerException in sun.io.ch.IOUtil when OOM is thrown In-Reply-To: <4D9C5FCE.3060005@univ-mlv.fr> References: <4D9C3E9F.1020204@oracle.com> <4D9C5FCE.3060005@univ-mlv.fr> Message-ID: <4D9C7DFE.6030504@oracle.com> R?mi Forax wrote: > : > Hi Alan, > patch looks fine, > just nitpicking, in innerJoin, the second exception message can be > misleading if > the socket use a proprietary protocol which is not IPV4 (a non > StandardProtocolFamily). > So I propose to change: > > "IPv4 socket cannot join IPv6 multicast group" > > to: > > "non IPv6 socket cannot join IPv6 multicast group" > > cheers, > R?mi > Would you be okay with "Only IPv6 socket can join IPv6 multicast group"? I think this case should be very rare and DatagramChannelImpl doesn't support any other protocol families at this time (the constructors ensure that it's INET or INET6). -Alan. From forax at univ-mlv.fr Wed Apr 6 08:41:03 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 06 Apr 2011 17:41:03 +0200 Subject: 7034155: (ch) NullPointerException in sun.io.ch.IOUtil when OOM is thrown In-Reply-To: <4D9C7DFE.6030504@oracle.com> References: <4D9C3E9F.1020204@oracle.com> <4D9C5FCE.3060005@univ-mlv.fr> <4D9C7DFE.6030504@oracle.com> Message-ID: <4D9C898F.90703@univ-mlv.fr> On 04/06/2011 04:51 PM, Alan Bateman wrote: > R?mi Forax wrote: >> : >> Hi Alan, >> patch looks fine, >> just nitpicking, in innerJoin, the second exception message can be >> misleading if >> the socket use a proprietary protocol which is not IPV4 (a non >> StandardProtocolFamily). >> So I propose to change: >> >> "IPv4 socket cannot join IPv6 multicast group" >> >> to: >> >> "non IPv6 socket cannot join IPv6 multicast group" >> >> cheers, >> R?mi >> > Would you be okay with "Only IPv6 socket can join IPv6 multicast > group"? I think this case should be very rare and DatagramChannelImpl > doesn't support any other protocol families at this time (the > constructors ensure that it's INET or INET6). Yes. > > -Alan. thanks, R?mi From rickard.backman at oracle.com Fri Apr 8 03:40:34 2011 From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=) Date: Fri, 08 Apr 2011 12:40:34 +0200 Subject: 7026287: Implement New I/O API (NIO.2) demo/sample Message-ID: <4D9EE622.8040809@oracle.com> Some sample code implementing a pretty basic chat server using the new asynchronous APIs in JDK7. The suggested sample: http://cr.openjdk.java.net/~rbackman/7026287/7026287-1/webrev/ Thanks /Rickard From Alan.Bateman at oracle.com Fri Apr 8 07:30:58 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Apr 2011 15:30:58 +0100 Subject: 7034532: (fs) AssertionError when working directory is UNC Message-ID: <4D9F1C22.3020208@oracle.com> Someone testing jdk7 in NetBeans reported the following stack trace when attempting to run their JUnit tests: Exception in thread "main" java.lang.AssertionError: Default directory must be absolute/non-UNC at sun.nio.fs.WindowsFileSystem.(WindowsFileSystem.java:60) at sun.nio.fs.WindowsFileSystemProvider.(WindowsFileSystemProvider.java:52) at sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:36) : at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906) The bug is that the code assumes that the process working directory cannot be an UNC. You can't "cd" to a UNC but you can launch a process with a UNC path as the working directory and that seems to be the case here. The fix is trivial and just allows the default directory to be a UNC: diff --git a/src/windows/classes/sun/nio/fs/WindowsFileSystem.java b/src/windows/classes/sun/nio/fs/WindowsFileSystem.java --- a/src/windows/classes/sun/nio/fs/WindowsFileSystem.java +++ b/src/windows/classes/sun/nio/fs/WindowsFileSystem.java @@ -56,8 +56,9 @@ class WindowsFileSystem // parse default directory and check it is absolute WindowsPathParser.Result result = WindowsPathParser.parse(dir); - if (result.type() != WindowsPathType.ABSOLUTE) - throw new AssertionError("Default directory must be absolute/non-UNC"); + if ((result.type() != WindowsPathType.ABSOLUTE) && + (result.type() != WindowsPathType.UNC)) + throw new AssertionError("Default directory is not an absolute path"); this.defaultDirectory = result.path(); this.defaultRoot = result.root(); I don't propose to include a regression test for this. Thanks, -Alan. From forax at univ-mlv.fr Fri Apr 8 09:01:25 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 08 Apr 2011 18:01:25 +0200 Subject: 7034532: (fs) AssertionError when working directory is UNC In-Reply-To: <4D9F1C22.3020208@oracle.com> References: <4D9F1C22.3020208@oracle.com> Message-ID: <4D9F3155.6010407@univ-mlv.fr> Thumb up R?mi On 04/08/2011 04:30 PM, Alan Bateman wrote: > > Someone testing jdk7 in NetBeans reported the following stack trace > when attempting to run their JUnit tests: > > Exception in thread "main" java.lang.AssertionError: Default directory > must be absolute/non-UNC > at sun.nio.fs.WindowsFileSystem.(WindowsFileSystem.java:60) > at > sun.nio.fs.WindowsFileSystemProvider.(WindowsFileSystemProvider.java:52) > at > sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:36) > : > at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906) > > The bug is that the code assumes that the process working directory > cannot be an UNC. You can't "cd" to a UNC but you can launch a process > with a UNC path as the working directory and that seems to be the case > here. > > The fix is trivial and just allows the default directory to be a UNC: > > diff --git a/src/windows/classes/sun/nio/fs/WindowsFileSystem.java > b/src/windows/classes/sun/nio/fs/WindowsFileSystem.java > --- a/src/windows/classes/sun/nio/fs/WindowsFileSystem.java > +++ b/src/windows/classes/sun/nio/fs/WindowsFileSystem.java > @@ -56,8 +56,9 @@ class WindowsFileSystem > // parse default directory and check it is absolute > WindowsPathParser.Result result = WindowsPathParser.parse(dir); > > - if (result.type() != WindowsPathType.ABSOLUTE) > - throw new AssertionError("Default directory must be > absolute/non-UNC"); > + if ((result.type() != WindowsPathType.ABSOLUTE) && > + (result.type() != WindowsPathType.UNC)) > + throw new AssertionError("Default directory is not an > absolute path"); > this.defaultDirectory = result.path(); > this.defaultRoot = result.root(); > > I don't propose to include a regression test for this. > > Thanks, > > -Alan. From mike.duigou at oracle.com Fri Apr 8 09:13:59 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 8 Apr 2011 09:13:59 -0700 Subject: 7034532: (fs) AssertionError when working directory is UNC In-Reply-To: <4D9F1C22.3020208@oracle.com> References: <4D9F1C22.3020208@oracle.com> Message-ID: The patch looks good to me. The direct throwing of AssertionError is a bit odd. InternalError instead perhaps? Mike On Apr 8 2011, at 07:30 , Alan Bateman wrote: > > Someone testing jdk7 in NetBeans reported the following stack trace when attempting to run their JUnit tests: > > Exception in thread "main" java.lang.AssertionError: Default directory must be absolute/non-UNC > at sun.nio.fs.WindowsFileSystem.(WindowsFileSystem.java:60) > at sun.nio.fs.WindowsFileSystemProvider.(WindowsFileSystemProvider.java:52) > at sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:36) > : > at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906) > > The bug is that the code assumes that the process working directory cannot be an UNC. You can't "cd" to a UNC but you can launch a process with a UNC path as the working directory and that seems to be the case here. > > The fix is trivial and just allows the default directory to be a UNC: > > diff --git a/src/windows/classes/sun/nio/fs/WindowsFileSystem.java b/src/windows/classes/sun/nio/fs/WindowsFileSystem.java > --- a/src/windows/classes/sun/nio/fs/WindowsFileSystem.java > +++ b/src/windows/classes/sun/nio/fs/WindowsFileSystem.java > @@ -56,8 +56,9 @@ class WindowsFileSystem > // parse default directory and check it is absolute > WindowsPathParser.Result result = WindowsPathParser.parse(dir); > - if (result.type() != WindowsPathType.ABSOLUTE) > - throw new AssertionError("Default directory must be absolute/non-UNC"); > + if ((result.type() != WindowsPathType.ABSOLUTE) && > + (result.type() != WindowsPathType.UNC)) > + throw new AssertionError("Default directory is not an absolute path"); > this.defaultDirectory = result.path(); > this.defaultRoot = result.root(); > > I don't propose to include a regression test for this. > > Thanks, > > -Alan. From Alan.Bateman at oracle.com Fri Apr 8 13:02:29 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Apr 2011 21:02:29 +0100 Subject: 7034532: (fs) AssertionError when working directory is UNC In-Reply-To: References: <4D9F1C22.3020208@oracle.com> Message-ID: <4D9F69D5.3050302@oracle.com> Mike Duigou wrote: > The patch looks good to me. > > The direct throwing of AssertionError is a bit odd. InternalError instead perhaps? > > > I'm not sure whether AssertionError or InternalError is the better choice. In the Windows provider it throws AssertionError in the otehr "should not reach here" cases so I think I'll keep it consistent for now -Alan From Alan.Bateman at oracle.com Mon Apr 11 06:14:13 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Apr 2011 14:14:13 +0100 Subject: 7026287: Implement New I/O API (NIO.2) demo/sample In-Reply-To: <4D9EE622.8040809@oracle.com> References: <4D9EE622.8040809@oracle.com> Message-ID: <4DA2FEA5.3020906@oracle.com> Rickard B?ckman wrote: > Some sample code implementing a pretty basic chat server using the new > asynchronous APIs in JDK7. > > The suggested sample: > http://cr.openjdk.java.net/~rbackman/7026287/7026287-1/webrev/ > > > Thanks > /Rickard Thanks for creating an additional sample for us. I've sent comments off-list on previous iterations so the following are just a few final comments. It might be better to put this sample in a "charserver" directory as it's very possible that we'll add additional sample code for the asynchronous I/O API in the future. In the top-level Makefile it's probably best to keep the SUBDIRS list in alphabetical order, not strictly required of course. The copyright date on make/mksample/nio/aio/Makefile is 2008-2011 and I assume you mean only 2011. In the README.txt I think this we should change this statement: "The server was written to demonstrate parts of the new functionality in NIO.2, in particular the asynchronous socket parts." to "The server was written to demonstrate the asynchronous I/O API in JDK 7. The sample assumes the reader has some familiarity with the subject matter." In ChatTest you should be able to use the @library tag to avoid listing the relative path to each class, eg: * @library ../../../../src/share/sample/nio/aio * @build ChatTest ChatServer Client ... * @run main ChatTest That's all I have. -Alan. From sjlee at apache.org Thu Apr 14 07:19:17 2011 From: sjlee at apache.org (Sangjin Lee) Date: Thu, 14 Apr 2011 07:19:17 -0700 Subject: why not both Future and CompletionHandler? Message-ID: Hi there, This may have been discussed in the past, but my googling didn't turn up a discussion... I've been looking at the I/O methods on the AsynchronousSocketChannel, and noticed that they let you interact with *either* Future or CompletionHandler, but not both. Each method flavor seems to have a pair (or more) of overloaded methods that lets you interact with the result only one way. Is there a reason not to use methods that allow you to use both mechanisms (Future and CompletionHandler) instead? For example, public Future connect(SocketAddress remote, A attachment, CompletionHandler handler); Thanks! Regards, Sangjin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110414/a1e2341e/attachment.html From Alan.Bateman at oracle.com Thu Apr 14 07:54:05 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2011 15:54:05 +0100 Subject: why not both Future and CompletionHandler? In-Reply-To: References: Message-ID: <4DA70A8D.4020500@oracle.com> Sangjin Lee wrote: > Hi there, > > This may have been discussed in the past, but my googling didn't turn > up a discussion... > > I've been looking at the I/O methods on the AsynchronousSocketChannel, > and noticed that they let you interact with *either* Future or > CompletionHandler, but not both. Each method flavor seems to have a > pair (or more) of overloaded methods that lets you interact with the > result only one way. Is there a reason not to use methods that allow > you to use both mechanisms (Future and CompletionHandler) instead? For > example, > > public Future connect(SocketAddress remote, A attachment, > CompletionHandler handler); That's right, you can use a Future or you specify a completion handler to consume the result. Do you have examples where you would want to consume the result of an I/O operation in a completion handler and at the same time wait or poll for the result? -Alan. From martijnverburg at gmail.com Thu Apr 14 08:03:36 2011 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 14 Apr 2011 16:03:36 +0100 Subject: Overall feedback from several conferences on NIO.2 Message-ID: Hi all, Just wanted to quickly chime in with a positive bit of news. Ben Evans and I have been presenting on Java 7 at several conferences (TSSJS, DevNexus, SDC, JAX London + some others) and overwhelmingly the audiences have given the Asynch I/O changes the big thumbs up. They also really enjoyed the new helper methods in the Files class and I got a number of comments saying that "it certainly looked like NIO.2, got it right". Obviously concrete feedback would be better and hopefully you'll get some more developers reporting issues, but I thought I'd let you know about the general vibe anyhow :) Cheers, Martijn From sjlee at apache.org Thu Apr 14 08:20:11 2011 From: sjlee at apache.org (Sangjin Lee) Date: Thu, 14 Apr 2011 08:20:11 -0700 Subject: why not both Future and CompletionHandler? In-Reply-To: <4DA70A8D.4020500@oracle.com> References: <4DA70A8D.4020500@oracle.com> Message-ID: Yes, I think it can come very handy if you want to add some cross-cutting concerns in the completion handlers but allow the end users to interact with the result via Future. For example, suppose I build a framework/library for others using the async channels (HTTP app, ssh app, etc.). I want to allow my users freedom to choose between the "pull" (future) and the "push" (completion handler). However, *regardless* of what my end user choose to interact with the result, I want to be able to inject some concerns like logging, instrumenting, etc. in the form of a completion handler (can be completely internal to the framework). With the current APIs, if the user wants a future, the framework cannot use the completion handler and I would need to find another way to inject such logic. Or if I want to retain the completion handler for the framework, then I would need to create my own future objects to provide to the end users. Either approach is doable, but it would be so much easier if the NIO.2 APIs provide both mechanisms in a single method call. My 2 cents. Thanks! Regards, Sangjin On Thu, Apr 14, 2011 at 7:54 AM, Alan Bateman wrote: > Sangjin Lee wrote: > >> Hi there, >> >> This may have been discussed in the past, but my googling didn't turn up a >> discussion... >> >> I've been looking at the I/O methods on the AsynchronousSocketChannel, and >> noticed that they let you interact with *either* Future or >> CompletionHandler, but not both. Each method flavor seems to have a pair (or >> more) of overloaded methods that lets you interact with the result only one >> way. Is there a reason not to use methods that allow you to use both >> mechanisms (Future and CompletionHandler) instead? For example, >> >> public Future connect(SocketAddress remote, A attachment, >> CompletionHandler handler); >> > That's right, you can use a Future or you specify a completion handler to > consume the result. Do you have examples where you would want to consume the > result of an I/O operation in a completion handler and at the same time wait > or poll for the result? > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110414/5c2cb87b/attachment.html From Alan.Bateman at oracle.com Thu Apr 14 08:36:39 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2011 16:36:39 +0100 Subject: Overall feedback from several conferences on NIO.2 In-Reply-To: References: Message-ID: <4DA71487.10007@oracle.com> Martijn Verburg wrote: > Hi all, > > Just wanted to quickly chime in with a positive bit of news. Ben > Evans and I have been presenting on Java 7 at several conferences > (TSSJS, DevNexus, SDC, JAX London + some others) and overwhelmingly > the audiences have given the Asynch I/O changes the big thumbs up. > They also really enjoyed the new helper methods in the Files class and > I got a number of comments saying that "it certainly looked like > NIO.2, got it right". > > Obviously concrete feedback would be better and hopefully you'll get > some more developers reporting issues, but I thought I'd let you know > about the general vibe anyhow :) > > Cheers, > Martijn > Good to hear that it is been well received and thanks for taking the time to let us know. Are the slides that you have been using online somewhere? -Alan From Alan.Bateman at oracle.com Thu Apr 14 08:38:19 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2011 16:38:19 +0100 Subject: why not both Future and CompletionHandler? In-Reply-To: References: <4DA70A8D.4020500@oracle.com> Message-ID: <4DA714EB.1000300@oracle.com> Sangjin Lee wrote: > Yes, I think it can come very handy if you want to add some > cross-cutting concerns in the completion handlers but allow the end > users to interact with the result via Future. > > For example, suppose I build a framework/library for others using the > async channels (HTTP app, ssh app, etc.). I want to allow my users > freedom to choose between the "pull" (future) and the "push" > (completion handler). However, *regardless* of what my end user choose > to interact with the result, I want to be able to inject some concerns > like logging, instrumenting, etc. in the form of a completion handler > (can be completely internal to the framework). > > With the current APIs, if the user wants a future, the framework > cannot use the completion handler and I would need to find another way > to inject such logic. Or if I want to retain the completion handler > for the framework, then I would need to create my own future objects > to provide to the end users. Either approach is doable, but it would > be so much easier if the NIO.2 APIs provide both mechanisms in a > single method call. My 2 cents. Thanks! For high performance applications using completion handlers then we don't want to future Future objects that won't be used. In your framework/library then won't it return your own Future type anyway? -Alan. From forax at univ-mlv.fr Thu Apr 14 09:01:24 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 14 Apr 2011 18:01:24 +0200 Subject: why not both Future and CompletionHandler? In-Reply-To: <4DA714EB.1000300@oracle.com> References: <4DA70A8D.4020500@oracle.com> <4DA714EB.1000300@oracle.com> Message-ID: <4DA71A54.2030408@univ-mlv.fr> On 04/14/2011 05:38 PM, Alan Bateman wrote: > Sangjin Lee wrote: >> Yes, I think it can come very handy if you want to add some >> cross-cutting concerns in the completion handlers but allow the end >> users to interact with the result via Future. >> >> For example, suppose I build a framework/library for others using the >> async channels (HTTP app, ssh app, etc.). I want to allow my users >> freedom to choose between the "pull" (future) and the "push" >> (completion handler). However, *regardless* of what my end user >> choose to interact with the result, I want to be able to inject some >> concerns like logging, instrumenting, etc. in the form of a >> completion handler (can be completely internal to the framework). >> >> With the current APIs, if the user wants a future, the framework >> cannot use the completion handler and I would need to find another >> way to inject such logic. Or if I want to retain the completion >> handler for the framework, then I would need to create my own future >> objects to provide to the end users. Either approach is doable, but >> it would be so much easier if the NIO.2 APIs provide both mechanisms >> in a single method call. My 2 cents. Thanks! > For high performance applications using completion handlers then we > don't want to future Future objects that won't be used. In your > framework/library then won't it return your own Future type anyway? > > -Alan. Or if I want to use a completion handler but have also a way to cancel the operation. R?mi From wolfgang.baltes at laposte.net Thu Apr 14 09:16:40 2011 From: wolfgang.baltes at laposte.net (wolfgang.baltes) Date: Thu, 14 Apr 2011 18:16:40 +0200 (CEST) Subject: No subject Message-ID: <29927420.555060.1302797800272.JavaMail.www@wwinf8203> On 2011-04-14 08:38, Alan Bateman wrote: > > Sangjin Lee wrote: >> Yes, I think it can come very handy if you want to add some >> cross-cutting concerns in the completion handlers but allow the end >> users to interact with the result via Future. >> >> For example, suppose I build a framework/library for others using the >> async channels (HTTP app, ssh app, etc.). I want to allow my users >> freedom to choose between the "pull" (future) and the "push" >> (completion handler). However, *regardless* of what my end user >> choose to interact with the result, I want to be able to inject some >> concerns like logging, instrumenting, etc. in the form of a >> completion handler (can be completely internal to the framework). >> >> With the current APIs, if the user wants a future, the framework >> cannot use the completion handler and I would need to find another >> way to inject such logic. Or if I want to retain the completion >> handler for the framework, then I would need to create my own future >> objects to provide to the end users. Either approach is doable, but >> it would be so much easier if the NIO.2 APIs provide both mechanisms >> in a single method call. My 2 cents. Thanks! > For high performance applications using completion handlers then we > don't want to future Future objects that won't be used. In your > framework/library then won't it return your own Future type anyway? > > -Alan. > > Hi, I encountered a similar need. The problem I wanted to solve was that I didn't want to have my main code thread wait (or block) for completion of the I/O operation only to start a follow up task. I created a class ? ?class CompletionFuture ? ?extends FutureTask ? ?implements CompletionHandler that does the trick. It's constructor takes a Callable as argument. The created object is a Future. The CompletionFuture's (or CompletionHandler's) completed(Integer, A) method essentially submits itself (in its role as FutureTask) to an ExecutionService. When this task is finished the get() method unblocks. The CompletionFuture's failed(Integer, A) method shortcuts the task by calling the setException(Throwable) method. Again, this unblocks get(), by throwing the exception. Alternatively, fail could also run the task using some instance field to indicate the failed condition. I can send a skeletal version of my code if desired. I am not sure that this functionality is sufficiently generic to be of general interest as it may need to be adopted to every specific application. For example, the task could be executed by the same thread as the CompletionHandler, by an ExecutionService other than the main thread, or the thread pool in which the main thread runs. Wolfgang. Une messagerie gratuite, garantie ? vie et des services en plus, ?a vous tente ? Je cr?e ma bo?te mail www.laposte.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110414/c483a0b5/attachment-0001.html From wolfgang.baltes at laposte.net Thu Apr 14 09:21:29 2011 From: wolfgang.baltes at laposte.net (wolfgang.baltes) Date: Thu, 14 Apr 2011 18:21:29 +0200 (CEST) Subject: why not both Future and CompletionHandler? Message-ID: <1908182.555522.1302798089311.JavaMail.www@wwinf8203> On 2011-04-14 08:38, Alan Bateman wrote: Sangjin Lee wrote: Yes, I think it can come very handy if you want to add some cross-cutting concerns in the completion handlers but allow the end users to interact with the result via Future. For example, suppose I build a framework/library for others using the async channels (HTTP app, ssh app, etc.). I want to allow my users freedom to choose between the "pull" (future) and the "push" (completion handler). However, *regardless* of what my end user choose to interact with the result, I want to be able to inject some concerns like logging, instrumenting, etc. in the form of a completion handler (can be completely internal to the framework). With the current APIs, if the user wants a future, the framework cannot use the completion handler and I would need to find another way to inject such logic. Or if I want to retain the completion handler for the framework, then I would need to create my own future objects to provide to the end users. Either approach is doable, but it would be so much easier if the NIO.2 APIs provide both mechanisms in a single method call. My 2 cents. Thanks! For high performance applications using completion handlers then we don't want to future Future objects that won't be used. In your framework/library then won't it return your own Future type anyway? -Alan. (This is a resend with subject filled in. Sorry, but I have email problems this morning.) Hi, I encountered a similar need. The problem I wanted to solve was that I didn't want to have my main code thread wait (or block) for completion of the I/O operation only to start a follow up task. I created a class ?? class CompletionFuture ?? extends FutureTask ?? implements CompletionHandler that does the trick. It's constructor takes a Callable as argument. The created object is a Future. The CompletionFuture's (or CompletionHandler's) completed(Integer, A) method essentially submits itself (in its role as FutureTask) to an ExecutionService. When this task is finished the get() method unblocks. The CompletionFuture's failed(Integer, A) method shortcuts the task by calling the setException(Throwable) method. Again, this unblocks get(), by throwing the exception. Alternatively, fail could also run the task using some instance field to indicate the failed condition. I can send a skeletal version of my code if desired. I am not sure that this functionality is sufficiently generic to be of general interest as it may need to be adopted to every specific application. For example, the task could be executed by the same thread as the CompletionHandler, by an ExecutionService other than the main thread, or the thread pool in which the main thread runs. Wolfgang. Une messagerie gratuite, garantie ? vie et des services en plus, ?a vous tente ? Je cr?e ma bo?te mail www.laposte.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110414/b1c52b90/attachment.html From forax at univ-mlv.fr Thu Apr 14 09:56:27 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Thu, 14 Apr 2011 18:56:27 +0200 Subject: why not both Future and CompletionHandler? In-Reply-To: <1908182.555522.1302798089311.JavaMail.www@wwinf8203> References: <1908182.555522.1302798089311.JavaMail.www@wwinf8203> Message-ID: <4DA7273B.6060307@univ-mlv.fr> On 04/14/2011 06:21 PM, wolfgang.baltes wrote: > > On 2011-04-14 08:38, Alan Bateman wrote: > > > Sangjin Lee wrote: > > Yes, I think it can come very handy if you want to add some > cross-cutting concerns in the completion handlers but allow > the end users to interact with the result via Future. > > For example, suppose I build a framework/library for others > using the async channels (HTTP app, ssh app, etc.). I want to > allow my users freedom to choose between the "pull" (future) > and the "push" (completion handler). However, *regardless* of > what my end user choose to interact with the result, I want to > be able to inject some concerns like logging, instrumenting, > etc. in the form of a completion handler (can be completely > internal to the framework). > > With the current APIs, if the user wants a future, the > framework cannot use the completion handler and I would need > to find another way to inject such logic. Or if I want to > retain the completion handler for the framework, then I would > need to create my own future objects to provide to the end > users. Either approach is doable, but it would be so much > easier if the NIO.2 APIs provide both mechanisms in a single > method call. My 2 cents. Thanks! > > For high performance applications using completion handlers then > we don't want to future Future objects that won't be used. In your > framework/library then won't it return your own Future type anyway? > > -Alan. > > (This is a resend with subject filled in. Sorry, but I have email > problems this morning.) > Hi, > > I encountered a similar need. The problem I wanted to solve was that I > didn't want to have my main code thread wait (or block) for completion > of the I/O operation only to start a follow up task. I created a class > > class CompletionFuture > extends FutureTask > implements CompletionHandler > > that does the trick. It's constructor takes a Callable as argument. > The created object is a Future. The CompletionFuture's (or > CompletionHandler's) completed(Integer, A) method essentially submits > itself (in its role as FutureTask) to an ExecutionService. When this > task is finished the get() method unblocks. The CompletionFuture's > failed(Integer, A) method shortcuts the task by calling the > setException(Throwable) method. Again, this unblocks get(), by > throwing the exception. Alternatively, fail could also run the task > using some instance field to indicate the failed condition. > > I can send a skeletal version of my code if desired. I am not sure > that this functionality is sufficiently generic to be of general > interest as it may need to be adopted to every specific application. > For example, the task could be executed by the same thread as the > CompletionHandler, by an ExecutionService other than the main thread, > or the thread pool in which the main thread runs. > > Wolfgang. How do you implement cancel ? R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110414/59f44e07/attachment.html From Alan.Bateman at oracle.com Thu Apr 14 10:01:25 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2011 18:01:25 +0100 Subject: why not both Future and CompletionHandler? In-Reply-To: <4DA71A54.2030408@univ-mlv.fr> References: <4DA70A8D.4020500@oracle.com> <4DA714EB.1000300@oracle.com> <4DA71A54.2030408@univ-mlv.fr> Message-ID: <4DA72865.8020102@oracle.com> R?mi Forax wrote: > > Or if I want to use a completion handler but have also a way to cancel > the operation. Yes, and that was noted at the time [1] but isn't really much of a concern because canceling specific I/O operations usually doesn't make sense (and just isn't feasible everywhere anyway). -Alan [1] http://bugs.sun.com/view_bug.do?bug_id=6842687 From martijnverburg at gmail.com Thu Apr 14 10:02:52 2011 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 14 Apr 2011 18:02:52 +0100 Subject: Overall feedback from several conferences on NIO.2 In-Reply-To: <4DA71487.10007@oracle.com> References: <4DA71487.10007@oracle.com> Message-ID: Hi Alan, The only slides I have in the public are fairly light on NIO.2 section (only 4/60 slides) as they were generic Java 7 talks. But I do have a version with a heavier NIO.2 focus (more like 10/60 slides) that I'll wave a creative commons wand over and release to slideshare sometime this weekend (got to be careful with those images!). I'll be happy for anyone to use those :) Cheers, Martijn On 14 April 2011 16:36, Alan Bateman wrote: > Martijn Verburg wrote: >> >> Hi all, >> >> Just wanted to quickly chime in with a positive bit of news. ?Ben >> Evans and I have been presenting on Java 7 at several conferences >> (TSSJS, DevNexus, SDC, JAX London + some others) and overwhelmingly >> the audiences have given the Asynch I/O changes the big thumbs up. >> They also really enjoyed the new helper methods in the Files class and >> I got a number of comments saying that "it certainly looked like >> NIO.2, got it right". >> >> Obviously concrete feedback would be better and hopefully you'll get >> some more developers reporting issues, but I thought I'd let you know >> about the general vibe anyhow :) >> >> Cheers, >> Martijn >> > > Good to hear that it is been well received and thanks for taking the time to > let us know. Are the slides that you have been using online somewhere? > > -Alan > From forax at univ-mlv.fr Thu Apr 14 10:09:07 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 14 Apr 2011 19:09:07 +0200 Subject: why not both Future and CompletionHandler? In-Reply-To: <4DA72865.8020102@oracle.com> References: <4DA70A8D.4020500@oracle.com> <4DA714EB.1000300@oracle.com> <4DA71A54.2030408@univ-mlv.fr> <4DA72865.8020102@oracle.com> Message-ID: <4DA72A33.2070801@univ-mlv.fr> On 04/14/2011 07:01 PM, Alan Bateman wrote: > R?mi Forax wrote: >> >> Or if I want to use a completion handler but have also a way to >> cancel the operation. > Yes, and that was noted at the time [1] but isn't really much of a > concern because canceling specific I/O operations usually doesn't make > sense (and just isn't feasible everywhere anyway). > > -Alan > > [1] http://bugs.sun.com/view_bug.do?bug_id=6842687 So in that case, the idea of Wolfgang of CompletionFuture seems the good one and methods that returns a Future aren't needed anymore. R?mi From forax at univ-mlv.fr Thu Apr 14 10:43:36 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 14 Apr 2011 19:43:36 +0200 Subject: Tackle verbosity and static import Message-ID: <4DA73248.5070003@univ-mlv.fr> Playing a little bit with NIO file API, I come with this snippet for printing all lines of a file. public static void main(String[] args) throws IOException { for(String line: readAllLines(get("foo.txt"), defaultCharset())) { System.out.println(line); } } The trick is to abuse of static import, the whole file is: import static java.nio.file.Files.*; import static java.nio.file.Paths.*; import static java.nio.charset.Charset.*; import java.io.IOException; public class LessVerbosity { public static void main(String[] args) throws IOException { for(String line: readAllLines(get("foo.txt"), defaultCharset())) { System.out.println(line); } } } In my opinion, it shows that Paths.get should be renamed to Paths.getPath() to be meaningful if used with static import. Also, it should be cool to have an overload version of Files.readAllLines that doesn't require a charset and use the default charset. R?mi From wolfgang_baltes at hotmail.com Thu Apr 14 10:53:36 2011 From: wolfgang_baltes at hotmail.com (Wolfgang Baltes) Date: Thu, 14 Apr 2011 10:53:36 -0700 Subject: why not both Future and CompletionHandler? In-Reply-To: <4DA730C1.80808@hotmail.com> References: <1908182.555522.1302798089311.JavaMail.www@wwinf8203> <4DA7273B.6060307@univ-mlv.fr> <4DA730C1.80808@hotmail.com> Message-ID: On 2011-04-14 10:37, Wolfgang Baltes wrote: > > > On 2011-04-14 09:56, R?mi Forax wrote: >> On 04/14/2011 06:21 PM, wolfgang.baltes wrote: >>> >>> On 2011-04-14 08:38, Alan Bateman wrote: >>> >>> >>> Sangjin Lee wrote: >>> >>> Yes, I think it can come very handy if you want to add some >>> cross-cutting concerns in the completion handlers but allow >>> the end users to interact with the result via Future. >>> >>> For example, suppose I build a framework/library for others >>> using the async channels (HTTP app, ssh app, etc.). I want >>> to allow my users freedom to choose between the "pull" >>> (future) and the "push" (completion handler). However, >>> *regardless* of what my end user choose to interact with the >>> result, I want to be able to inject some concerns like >>> logging, instrumenting, etc. in the form of a completion >>> handler (can be completely internal to the framework). >>> >>> With the current APIs, if the user wants a future, the >>> framework cannot use the completion handler and I would need >>> to find another way to inject such logic. Or if I want to >>> retain the completion handler for the framework, then I >>> would need to create my own future objects to provide to the >>> end users. Either approach is doable, but it would be so >>> much easier if the NIO.2 APIs provide both mechanisms in a >>> single method call. My 2 cents. Thanks! >>> >>> For high performance applications using completion handlers then >>> we don't want to future Future objects that won't be used. In >>> your framework/library then won't it return your own Future type >>> anyway? >>> >>> -Alan. >>> >>> (This is a resend with subject filled in. Sorry, but I have email >>> problems this morning.) >>> Hi, >>> >>> I encountered a similar need. The problem I wanted to solve was that >>> I didn't want to have my main code thread wait (or block) for >>> completion of the I/O operation only to start a follow up task. I >>> created a class >>> >>> class CompletionFuture >>> extends FutureTask >>> implements CompletionHandler >>> >>> that does the trick. It's constructor takes a Callable as >>> argument. The created object is a Future. The CompletionFuture's >>> (or CompletionHandler's) completed(Integer, A) method essentially >>> submits itself (in its role as FutureTask) to an ExecutionService. >>> When this task is finished the get() method unblocks. The >>> CompletionFuture's failed(Integer, A) method shortcuts the task by >>> calling the setException(Throwable) method. Again, this unblocks >>> get(), by throwing the exception. Alternatively, fail could also run >>> the task using some instance field to indicate the failed condition. >>> >>> I can send a skeletal version of my code if desired. I am not sure >>> that this functionality is sufficiently generic to be of general >>> interest as it may need to be adopted to every specific application. >>> For example, the task could be executed by the same thread as the >>> CompletionHandler, by an ExecutionService other than the main >>> thread, or the thread pool in which the main thread runs. >>> >>> Wolfgang. >> >> How do you implement cancel ? >> >> R?mi >> > R?mi, > > I don't/can't cancel the I/O operation, but I can the following task. > So far I used this only for file I/O operations, and didn't see the > need for cancellation. Again, I don't want to say that my solution is > of too board an appeal, but it may fit certain needs. > > Wolfgang. R?mi, As an addition to my previous reply: I didn't find clear semantics on how to cancel an I/O operation; that is, I couldn't find a clear explanation of what cancel() on a Future returned by an I/O operation would actually do. Alan's memo seems to indicate that it may not do much. On the other side, the CompletionFuture I described allows cancellation of the task (i.e., the argument to the constructor). Wolfgang. From Alan.Bateman at oracle.com Thu Apr 14 11:14:24 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2011 19:14:24 +0100 Subject: why not both Future and CompletionHandler? In-Reply-To: References: <1908182.555522.1302798089311.JavaMail.www@wwinf8203> <4DA7273B.6060307@univ-mlv.fr> <4DA730C1.80808@hotmail.com> Message-ID: <4DA73980.4000306@oracle.com> Wolfgang Baltes wrote: > > R?mi, > > As an addition to my previous reply: I didn't find clear semantics on > how to cancel an I/O operation; that is, I couldn't find a clear > explanation of what cancel() on a Future returned by an I/O operation > would actually do. Alan's memo seems to indicate that it may not do much. > > On the other side, the CompletionFuture I described allows > cancellation of the task (i.e., the argument to the constructor). I/O and cancellation is a very awkward topic. We have a couple of paragraphs in the AsynchronousChannel description to set expectations that it may not be possible to cancel the underlying I/O operation and to also explain that when mayInterruptIfRunning is true, it is allowed to close the channel. -Alan. From Alan.Bateman at oracle.com Thu Apr 14 11:18:13 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2011 19:18:13 +0100 Subject: Tackle verbosity and static import In-Reply-To: <4DA73248.5070003@univ-mlv.fr> References: <4DA73248.5070003@univ-mlv.fr> Message-ID: <4DA73A65.7070409@oracle.com> R?mi Forax wrote: > Playing a little bit with NIO file API, I come with this snippet for > printing > all lines of a file. > > public static void main(String[] args) throws IOException { > for(String line: readAllLines(get("foo.txt"), defaultCharset())) { > System.out.println(line); > } > } > > The trick is to abuse of static import, the whole file is: > > import static java.nio.file.Files.*; > import static java.nio.file.Paths.*; > import static java.nio.charset.Charset.*; > > import java.io.IOException; > > public class LessVerbosity { > public static void main(String[] args) throws IOException { > for(String line: readAllLines(get("foo.txt"), defaultCharset())) { > System.out.println(line); > } > } > } > > In my opinion, it shows that Paths.get should be renamed to > Paths.getPath() > to be meaningful if used with static import. > > Also, it should be cool to have an overload version of Files.readAllLines > that doesn't require a charset and use the default charset. > > R?mi > Yes, definitely pushing static import a bit too far :-) The Files class is well suited for static import but the Paths class isn't. I don't think Paths.get is too bad but in any case, it's probably too late now to consider renaming these methods. On the charset, did you see Mike Duigou's proposal on core-libs-dev to define a class with constants for the standard charsets? That should work well with readAllLines and several other methods, eg: readAllLines(path, UTF_8); -Alan. From Alan.Bateman at oracle.com Thu Apr 14 11:28:33 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2011 19:28:33 +0100 Subject: why not both Future and CompletionHandler? In-Reply-To: <4DA72A33.2070801@univ-mlv.fr> References: <4DA70A8D.4020500@oracle.com> <4DA714EB.1000300@oracle.com> <4DA71A54.2030408@univ-mlv.fr> <4DA72865.8020102@oracle.com> <4DA72A33.2070801@univ-mlv.fr> Message-ID: <4DA73CD1.7040308@oracle.com> R?mi Forax wrote: > > So in that case, the idea of Wolfgang of CompletionFuture seems the > good one > and methods that returns a Future aren't needed anymore. His solution looks reasonable. Implementation wise we can of course mostly implement the Future-style based on completion handlers. -Alan From jitendra.kotamraju at oracle.com Fri Apr 15 13:19:15 2011 From: jitendra.kotamraju at oracle.com (Jitendra Kotamraju) Date: Fri, 15 Apr 2011 13:19:15 -0700 Subject: why not both Future and CompletionHandler? Message-ID: <4DA8A843.9030706@oracle.com> There is also similar API ListenableFuture [1] in Guava libraries. I haven't seen the CompletionFuture, but I guess it can be subtype of ListenableFuture. Regardless of NIO2, it would be good have this API in SE and it will be quite useful to JAX-RS/JAX-WS API. Jitu [1]http://guava-libraries.googlecode.com/svn-history/r224/trunk/javadoc/com/google/common/util/concurrent/ListenableFuture.html From wolfgang.baltes at laposte.net Fri Apr 15 15:34:39 2011 From: wolfgang.baltes at laposte.net (Wolfgang Baltes) Date: Fri, 15 Apr 2011 15:34:39 -0700 Subject: why not both Future and CompletionHandler? In-Reply-To: <4DA8A843.9030706@oracle.com> References: <4DA8A843.9030706@oracle.com> Message-ID: <4DA8C7FF.6020202@laposte.net> On 2011-04-15 13:19, Jitendra Kotamraju wrote: > > There is also similar API ListenableFuture [1] in Guava libraries. I > haven't seen the CompletionFuture, but I guess it can be subtype of > ListenableFuture. Regardless of NIO2, it would be good have this API > in SE and it will be quite useful to JAX-RS/JAX-WS API. > > Jitu > [1]http://guava-libraries.googlecode.com/svn-history/r224/trunk/javadoc/com/google/common/util/concurrent/ListenableFuture.html > > > Thanks for pointing this out. ListenableFuture is certainly of interest in this context. However, there is at least one significant difference: CompletionFuture chains a Future behind a CompletionHandler, whereas ListenableFuture chains Futures. At this time, CompletionFuture is used to launch only one Future, but this could easily be changed. I am not sure CompletionFuture should be in the SE API; I think it is more a pattern with many implementation options and variations due to the coupling (see below how the Throwable is forwarded). ListenableFuture is more generic and probably fits as an API. This is because there is no coupling between the Future and the listeners. Here is some code that indicates how CompletionFuture works. public class CompletionFuture extends FutureTask implements CompletionHandler { final private ExecutorService exec; public CompletionFuture(Callable task, ExecutorService exec) { super(task); this.exec = exec; } @Override public void completed(V result, A attachment) { // Do something with result and/or attachment. // Chain the task. this.exec.execute(this); } @Override public void failed(Throwable t, A attachment) { // Shortcut the task and send t instead. this.setException(t); } } simplified example calling code: Callable task = new Callable() { @Override public FV call() throws Exception { // insert code here } }; CompletionFuture cf = new CompletionFuture(task, exec); AsynchronousFileChannel asf = new AsynchronousFileChannel(); asf.open(...); ByteBuffer bb = ByteBuffer.allocateDirect(capacity); asf.read(bb, position, null, cf); FV result = cf.get(); Wolfgang. From martijnverburg at gmail.com Tue Apr 19 04:16:59 2011 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 19 Apr 2011 12:16:59 +0100 Subject: Overall feedback from several conferences on NIO.2 In-Reply-To: References: <4DA71487.10007@oracle.com> Message-ID: Hi all, The slides are now hosted at: http://www.slideshare.net/martijnverburg/back-to-thefuturewithjava-7v0-6nio2 The code/details may be slightly out of date as they were based off b133 or so (IIRC) The slides themselves are perhaps not that useful without the presenter explaining things further, but hopefully they're of some use to somebody out there. Thanks, Martijn On 14 April 2011 18:02, Martijn Verburg wrote: > Hi Alan, > > The only slides I have in the public are fairly light on NIO.2 section > (only 4/60 slides) as they were generic Java 7 talks. But I do have a > version with a heavier NIO.2 focus (more like 10/60 slides) that I'll > wave a creative commons wand over and release to slideshare sometime > this weekend (got to be careful with those images!). > > I'll be happy for anyone to use those :) > > Cheers, > Martijn > > On 14 April 2011 16:36, Alan Bateman wrote: >> Martijn Verburg wrote: >>> >>> Hi all, >>> >>> Just wanted to quickly chime in with a positive bit of news. ?Ben >>> Evans and I have been presenting on Java 7 at several conferences >>> (TSSJS, DevNexus, SDC, JAX London + some others) and overwhelmingly >>> the audiences have given the Asynch I/O changes the big thumbs up. >>> They also really enjoyed the new helper methods in the Files class and >>> I got a number of comments saying that "it certainly looked like >>> NIO.2, got it right". >>> >>> Obviously concrete feedback would be better and hopefully you'll get >>> some more developers reporting issues, but I thought I'd let you know >>> about the general vibe anyhow :) >>> >>> Cheers, >>> Martijn >>> >> >> Good to hear that it is been well received and thanks for taking the time to >> let us know. Are the slides that you have been using online somewhere? >> >> -Alan >> > From Alan.Bateman at oracle.com Wed Apr 27 03:08:27 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Apr 2011 11:08:27 +0100 Subject: 7039186: (ch) EPoll based asynchronous I/O implementation should be portable to linux-arm and linux-ppc Message-ID: <4DB7EB1B.1040604@oracle.com> The Linux/epoll implementation of the AsynchronousChannelProvider has its own definition of the epoll_event structure - this stems from early in jdk7 when we were still required to build on 2.4 based distributions. The definition of epoll_event isn't right for non-x86 platforms and means all tests for this API are failing on linux-arm and linux-ppc (our embedded team port to these architectures). The simplest solution is to just get rid of this definition and include epoll.h (which we should have done ages ago). While we're at it, we can also change the inotify code to include inotify.h. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7039186/webrev/ Thanks, Alan. From mik3hall at gmail.com Thu Apr 28 03:11:10 2011 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 28 Apr 2011 05:11:10 -0500 Subject: FileSystemProvider delegation Message-ID: <00CFA8F0-95B7-4BC9-8B04-737148874E5C@gmail.com> I have a 'file' default FileSystemProvider that I am trying in some instances to have delegate to the normal platform FileSystemProvider. In the getPath(String first, String more) method for the custom FileSystem method if it decides to delegate back it currently does this... In TrueZipFileSystem.java (extends FileSystem) getPath(String first, String... more) ... return new PathDelegate(((TrueZipFileSystemProvider)provider).getPriorProvider().getPath(pathURI)); Where PathDelegate is a wrapper for the platform instance Path that provides some convenience methods. These are pretty much the convenience methods that the zip demo assumes it's Path class to provide. However, if I try to use this returned platform Path wrapper instance like this... Path absdirfile = Paths.get("/Users"); System.out.println("Paths absolute dir " + absdirfile + " class " + absdirfile.getClass().getName()); System.out.println(absdirfile + " is directory " + Files.isDirectory(absdirfile)); It gets... Paths absolute dir org.truezip.PathDelegate at cb5de2 class org.truezip.PathDelegate Exception in thread "main" java.nio.file.ProviderMismatchException at sun.nio.fs.UnixPath.toUnixPath(UnixPath.java:200) at sun.nio.fs.UnixFileSystemProvider.getFileAttributeView(UnixFileSystemProvider.java:128) at sun.nio.fs.BsdFileSystemProvider.getFileAttributeView(BsdFileSystemProvider.java:57) at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:157) at sun.nio.fs.BsdFileSystemProvider.readAttributes(BsdFileSystemProvider.java:80) at java.nio.file.Files.readAttributes(Files.java:1669) at java.nio.file.Files.isDirectory(Files.java:2118) at BasicSetupTester.main(BasicSetupTester.java:13) Per the javadoc for ProviderMismatchException Unchecked exception thrown when an attempt is made to invoke a method on an object created by one file system provider with a parameter created by a different file system provider. So the wrapper class can't be used? It's the only parm. If the platform instance will only work with one FileSystem and Path that are also platform type, it makes delegation back to it from other providers more difficult, doesn't it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110428/143e9309/attachment.html From Alan.Bateman at oracle.com Thu Apr 28 03:38:38 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Apr 2011 11:38:38 +0100 Subject: FileSystemProvider delegation In-Reply-To: <00CFA8F0-95B7-4BC9-8B04-737148874E5C@gmail.com> References: <00CFA8F0-95B7-4BC9-8B04-737148874E5C@gmail.com> Message-ID: <4DB943AE.3040608@oracle.com> Michael Hall wrote: > I have a 'file' default FileSystemProvider that I am trying in some > instances to have delegate to the normal platform FileSystemProvider. > In the getPath(String first, String more) method for the custom > FileSystem method if it decides to delegate back it currently does this... > > In TrueZipFileSystem.java (extends FileSystem) > getPath(String first, String... more) > ... > return new > PathDelegate(((TrueZipFileSystemProvider)provider).getPriorProvider().getPath(pathURI)); > > Where PathDelegate is a wrapper for the platform instance Path that > provides some convenience methods. These are pretty much the > convenience methods that the zip demo assumes it's Path class to provide. > > However, if I try to use this returned platform Path wrapper instance > like this... > > Path absdirfile = Paths.get("/Users"); > System.out.println("Paths absolute dir " + absdirfile + " class " + > absdirfile.getClass().getName()); > System.out.println(absdirfile + " is directory " + > Files.isDirectory(absdirfile)); > > It gets... > > Paths absolute dir org.truezip.PathDelegate at cb5de2 class > org.truezip.PathDelegate > Exception in thread "main" java.nio.file.ProviderMismatchException > at sun.nio.fs.UnixPath.toUnixPath(UnixPath.java:200) > at > sun.nio.fs.UnixFileSystemProvider.getFileAttributeView(UnixFileSystemProvider.java:128) > at > sun.nio.fs.BsdFileSystemProvider.getFileAttributeView(BsdFileSystemProvider.java:57) > at > sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:157) > at > sun.nio.fs.BsdFileSystemProvider.readAttributes(BsdFileSystemProvider.java:80) > at java.nio.file.Files.readAttributes(Files.java:1669) > at java.nio.file.Files.isDirectory(Files.java:2118) > at BasicSetupTester.main(BasicSetupTester.java:13) > > Per the javadoc for ProviderMismatchException > Unchecked exception thrown when an attempt is made to invoke a method > on an object created by one file system provider with a parameter > created by a different file system provider. > > So the wrapper class can't be used? It's the only parm. If the > platform instance will only work with one FileSystem and Path that are > also platform type, it makes delegation back to it from other > providers more difficult, doesn't it? > What does org.truezip.PathDelegate.getFileSystem().provider() return? From the stack trace it looks like it is running sun.nio.fs.BsdFileSystemProvider whereas it should be returning your file system provider. If it helps, our test cases have a "pass through" file system that might be useful to you: http://hg.openjdk.java.net/jdk7/jdk7/jdk/raw-file/tip/test/java/nio/file/Files/PassThroughFileSystem.java -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110428/b4ba14dd/attachment.html From mik3hall at gmail.com Thu Apr 28 13:55:28 2011 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 28 Apr 2011 15:55:28 -0500 Subject: FileSystemProvider delegation In-Reply-To: <4DB943AE.3040608@oracle.com> References: <00CFA8F0-95B7-4BC9-8B04-737148874E5C@gmail.com> <4DB943AE.3040608@oracle.com> Message-ID: On Apr 28, 2011, at 5:38 AM, Alan Bateman wrote: > What does org.truezip.PathDelegate.getFileSystem().provider() return? From the stack trace it looks like it is running sun.nio.fs.BsdFileSystemProvider whereas it should be returning your file system provider. PathDelegate is supposed to actually be an instance whose provider is the platform one, Bsd in this case. Delegated back to when I decide the file isn't an archival one I want to handle differently. It goes.... pubilc abstract class AbstractPath { // Defines helper methods as per zip demo } public class PathDelegate extends AbstractPath implements Path { Path path; // Instance of platform, Bsd in this case, Path // methods do their invocations on the above path instance. // The 'helper' or convenience methods inherited from AbstractPath are what keeps this from itself being a straight pass through } What actually shows as the provider for this class may be the problem though, that it is actually not the Bsd one. I will look into that. > > If it helps, our test cases have a "pass through" file system that might be useful to you: > http://hg.openjdk.java.net/jdk7/jdk7/jdk/raw-file/tip/test/java/nio/file/Files/PassThroughFileSystem.java Should of known that. I did one of these myself just to make sure that the so far basic testing I have now would run correctly. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110428/55a58bb2/attachment.html From Alan.Bateman at oracle.com Thu Apr 28 14:06:03 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Apr 2011 22:06:03 +0100 Subject: FileSystemProvider delegation In-Reply-To: References: <00CFA8F0-95B7-4BC9-8B04-737148874E5C@gmail.com> <4DB943AE.3040608@oracle.com> Message-ID: <4DB9D6BB.9070602@oracle.com> Michael Hall wrote: > > > What actually shows as the provider for this class may be the problem > though, that it is actually not the Bsd one. I will look into that. Yes, I would suggest double checking that as you don't want any references to instances from the underlying provider escaping out. If they do escape out then ProviderMismatchException is the likely result. -Alan.