From avinash.lakshman at gmail.com Sun Oct 4 00:30:59 2009 From: avinash.lakshman at gmail.com (Avinash Lakshman) Date: Sun, 4 Oct 2009 00:30:59 -0700 Subject: Glibc version Message-ID: Looks like the new installation depends on GLBC version 2.4. Is there any place where I can find the latest download which is compatible with GLIBC version 2.3? Thanks A -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20091004/5f368870/attachment.html From Alan.Bateman at Sun.COM Sun Oct 4 00:44:01 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 04 Oct 2009 08:44:01 +0100 Subject: Glibc version In-Reply-To: References: Message-ID: <4AC85241.9090805@sun.com> Avinash Lakshman wrote: > Looks like the new installation depends on GLBC version 2.4. Is there > any place where I can find the latest download which is compatible > with GLIBC version 2.3? > > Thanks > A Which build are you using? The only dependency in the nio code on glibc 2.4 was removed a few months ago (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6864319). Martin - have you seen any issues in recent builds? -Alan From Alan.Bateman at Sun.COM Sun Oct 4 07:35:54 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 04 Oct 2009 15:35:54 +0100 Subject: Glibc version In-Reply-To: References: <4AC85241.9090805@sun.com> Message-ID: <4AC8B2CA.7050505@sun.com> Avinash Lakshman wrote: > Actually I just downloaded the binary install for 64 bit Linux. The > installer fails since I do not have GLBC versiion 2.4. > > A Is this the self extracting .bin file from the download page [1]? This is a script that unpacks install.sfx that installs it into $PWD/jdk1.7.0. Is is there that it is failing? (sorry I can't verify it because I can't find a system with glibc 2.3). Xiomara - do you know if the installer build changed recently? I remember the JDK switched to Fedora 9 about 6 months ago but Avinash seems to be suggesting that the installation is failing on older systems with the "latest build". -Alan. [1] http://download.java.net/jdk7/binaries/ From martinrb at google.com Sun Oct 4 11:14:42 2009 From: martinrb at google.com (Martin Buchholz) Date: Sun, 4 Oct 2009 11:14:42 -0700 Subject: Glibc version In-Reply-To: <4AC85241.9090805@sun.com> References: <4AC85241.9090805@sun.com> Message-ID: <1ccfd1c10910041114i796d48e2w34cc14f9ca0f85a9@mail.gmail.com> Recent builds of openjdk 7 succeed on Ubuntu dapper, which is based on glibc 2.3.6. The only very recent change was a new dependency on the ant-optional package in b73. It's a tough call as to whether Sun's officially supported binary builds should support glibc 2.3.6 or not. I have been advocating that, since I love portability, and features from later glibcs can be detected and used at runtime, which means no downside for users. Martin On Sun, Oct 4, 2009 at 00:44, Alan Bateman wrote: > Avinash Lakshman wrote: >> >> Looks like the new installation depends on GLBC version 2.4. Is there any >> place where I can find the latest download which is compatible with GLIBC >> version 2.3? >> >> Thanks >> A > > Which build are you using? The only dependency in the nio code on glibc 2.4 > was removed a few months ago (see > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6864319). > > Martin - have you seen any issues in recent builds? > > -Alan > > From Alan.Bateman at Sun.COM Mon Oct 5 01:14:18 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 05 Oct 2009 09:14:18 +0100 Subject: Glibc version In-Reply-To: <1ccfd1c10910041114i796d48e2w34cc14f9ca0f85a9@mail.gmail.com> References: <4AC85241.9090805@sun.com> <1ccfd1c10910041114i796d48e2w34cc14f9ca0f85a9@mail.gmail.com> Message-ID: <4AC9AADA.5020609@sun.com> Martin Buchholz wrote: > Recent builds of openjdk 7 succeed on Ubuntu dapper, > which is based on glibc 2.3.6. > > The only very recent change was a new dependency on > the ant-optional package in b73. > > It's a tough call as to whether Sun's officially supported > binary builds should support glibc 2.3.6 or not. > I have been advocating that, since I love portability, and > features from later glibcs can be detected and used at > runtime, which means no downside for users. > > Martin > Thanks Martin. I think Avinash is using the binary releases and isn't building from source (but building from source is probably the only solution for this case). -Alan. From Xiomara.Jayasena at Sun.COM Mon Oct 5 08:48:41 2009 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Mon, 05 Oct 2009 08:48:41 -0700 Subject: Glibc version In-Reply-To: <4AC8B2CA.7050505@sun.com> References: <4AC85241.9090805@sun.com> <4AC8B2CA.7050505@sun.com> Message-ID: <4ACA1559.2020009@sun.com> Alan Bateman wrote: > Avinash Lakshman wrote: >> Actually I just downloaded the binary install for 64 bit Linux. The >> installer fails since I do not have GLBC versiion 2.4. >> >> A > Is this the self extracting .bin file from the download page [1]? This > is a script that unpacks install.sfx that installs it into > $PWD/jdk1.7.0. Is is there that it is failing? (sorry I can't verify > it because I can't find a system with glibc 2.3). > > Xiomara - do you know if the installer build changed recently? I > remember the JDK switched to Fedora 9 about 6 months ago but Avinash > seems to be suggesting that the installation is failing on older > systems with the "latest build". Since the upgrade to Fedora 9 having glibc 2.4 is a requirement. I don't think there have been any changes in that area since the Fedora9 upgrade, I am copying Kelly in case he knows of anything I may have missed. -Xiomara > > -Alan. > > [1] http://download.java.net/jdk7/binaries/ From Kelly.Ohair at Sun.COM Mon Oct 5 10:04:08 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 05 Oct 2009 10:04:08 -0700 Subject: Glibc version In-Reply-To: <4ACA1559.2020009@sun.com> References: <4AC85241.9090805@sun.com> <4AC8B2CA.7050505@sun.com> <4ACA1559.2020009@sun.com> Message-ID: <4ACA2708.5060503@sun.com> The key issue here is that jdk7 is no longer supported on many of the older Linux releases, although someone might be able to build OpenJDK's on older Linux systems, we now use Fedora 9 for all our JDK7 builds. Changing to Fedora 9 as our build platform, means that the installer bundles may not install on older Linux systems, which some may view as a good thing. I don't know of any additional or recent changes to the bundling that might impact Linux. -kto Xiomara Jayasena wrote: > Alan Bateman wrote: >> Avinash Lakshman wrote: >>> Actually I just downloaded the binary install for 64 bit Linux. The >>> installer fails since I do not have GLBC versiion 2.4. >>> >>> A >> Is this the self extracting .bin file from the download page [1]? This >> is a script that unpacks install.sfx that installs it into >> $PWD/jdk1.7.0. Is is there that it is failing? (sorry I can't verify >> it because I can't find a system with glibc 2.3). >> >> Xiomara - do you know if the installer build changed recently? I >> remember the JDK switched to Fedora 9 about 6 months ago but Avinash >> seems to be suggesting that the installation is failing on older >> systems with the "latest build". > Since the upgrade to Fedora 9 having glibc 2.4 is a requirement. > > I don't think there have been any changes in that area since the Fedora9 > upgrade, I am copying Kelly in case he knows of anything I may have missed. > > -Xiomara > >> >> -Alan. >> >> [1] http://download.java.net/jdk7/binaries/ > From Ulf.Zibis at gmx.de Tue Oct 6 05:00:30 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 06 Oct 2009 14:00:30 +0200 Subject: Missing delete path facility Message-ID: <4ACB315E.8040605@gmx.de> Hi all, in the new nio API there is Path#delete(). It only allows to delete a single file or directory if empty. If developer wants to delete a complete subtree of a path, he has to programmatically iterate over all its elements. Please add functionality to save developers from hand-coding those iterations. On http://java.sun.com/docs/books/tutorial/essential/io/legacy.html in "Mapping java.io.File Functionality to java.nio.file"-table I find: |File.delete| --> |Path.delete| or |Path.delete(boolean) |But there is no expression for delete(boolean) in current implementation of Path. -Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20091006/b6542b5d/attachment.html From Alan.Bateman at Sun.COM Tue Oct 6 05:18:55 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 06 Oct 2009 13:18:55 +0100 Subject: Missing delete path facility In-Reply-To: <4ACB315E.8040605@gmx.de> References: <4ACB315E.8040605@gmx.de> Message-ID: <4ACB35AF.6010600@sun.com> Ulf Zibis wrote: > Hi all, > > in the new nio API there is Path#delete(). It only allows to delete a > single file or directory if empty. > If developer wants to delete a complete subtree of a path, he has to > programmatically iterate over all its elements. > > Please add functionality to save developers from hand-coding those > iterations. This has come up a few times and is a good candidate to add to the Files utility class. Like all composite operations, the question arises as to what to an operation fails. If you are writing a command-line tool (like rm -r) then you would emit a warning message and continue. Other approaches are to terminate, or to continue and return a collection of the files that could not be deleted (and the reason). But point taken that developers shouldn't have to re-invent this. In the mean-time, it's actually not that hard and there is a skeleton example in FileVisitor's javadoc. > > On http://java.sun.com/docs/books/tutorial/essential/io/legacy.html in > "Mapping java.io.File Functionality to java.nio.file"-table I find: > |File.delete| --> |Path.delete| or |Path.delete(boolean) > > |But there is no expression for delete(boolean) in current > implementation of Path. Thanks. I think Sharon Zakhour (the tech writer that developed this tutorial) has already fixed this one and a couple of other issues. They just aren't pushed to java.sun.com yet. -Alan. From Alan.Bateman at Sun.COM Mon Oct 12 06:43:37 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 12 Oct 2009 14:43:37 +0100 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD3290E.2010507@gmx.de> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> Message-ID: <4AD33289.3000600@sun.com> Ulf Zibis wrote: > : > Anyway, I would like to see zip/jar URIs as valid parameter to open a > file/path/stream/channel via new File(URI) or Paths.get(URI). There is a file system provider (albeit demo/prototype quality) for zip file in the nio repository. Just add ZipFileSystem.jar to your classpath and you can treat the contents of a zip or JAR file as a read-only file system. You can use URIs, such as zip:///home/foo.zip#/top/bar, to locate files if you wish. -Alan. From Alan.Bateman at Sun.COM Mon Oct 12 07:26:44 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 12 Oct 2009 15:26:44 +0100 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD3375C.9030400@gmx.de> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> <4AD3375C.9030400@gmx.de> Message-ID: <4AD33CA4.5020608@sun.com> Ulf Zibis wrote: > Am 12.10.2009 15:03, Ulf Zibis schrieb: >> Additionally something like Path#unlock() would be helpful, if >> copy/delete fails. For example see: >> http://diamondcs.com.au/freeutilities/fileunlocker.php > > Additionally see: http://ccollomb.free.fr/unlocker/ I assume this type of thing can lead to data loss and/or hard to diagnose corruption. If you are running into sharing violations then try out the file system API as the Windows provider opens files by default to allow delete access (ie: close to Unix semantics by default with provider specific options to control the DOS sharing mode if you really want). The only case where we still have a problem is memory-mapped files. Changing the long standing behavior of the java.io classes is another matter as that would likely break existing applications that rely on the current/long standing behavior. -Alan. From Ulf.Zibis at gmx.de Mon Oct 12 07:23:55 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Oct 2009 16:23:55 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD33289.3000600@sun.com> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> <4AD33289.3000600@sun.com> Message-ID: <4AD33BFB.3040201@gmx.de> Am 12.10.2009 15:43, Alan Bateman schrieb: > Ulf Zibis wrote: >> : >> Anyway, I would like to see zip/jar URIs as valid parameter to open a >> file/path/stream/channel via new File(URI) or Paths.get(URI). > There is a file system provider (albeit demo/prototype quality) for > zip file in the nio repository. Just add ZipFileSystem.jar to your > classpath and you can treat the contents of a zip or JAR file as a > read-only file system. You can use URIs, such as > zip:///home/foo.zip#/top/bar, to locate files if you wish. > Alan, that's cool, thanks. Hopefully this goes into trunk of JDK 7, (+ write access ?). Can you give me direct link of ZipFileSystem.jar + javadoc + sources ? If I run this example: System.out.println( sun.nio.cs.ext.SJIS_0213.class.getResource("sjis0213.dat").toURI()); I get: jar:file:/C:/Programme/Java/jdk1.7.0/fastdebug/jre/lib/charsets.jar!/sun/nio/cs/ext/sjis0213.dat This looks little different from your example (scheme + '!' instead '#'). Is that covered too by ZipFileSystem.jar ? -Ulf From Ulf.Zibis at gmx.de Mon Oct 12 06:03:10 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Oct 2009 15:03:10 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AB10D85.8040402@sun.com> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> Message-ID: <4AD3290E.2010507@gmx.de> Am 16.09.2009 18:08, Alan Bateman schrieb: > Joel Kamentz wrote: > >> : >> >> Attempt to convert an URL to a local file, taking into >> account that it might be wrappered by jar:, that File.toURL doesn't >> process %20 and the like, etc. >> > File.toURL is deprecated. You might want to look at File.toURI. Anyway, I would like to see zip/jar URIs as valid parameter to open a file/path/stream/channel via new File(URI) or Paths.get(URI). > > >> Delete files or sub-trees, catching exceptions and instead >> just return success / failure. >> > This one comes up a lot and has been addressed in the file system API > work in jdk7. So if you have a File f you can replace f.delete() with > f.toPath().delete() and it will do what you want. > > Recursive delete is relatively easy too, using Files.walkFileTree. > There's an example in the javadoc that does this (look in > java.nio.file.FileVisitor). I would like to see some convenience methods for deleting/copying subtrees, without having to implement the FileVisitor examples. Additionally something like Path#unlock() would be helpful, if copy/delete fails. For example see: http://diamondcs.com.au/freeutilities/fileunlocker.php -Ulf From Alan.Bateman at Sun.COM Mon Oct 12 08:40:44 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 12 Oct 2009 16:40:44 +0100 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD33BFB.3040201@gmx.de> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> <4AD33289.3000600@sun.com> <4AD33BFB.3040201@gmx.de> Message-ID: <4AD34DFC.3040506@sun.com> Ulf Zibis wrote: > : > Alan, that's cool, thanks. Hopefully this goes into trunk of JDK 7, (+ > write access ?). > Can you give me direct link of ZipFileSystem.jar + javadoc + sources ? Just clone the nio/nio repository. There's a README in jdk/src/share/demo/nio/ZipFileSystem. > > If I run this example: > System.out.println( > > sun.nio.cs.ext.SJIS_0213.class.getResource("sjis0213.dat").toURI()); > I get: > jar:file:/C:/Programme/Java/jdk1.7.0/fastdebug/jre/lib/charsets.jar!/sun/nio/cs/ext/sjis0213.dat > > > This looks little different from your example (scheme + '!' instead '#'). > Is that covered too by ZipFileSystem.jar ? The URI syntax is defined by the provider and this demo provider uses hierarchical URIs with "zip" as the scheme. It wouldn't hard to wrap this provider with another that supports the legacy JAR URL syntax (although that syntax worries me in that it uses opaque URIs and will likely be a challenge if/when the platform is updated to support RFC 3986). -Alan. From Ulf.Zibis at gmx.de Mon Oct 12 07:04:12 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Oct 2009 16:04:12 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD3290E.2010507@gmx.de> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> Message-ID: <4AD3375C.9030400@gmx.de> Am 12.10.2009 15:03, Ulf Zibis schrieb: > Additionally something like Path#unlock() would be helpful, if > copy/delete fails. For example see: > http://diamondcs.com.au/freeutilities/fileunlocker.php Additionally see: http://ccollomb.free.fr/unlocker/ -Ulf From Ulf.Zibis at gmx.de Mon Oct 12 09:11:06 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 12 Oct 2009 18:11:06 +0200 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD33CA4.5020608@sun.com> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> <4AD3375C.9030400@gmx.de> <4AD33CA4.5020608@sun.com> Message-ID: <4AD3551A.3090602@gmx.de> Am 12.10.2009 16:26, Alan Bateman schrieb: > Ulf Zibis wrote: >> Am 12.10.2009 15:03, Ulf Zibis schrieb: >>> Additionally something like Path#unlock() would be helpful, if >>> copy/delete fails. For example see: >>> http://diamondcs.com.au/freeutilities/fileunlocker.php >> >> Additionally see: http://ccollomb.free.fr/unlocker/ > I assume this type of thing can lead to data loss and/or hard to > diagnose corruption. Of course, such method should be used with care. The developer/user should first retrieve/examine some information like the blocking process from the locked file. But this option should be more comfortable, than rebooting the hole system, which too could have data loss/corruption in consequence. ... and delete always has data loss in effect. ;-) > If you are running into sharing violations then try out the file > system API as the Windows provider opens files by default to allow > delete access (ie: close to Unix semantics by default with provider > specific options to control the DOS sharing mode if you really want). In java.nio.file.Filesystem b72 I don't find information about sharing attributes. > The only case where we still have a problem is memory-mapped files. > Changing the long standing behavior of the java.io classes is another > matter as that would likely break existing applications that rely on > the current/long standing behavior. > > -Alan. > > -Ulf From Alan.Bateman at Sun.COM Mon Oct 12 12:01:13 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 12 Oct 2009 20:01:13 +0100 Subject: What methods should go into a java.util.Objects class in JDK 7? In-Reply-To: <4AD3551A.3090602@gmx.de> References: <9F2CEE46-89BD-407C-B68C-00B819ABAE73@gmail.com> <15412A37E8C9574393B24ADD991FAA760B8AD21D9A@MERCMBX14.na.sas.com> <4AB10D85.8040402@sun.com> <4AD3290E.2010507@gmx.de> <4AD3375C.9030400@gmx.de> <4AD33CA4.5020608@sun.com> <4AD3551A.3090602@gmx.de> Message-ID: <4AD37CF9.8030203@sun.com> Ulf Zibis wrote: > : > In java.nio.file.Filesystem b72 I don't find information about sharing > attributes. These are provider specific open options so they aren't in the javadoc. If you look at the dosSharingOptionTests in jdk/test/java/nio/Path/SBC.java you will see tests for these options. -Alan. From cowwoc at bbs.darktech.org Sun Oct 18 11:59:56 2009 From: cowwoc at bbs.darktech.org (Gili) Date: Sun, 18 Oct 2009 11:59:56 -0700 (PDT) Subject: Moving CompletionHandler to java.util.concurrent Message-ID: <1255892396821-3845440.post@n2.nabble.com> Hi, I would like to propose moving CompletionHandler to package java.util.concurrent. Its use is not limited to I/O operations. For example, I use it for monitoring asynchronous Swing operations. CompletionHandler can be used virtually anywhere that java.util.concurrent.Future can, so why not place them in the same package? Gili -- View this message in context: http://n2.nabble.com/Moving-CompletionHandler-to-java-util-concurrent-tp3845440p3845440.html Sent from the nio-discuss mailing list archive at Nabble.com. From Alan.Bateman at Sun.COM Mon Oct 19 04:28:54 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 19 Oct 2009 12:28:54 +0100 Subject: Moving CompletionHandler to java.util.concurrent In-Reply-To: <1255892396821-3845440.post@n2.nabble.com> References: <1255892396821-3845440.post@n2.nabble.com> Message-ID: <4ADC4D76.5070003@sun.com> Gili wrote: > Hi, > > I would like to propose moving CompletionHandler to package > java.util.concurrent. Its use is not limited to I/O operations. For example, > I use it for monitoring asynchronous Swing operations. CompletionHandler can > be used virtually anywhere that java.util.concurrent.Future can, so why not > place them in the same package? > > Gili > Have you brought this up on concurrency-interest? I'm pretty sure this type of thing has come up many times (in the context of Executors at least). -Alan. From cowwoc at bbs.darktech.org Mon Oct 19 06:31:17 2009 From: cowwoc at bbs.darktech.org (Gili) Date: Mon, 19 Oct 2009 06:31:17 -0700 (PDT) Subject: Moving CompletionHandler to java.util.concurrent In-Reply-To: <4ADC4D76.5070003@sun.com> References: <1255892396821-3845440.post@n2.nabble.com> <4ADC4D76.5070003@sun.com> Message-ID: <1255959077569-3849014.post@n2.nabble.com> Alan Bateman wrote: > > Gili wrote: >> Hi, >> >> I would like to propose moving CompletionHandler to package >> java.util.concurrent. Its use is not limited to I/O operations. For >> example, >> I use it for monitoring asynchronous Swing operations. CompletionHandler >> can >> be used virtually anywhere that java.util.concurrent.Future can, so why >> not >> place them in the same package? >> >> Gili >> > Have you brought this up on concurrency-interest? I'm pretty sure this > type of thing has come up many times (in the context of Executors at > least). > I just cross-posted to http://www.nabble.com/Moving-CompletionHandler-to-java.util.concurrent-td25958440.html -- we'll see what they have to say. Oddly enough I couldn't find previous discussion of this sort of thing on their mailing list. Gili -- View this message in context: http://n2.nabble.com/Moving-CompletionHandler-to-java-util-concurrent-tp3845440p3849014.html Sent from the nio-discuss mailing list archive at Nabble.com. From mthornton at optrak.co.uk Mon Oct 19 07:35:24 2009 From: mthornton at optrak.co.uk (Mark Thornton) Date: Mon, 19 Oct 2009 15:35:24 +0100 Subject: Moving CompletionHandler to java.util.concurrent In-Reply-To: <1255959077569-3849014.post@n2.nabble.com> References: <1255892396821-3845440.post@n2.nabble.com> <4ADC4D76.5070003@sun.com> <1255959077569-3849014.post@n2.nabble.com> Message-ID: <4ADC792C.5090508@optrak.co.uk> Gili wrote: > > > I just cross-posted to > http://www.nabble.com/Moving-CompletionHandler-to-java.util.concurrent-td25958440.html > -- we'll see what they have to say. Oddly enough I couldn't find previous > discussion of this sort of thing on their mailing list. > > Gili > Does the nabble interface work both ways --- your message hasn't yet appeared on the 'real' concurrency list after an hour whereas it appeared on the nio list within a minute or so. Mark From cowwoc at bbs.darktech.org Mon Oct 19 11:48:57 2009 From: cowwoc at bbs.darktech.org (Gili) Date: Mon, 19 Oct 2009 11:48:57 -0700 (PDT) Subject: Moving CompletionHandler to java.util.concurrent In-Reply-To: <4ADC792C.5090508@optrak.co.uk> References: <1255892396821-3845440.post@n2.nabble.com> <4ADC4D76.5070003@sun.com> <1255959077569-3849014.post@n2.nabble.com> <4ADC792C.5090508@optrak.co.uk> Message-ID: <1255978137234-3851085.post@n2.nabble.com> Mark Thornton wrote: > > Does the nabble interface work both ways --- your message hasn't yet > appeared on the 'real' concurrency list after an hour whereas it > appeared on the nio list within a minute or so. > Hi Mark, It is normally instantaneous but in this case I forgot to subscribe to the forum prior to posting so my post is awaiting review by the moderator. It should be rectified within the next 24 hours. Gili -- View this message in context: http://n2.nabble.com/Moving-CompletionHandler-to-java-util-concurrent-tp3845440p3851085.html Sent from the nio-discuss mailing list archive at Nabble.com. From cowwoc at bbs.darktech.org Wed Oct 21 09:12:26 2009 From: cowwoc at bbs.darktech.org (Gili) Date: Wed, 21 Oct 2009 09:12:26 -0700 (PDT) Subject: Moving CompletionHandler to java.util.concurrent In-Reply-To: <4ADC792C.5090508@optrak.co.uk> References: <1255892396821-3845440.post@n2.nabble.com> <4ADC4D76.5070003@sun.com> <1255959077569-3849014.post@n2.nabble.com> <4ADC792C.5090508@optrak.co.uk> Message-ID: <1256141546200-3866340.post@n2.nabble.com> http://www.nabble.com/Re%3A-Moving-CompletionHandler-to-java.util.concurrent-p25964609.html brings up a good point: why don't we simply add event listeners to Future? Seems like a much cleaner and more useful approach... Instead of having to provide one method for Future and another for CompletionHandler, the Future would handle both use-cases. What do you think? Gili Mark Thornton wrote: > > Gili wrote: >> >> >> I just cross-posted to >> http://www.nabble.com/Moving-CompletionHandler-to-java.util.concurrent-td25958440.html >> -- we'll see what they have to say. Oddly enough I couldn't find previous >> discussion of this sort of thing on their mailing list. >> >> Gili >> > Does the nabble interface work both ways --- your message hasn't yet > appeared on the 'real' concurrency list after an hour whereas it > appeared on the nio list within a minute or so. > > Mark > > > -- View this message in context: http://n2.nabble.com/Moving-CompletionHandler-to-java-util-concurrent-tp3845440p3866340.html Sent from the nio-discuss mailing list archive at Nabble.com. From cowwoc at bbs.darktech.org Wed Oct 21 09:33:58 2009 From: cowwoc at bbs.darktech.org (Gili) Date: Wed, 21 Oct 2009 09:33:58 -0700 (PDT) Subject: Moving CompletionHandler to java.util.concurrent In-Reply-To: <4ADC4D76.5070003@sun.com> References: <1255892396821-3845440.post@n2.nabble.com> <4ADC4D76.5070003@sun.com> Message-ID: <1256142838070-3866513.post@n2.nabble.com> You know what Alan? The more I take a look at http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/util/concurrent/ListenableFuture.html the more it doesn't make sense to introduce CompletionHandler in Java7. Instead of introducing duplicate methods (one that uses Futures, another that uses CompletionHandler) we should just have a single method that handles both use-cases using a ListenableFuture. Have you guys reviewed this possibility already...? Thanks, Gili Alan Bateman wrote: > > Gili wrote: >> Hi, >> >> I would like to propose moving CompletionHandler to package >> java.util.concurrent. Its use is not limited to I/O operations. For >> example, >> I use it for monitoring asynchronous Swing operations. CompletionHandler >> can >> be used virtually anywhere that java.util.concurrent.Future can, so why >> not >> place them in the same package? >> >> Gili >> > Have you brought this up on concurrency-interest? I'm pretty sure this > type of thing has come up many times (in the context of Executors at > least). > > -Alan. > > -- View this message in context: http://n2.nabble.com/Moving-CompletionHandler-to-java-util-concurrent-tp3845440p3866513.html Sent from the nio-discuss mailing list archive at Nabble.com. From Alan.Bateman at Sun.COM Thu Oct 22 02:02:59 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 22 Oct 2009 10:02:59 +0100 Subject: Moving CompletionHandler to java.util.concurrent In-Reply-To: <1256142838070-3866513.post@n2.nabble.com> References: <1255892396821-3845440.post@n2.nabble.com> <4ADC4D76.5070003@sun.com> <1256142838070-3866513.post@n2.nabble.com> Message-ID: <4AE01FC3.9010504@sun.com> Gili wrote: > You know what Alan? The more I take a look at > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/util/concurrent/ListenableFuture.html > the more it doesn't make sense to introduce CompletionHandler in Java7. > Instead of introducing duplicate methods (one that uses Futures, another > that uses CompletionHandler) we should just have a single method that > handles both use-cases using a ListenableFuture. > > Have you guys reviewed this possibility already...? > Yes, this ground has been well covered. If you go back a few years to AIO4J, you'll see that it had an API that is close to what you are suggesting now. The API we have now is relatively simple - you wait/poll for a result using the Future, or you specify a callback (completion handler) to be invoked when the I/O operation completes. There is no support for "mixing" of styles where you might be waiting for the result and also consuming the result in a callback, or where you decide to register a callback after the fact. If you really need this then you can wrap the channels and use the completion handlers to drive the framework. -Alan. From cowwoc at bbs.darktech.org Thu Oct 22 09:57:52 2009 From: cowwoc at bbs.darktech.org (Gili) Date: Thu, 22 Oct 2009 09:57:52 -0700 (PDT) Subject: Moving CompletionHandler to java.util.concurrent In-Reply-To: <4AE01FC3.9010504@sun.com> References: <1255892396821-3845440.post@n2.nabble.com> <4ADC4D76.5070003@sun.com> <1256142838070-3866513.post@n2.nabble.com> <4AE01FC3.9010504@sun.com> Message-ID: <1256230672560-3873582.post@n2.nabble.com> Alan Bateman wrote: > > Gili wrote: >> You know what Alan? The more I take a look at >> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/util/concurrent/ListenableFuture.html >> the more it doesn't make sense to introduce CompletionHandler in Java7. >> Instead of introducing duplicate methods (one that uses Futures, another >> that uses CompletionHandler) we should just have a single method that >> handles both use-cases using a ListenableFuture. >> >> Have you guys reviewed this possibility already...? >> > Yes, this ground has been well covered. If you go back a few years to > AIO4J, you'll see that it had an API that is close to what you are > suggesting now. > Okay, so why did the team decide against this approach? What problems are associated with it? Alan Bateman wrote: > > If you really need this then you can > wrap the channels and use the completion handlers to drive the framework. > I don't understand what you mean here. How can one wrap a channel to achieve the behavior I'm asking for? Thanks, Gili -- View this message in context: http://n2.nabble.com/Moving-CompletionHandler-to-java-util-concurrent-tp3845440p3873582.html Sent from the nio-discuss mailing list archive at Nabble.com. From Alan.Bateman at Sun.COM Thu Oct 22 11:40:59 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 22 Oct 2009 19:40:59 +0100 Subject: Moving CompletionHandler to java.util.concurrent In-Reply-To: <1256230672560-3873582.post@n2.nabble.com> References: <1255892396821-3845440.post@n2.nabble.com> <4ADC4D76.5070003@sun.com> <1256142838070-3866513.post@n2.nabble.com> <4AE01FC3.9010504@sun.com> <1256230672560-3873582.post@n2.nabble.com> Message-ID: <4AE0A73B.4020402@sun.com> Gili wrote: > : > Okay, so why did the team decide against this approach? What problems are > associated with it? > If you want a callback (or completion handler) to be invoked when the I/O completes then you don't need a Future - just specify the completion handler when initiating the I/O operation and don't create any objects that could potentially be tenured. In terms of usage then it would be strange to wait/poll for a result and at the same time be notified when the I/O completes. In terms of performance it works well to dispatch directly to the completion handler on the thread that is handling the I/O event. If you are setting the completion handler after the fact then it may require a slow-path wakeup of an I/O thread to ensure that the completion handler is invoked on a thread with the correct identity (unlike thread pools, the threads may be blocked waiting on I/O events rather than work queues). > : > I don't understand what you mean here. How can one wrap a channel to achieve > the behavior I'm asking for? > It shouldn't be too hard to create a class that wraps a channel and defines I/O methods that return "ListeningFuture"-like object. The implementation will use the I/O methods that specify a completion handler so that it is notified when the I/O completes. That notification can be used to dispatch to the listeners, set the Future results, etc. The only complication is listeners that are set after the I/O completes. In that case it doesn't have a way to ensure that the listeners are invoked on a thread with the expected identity. -Alan. From vbonfanti at gmail.com Fri Oct 23 13:10:23 2009 From: vbonfanti at gmail.com (Vince Bonfanti) Date: Fri, 23 Oct 2009 16:10:23 -0400 Subject: Path.moveTo() javadoc question Message-ID: <18fbabce0910231310i65720ffeo124f34e1acb02f62@mail.gmail.com> A minor quibble; the Path.moveTo() javadoc says it throws a FileAlreadyExistsException "if the target file exists and cannot be replaced because the REPLACE_EXISTING option is not specified, or the target file is a non-empty directory." In the case of a non-empty directory, shouldn't it throw a DirectoryNotEmptyException? From Alan.Bateman at Sun.COM Fri Oct 23 14:32:49 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 23 Oct 2009 22:32:49 +0100 Subject: Path.moveTo() javadoc question In-Reply-To: <18fbabce0910231310i65720ffeo124f34e1acb02f62@mail.gmail.com> References: <18fbabce0910231310i65720ffeo124f34e1acb02f62@mail.gmail.com> Message-ID: <4AE22101.4030303@sun.com> Vince Bonfanti wrote: > A minor quibble; the Path.moveTo() javadoc says it throws a > FileAlreadyExistsException "if the target file exists and cannot be > replaced because the REPLACE_EXISTING option is not specified, or the > target file is a non-empty directory." In the case of a non-empty > directory, shouldn't it throw a DirectoryNotEmptyException? > That would be better and make sense for when you specify the REPLACE_EXISTING option. If you don't specify the REPLACE_EXISTING option then FileAlreadyExistsException is right. I need to verify that it doesn't impact the specification of ATOMIC_MOVE as that option prevents an implementation from doing any checks that would cause the operation to be non-atomic. Assuming there aren't any issues then I will create a bug to track this. -Alan. From edwardsd at amgen.com Mon Oct 26 08:08:37 2009 From: edwardsd at amgen.com (Edwards, David) Date: Mon, 26 Oct 2009 08:08:37 -0700 Subject: POSIX Permissions Message-ID: <74C8407BA5874A4CA347434E94150B74056ED1CA60@USTO-PMSG-MBS07.am.corp.amgen.com> Executing the following code Path path = Paths.get("/home/edwardsd"); PosixFileAttributes attr = Attributes.readPosixFileAttributes(path); System.out.format("%s %s %s%n", attr.owner().getName(), attr.group().getName(), PosixFilePermissions.toString(attr.permissions())); Produces the following output edwardsd users rwxrwxrwx However executing the UNIX command ls -ldi /home/edwardsd produces 32416151 drwxrwsrwx 68 edwardsd users 16384 Oct 26 07:07 edwardsd The file has the SGID permission Modifying permission using the code below results in the SGID permission being removed. path.getFileAttributeView(PosixFileAttributeView.class).setPermissions(perms); I assume this would also be an issue for the permissions SUID and StickyBit. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20091026/3d6da2c9/attachment.html From Alan.Bateman at Sun.COM Mon Oct 26 08:45:52 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 26 Oct 2009 15:45:52 +0000 Subject: POSIX Permissions In-Reply-To: <74C8407BA5874A4CA347434E94150B74056ED1CA60@USTO-PMSG-MBS07.am.corp.amgen.com> References: <74C8407BA5874A4CA347434E94150B74056ED1CA60@USTO-PMSG-MBS07.am.corp.amgen.com> Message-ID: <4AE5C430.10909@sun.com> Edwards, David wrote: > > Executing the following code > > Path path = Paths.get("/home/edwardsd"); > > PosixFileAttributes attr = Attributes.readPosixFileAttributes(path); > > System.out.format("%s %s %s%n", attr.owner().getName(), > > attr.group().getName(), > > PosixFilePermissions.toString(attr.permissions())); > > Produces the following output > > edwardsd users rwxrwxrwx > > However executing the UNIX command ls ?ldi /home/edwardsd produces > > 32416151 drwxrwsrwx 68 edwardsd users 16384 Oct 26 07:07 edwardsd > > The file has the SGID permission > > Modifying permission using the code below results in the SGID > permission being removed. > > path.getFileAttributeView(PosixFileAttributeView.class).setPermissions(perms); > > I assume this would also be an issue for the permissions SUID and > StickyBit. > Right, PosixFileAttributeView only supports the file permissions and not the sticky bit or user/group set-ID bits. So far this has not been a problem. Our providers on Solaris/Linux do have extensions for this but it requires using a provider specific "unix" view. -Alan.