From Alan.Bateman at Sun.COM Mon May 12 04:40:06 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 12 May 2008 12:40:06 +0100 Subject: Slides from JavaOne 2008 session Message-ID: <48282C96.1070403@sun.com> I presented at JavaOne last week with Carl Quinn. Overall I think it was well received and there were lots of good questions. The slides we used can be found here: http://openjdk.java.net/projects/nio/presentations/TS-5686.pdf Just before JavaOne, we did a tech talk at Google that served as a dry-run for the JavaOne session. This should be available on YouTube soon. -Alan. From Bryan.Valentini at gdc4s.com Thu May 22 12:53:36 2008 From: Bryan.Valentini at gdc4s.com (Valentini, Bryan-P58079) Date: Thu, 22 May 2008 15:53:36 -0400 Subject: IPv6 on Vista 64-bit Message-ID: <53B097B659B00140BD1B1EC96EC6A553027F59FB@pa10exm01.gddsi.com> I'm a developer building an NIO-based transport mechanism. I saw the slides from JavaOne, and I am pretty excited about your work there. I had a project engineer ask me about Vista 64-bit IPv6 support. I know about the outstanding Vista-IPv6 bug, but I'm not sure which platforms will be fully supported and when. Is there any official work being done to get NIO-IPv6 on Vista working for JDK 5 or 6? Will we be able to use the OpenJDK on Vista in the near future? Thanks for your time, Bryan Valentini -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20080522/49a80df4/attachment.html From Alan.Bateman at Sun.COM Thu May 22 13:32:17 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 22 May 2008 21:32:17 +0100 Subject: IPv6 on Vista 64-bit In-Reply-To: <53B097B659B00140BD1B1EC96EC6A553027F59FB@pa10exm01.gddsi.com> References: <53B097B659B00140BD1B1EC96EC6A553027F59FB@pa10exm01.gddsi.com> Message-ID: <4835D851.8030900@sun.com> Valentini, Bryan-P58079 wrote: > > I'm a developer building an NIO-based transport mechanism. I saw the > slides from JavaOne, and I am pretty excited about your work there. I > had a project engineer ask me about Vista 64-bit IPv6 support. I know > about the outstanding Vista-IPv6 bug, but I'm not sure which platforms > will be fully supported and when. Is there any official work being > done to get NIO-IPv6 on Vista working for JDK 5 or 6? Will we be able > to use the OpenJDK on Vista in the near future? > > Thanks for your time, > > Bryan Valentini > A good question! As part of the completion of the socket-channel work we have added support for the new IPv6 stack in Windows Vista (both 32-bit and 64-bit). This means you can create a ServerSocketChannel and accept connections from IPv4 or IPv6 peers, a SocketChannel can connect to IPv6 hosts, etc. The other part to supporting the new dual stack is the changes to the legacy socket APIs and these changes are already in jdk7/OpenJDK. If you want to try it out now, and you build OpenJDK, then you can apply the nio2 patch, re-build, and it will work. So far we've found the quality of the stack to be quite good and we haven't run into any issues. I appreciate that most developers don't want to build from the source code and to that end we will have downloadable binaries very soon (there is a small bit of setup needed on the download site before that can happen but stay tuned). If you are willing to try it out and send feedback that would be great! As regards jdk5 and jdk6 - we don't have any plans at this time to back-port the IPv6 support into the shipping releases. If there is a strong business case then there isn't any technical reason why these changes couldn't be back-ported into jdk6. One thing to say is that the effort to do this isn't so much on the code side but rather in the testing and test environments. So there is some cost and in general we haven't had a lot of interest in IPv6. With OpenJDK6 then another possibility is that someone from the community runs with this. -Alan. From elharo at metalab.unc.edu Sun May 25 17:07:22 2008 From: elharo at metalab.unc.edu (Elliotte Harold) Date: Sun, 25 May 2008 17:07:22 -0700 Subject: File System metadata Message-ID: <4839FF3A.9000405@metalab.unc.edu> I'm still working through the details, but the current implementation of FileSystem attributes seems way too limited. It's basically giving us what we have already, just in a new form. I was really hoping for a system that would allow for arbitrary properties on files without tieing the API to any one operating system. For instance, int permissions = file.getIntProperty("permissions"); boolean readonly = file.getBooleanProperty("readonly"): We can certainly debate exactly what sort of syntax for such generic metadata is appropriate. Java's strong typing makes this really hard to design elegantly. Perhaps they should all just be Object. Perhaps they shoudl just be strings. Maybe we need methods that return default values and maybe we don't. Those details can be worked out. Nonetheless the current approach of supporting only POSIX and DOS attributes, and then naming those attributes explicitly seems very rigid and not very useful. What about NTFS and Mac OS X attributes? and whatever comes next? What about virtual file systems based on HTTP or a source code control system? I think a filesystem should be able to provide whichever attributes make sense to it, and these should be queryable through a standard interface. Perhaps we can still have Basic and Space attributes, but we need a much more generic system that does not attempt to enumerate all possible attributes up front. -- Elliotte Rusty Harold elharo at metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ From Alan.Bateman at Sun.COM Mon May 26 02:10:29 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 26 May 2008 10:10:29 +0100 Subject: File System metadata In-Reply-To: <4839FF3A.9000405@metalab.unc.edu> References: <4839FF3A.9000405@metalab.unc.edu> Message-ID: <483A7E85.5070305@sun.com> Elliotte Harold wrote: > I'm still working through the details, but the current implementation > of FileSystem attributes seems way too limited. It's basically giving > us what we have already, just in a new form. The attributes defined by the various views in the attribute package provide access to significantly more meta-data than is possible with the File class today. Furthermore, an implementation can support additional views beyond those defined in that package -- ie: a provider is not limited to the attribute views defined in the attribute package. Another point is that one of our goals with the new API is to provide bulk access to file attributes - essentially a stat-like API because too often we see performance issues with applications that need to access several file attributes of the same file at around the same time. > > I was really hoping for a system that would allow for arbitrary > properties on files without tieing the API to any one operating > system. For instance, > > int permissions = file.getIntProperty("permissions"); > boolean readonly = file.getBooleanProperty("readonly"): > > We can certainly debate exactly what sort of syntax for such generic > metadata is appropriate. Java's strong typing makes this really hard > to design elegantly. Perhaps they should all just be Object. Perhaps > they shoudl just be strings. Maybe we need methods that return default > values and maybe we don't. Those details can be worked out. There's nothing to prevent us adding something that would provide reflective access but if you want to do something reasonable with the attribute values then you'll need to know something about their types and semantics. Taking your example of "permissions". In that case, you'll need the permissions attribute specified somewhere in order to interpret it. If I want to change the group permissions then I'll need to know which bit to toggle for example. It gets more fun with more complicated attributes such as access control lists. If the ACL is returned to me as a String then it will have to encode the list of entries with each entry further encoding the type, the identity, permissions, etc. As I hope I can convince you, the attributes needs to be defined somewhere to be usable by portable applications. > > Nonetheless the current approach of supporting only POSIX and DOS > attributes, and then naming those attributes explicitly seems very > rigid and not very useful. What about NTFS and Mac OS X attributes? > and whatever comes next? What about virtual file systems based on HTTP > or a source code control system? In the zipfs sample code you'll see an example of this in action. It defines ZipFileAttributeView and JarFileAttributeView that provide access to zip/JAR entry specific attributes. > > I think a filesystem should be able to provide whichever attributes > make sense to it, and these should be queryable through a standard > interface. Perhaps we can still have Basic and Space attributes, but > we need a much more generic system that does not attempt to enumerate > all possible attributes up front. > The granularity of the support is at the level of a set or group of attributes rather than individual attributes. To that end, the FileSystem#getFileAttributeViews is the method to enumerate the supported FileAttributeViews supported by the FileSystem. You can also ask an underlying FileStore if it supports a given view by invoking the supportsFileAttributeView method. An implementation is minimally required to support BaiscFileAttributeView and may support others (including provider/implementation specific FileAttributeView types that aren't defined by the attribute package). -Alan. From elharo at metalab.unc.edu Mon May 26 05:35:44 2008 From: elharo at metalab.unc.edu (Elliotte Harold) Date: Mon, 26 May 2008 05:35:44 -0700 Subject: File System metadata In-Reply-To: <483A7E85.5070305@sun.com> References: <4839FF3A.9000405@metalab.unc.edu> <483A7E85.5070305@sun.com> Message-ID: <483AAEA0.40007@metalab.unc.edu> Alan Bateman wrote: > Elliotte Harold wrote: > The attributes defined by the various views in the attribute package > provide access to significantly more meta-data than is possible with the > File class today. There are a few extra bits but not as much as I expected. There's a lot more that's out there that isn't supported by the current API. My hope that was by supporting arbitrary names and values one could write platform specific code without using platform specific classes. For example, I want to write a program that uses Mac specific attributes when running on a Mac, I'll probably need classes and methods that are only available on Apple's VM. This means that not only do I have to write platform specific code. I also have to do a lot of extra work to allow the same code to compile and run on other platforms due to missing classes and methods. Not impossible, of course. I do a lot of this already today. A generic file metadata API that used only JDK standard classes and methods would be a lot easier to configure at runtime. > Furthermore, an implementation can support additional > views beyond those defined in that package -- ie: a provider is not > limited to the attribute views defined in the attribute package. These will be second class citizens though. Imagine we removed the PosixFileAttributes and DosFileAttributes classes and associated methods; and relegated them to optional JDK-vendor specific extensions that programmers could not assume the presence of. Would you still be satisfied with the functionality that was available? > Another > point is that one of our goals with the new API is to provide bulk > access to file attributes - essentially a stat-like API because too > often we see performance issues with applications that need to access > several file attributes of the same file at around the same time. That's fine. You could of course have a generic getAttributes method that returned a map of all the attributes on the file on the given file system. > In the zipfs sample code you'll see an example of this in action. It > defines ZipFileAttributeView and JarFileAttributeView that provide > access to zip/JAR entry specific attributes. > Thanks. I'll look at that. > The granularity of the support is at the level of a set or group of > attributes rather than individual attributes. To that end, the > FileSystem#getFileAttributeViews is the method to enumerate the > supported FileAttributeViews supported by the FileSystem. You can also > ask an underlying FileStore if it supports a given view by invoking the > supportsFileAttributeView method. An implementation is minimally > required to support BaiscFileAttributeView and may support others > (including provider/implementation specific FileAttributeView types that > aren't defined by the attribute package). Those are the key pieces I was missing. That makes this minimally possible, though you still have the problem of needing to bundle filesystem specific classes with your code. This runs into all sorts of licensing troubles, as well as extra weight for a program. It's like bundling a lot of the Apple-specific classes into a program just so you can run your MRJ invoking jar on Windows. Or you can just use reflection to call everything. I now see how you're planning to support extensions, which I didn't before. However I still think a generic approach would be a lot cleaner and more elegant. -- Elliotte Rusty Harold elharo at metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ From elharo at metalab.unc.edu Mon May 26 06:05:53 2008 From: elharo at metalab.unc.edu (Elliotte Harold) Date: Mon, 26 May 2008 06:05:53 -0700 Subject: exists and notExists Message-ID: <483AB5B1.6050101@metalab.unc.edu> Why do are there both exists() and notExists() methods in java.nio.file.Path? Is there some subtle issue such that notExists() is not equivalent to !exists()? Otherwise, this feels like unnecessary duplication to me. I'd rather have just the single exists() method. -- Elliotte Rusty Harold elharo at metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ From Alan.Bateman at Sun.COM Mon May 26 06:12:45 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 26 May 2008 14:12:45 +0100 Subject: exists and notExists In-Reply-To: <483AB5B1.6050101@metalab.unc.edu> References: <483AB5B1.6050101@metalab.unc.edu> Message-ID: <483AB74D.30709@sun.com> Elliotte Harold wrote: > Why do are there both exists() and notExists() methods in > java.nio.file.Path? Is there some subtle issue such that notExists() > is not equivalent to !exists()? > > Otherwise, this feels like unnecessary duplication to me. I'd rather > have just the single exists() method. > An existence check yields one of three answers: the file exists, the file does not exist, or it can't say (due a permission problem for example). The exists and notExists are convenience methods for cases where you want to take action when a file is confirmed to exist (at that point in time), or confirmed to not exist. -Alan. From Alan.Bateman at Sun.COM Mon May 26 06:18:20 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 26 May 2008 14:18:20 +0100 Subject: File System metadata In-Reply-To: <483AAEA0.40007@metalab.unc.edu> References: <4839FF3A.9000405@metalab.unc.edu> <483A7E85.5070305@sun.com> <483AAEA0.40007@metalab.unc.edu> Message-ID: <483AB89C.1050601@sun.com> Elliotte Harold wrote: > : > There are a few extra bits but not as much as I expected. There's a > lot more that's out there that isn't supported by the current API. Which file attributes are you specifically thinking about and are they interesting to main-stream applications? > > My hope that was by supporting arbitrary names and values one could > write platform specific code without using platform specific classes. > For example, I want to write a program that uses Mac specific > attributes when running on a Mac, I'll probably need classes and > methods that are only available on Apple's VM. This means that not > only do I have to write platform specific code. I also have to do a > lot of extra work to allow the same code to compile and run on other > platforms due to missing classes and methods. Not impossible, of > course. I do a lot of this already today. A generic file metadata API > that used only JDK standard classes and methods would be a lot easier > to configure at runtime. For the Mac port it should support BasicFileAttributeView, PosixFileAttributeView, AclFileAttributeView, and NamedAttributeFileView at least. You are correct that if you want to access/manipulate file system specific attributes then the classes would need to be present. Reflective access would help with that but you loose compile time safety. > : > These will be second class citizens though. Imagine we removed the > PosixFileAttributes and DosFileAttributes classes and associated > methods; and relegated them to optional JDK-vendor specific extensions > that programmers could not assume the presence of. Would you still be > satisfied with the functionality that was available? The reason these attributes views are defined is because the respective attributes are commonly used or supported by many file systems. > >> Another point is that one of our goals with the new API is to provide >> bulk access to file attributes - essentially a stat-like API because >> too often we see performance issues with applications that need to >> access several file attributes of the same file at around the same time. > > That's fine. You could of course have a generic getAttributes method > that returned a map of all the attributes on the file on the given > file system. Except there isn't much you can do with them without their definitions. For example, if the map contains the entry "hfsplus.checkedData" for the HFS+ specific attribute that is the date/time that the volume was checked for consistency then you can't interpret the value without implementation specific specification. -Alan. From carfield at carfield.com.hk Mon May 26 09:35:46 2008 From: carfield at carfield.com.hk (Carfield Yim) Date: Tue, 27 May 2008 00:35:46 +0800 Subject: exists and notExists In-Reply-To: <483AB74D.30709@sun.com> References: <483AB5B1.6050101@metalab.unc.edu> <483AB74D.30709@sun.com> Message-ID: On Mon, May 26, 2008 at 9:12 PM, Alan Bateman wrote: > Elliotte Harold wrote: >> >> Why do are there both exists() and notExists() methods in >> java.nio.file.Path? Is there some subtle issue such that notExists() is not >> equivalent to !exists()? >> >> Otherwise, this feels like unnecessary duplication to me. I'd rather have >> just the single exists() method. >> > An existence check yields one of three answers: the file exists, the file > does not exist, or it can't say (due a permission problem for example). The > exists and notExists are convenience methods for cases where you want to > take action when a file is confirmed to exist (at that point in time), or > confirmed to not exist. > Is that really useful to most of us? Why not enchancing existing API but duplicate what we have? From Alan.Bateman at Sun.COM Mon May 26 09:45:46 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 26 May 2008 17:45:46 +0100 Subject: exists and notExists In-Reply-To: References: <483AB5B1.6050101@metalab.unc.edu> <483AB74D.30709@sun.com> Message-ID: <483AE93A.1070307@sun.com> Carfield Yim wrote: > : > Is that really useful to most of us? Why not enchancing existing API > but duplicate what we have? > Are you saying that the notExists method isn't useful or are you saying you it should be added to java.io.File? If the latter, then recall that File has many many problems and the platform is long overdue a better interface to the file system. By adding the getFileRef method we provide a way for existing applications to make use of the new functionality without extensive changes to existing applications. -Alan. From elharo at metalab.unc.edu Mon May 26 17:59:22 2008 From: elharo at metalab.unc.edu (Elliotte Harold) Date: Mon, 26 May 2008 17:59:22 -0700 Subject: exists and notExists In-Reply-To: <483AB74D.30709@sun.com> References: <483AB5B1.6050101@metalab.unc.edu> <483AB74D.30709@sun.com> Message-ID: <483B5CEA.4010509@metalab.unc.edu> Alan Bateman wrote: > An existence check yields one of three answers: the file exists, the > file does not exist, or it can't say (due a permission problem for > example). The exists and notExists are convenience methods for cases > where you want to take action when a file is confirmed to exist (at that > point in time), or confirmed to not exist. > As I read the JavaDoc, the only reason the exists() method won't be able to say is if it throws a SecurityException. Correct? (If not, the JavaDoc needs to be clarified.) I don't feel like notExists is convenient enough to justify its existence. Presumably if one cannot tell if a file exists, one cannot tell if it doesn't exist either. Both are SecurityExceptions. Can you imagine the bloat if every isXXX() method in Java was matched by a isNotXXX() method? Let's not start down this path. A single exists() method is fully sufficient. -- Elliotte Rusty Harold elharo at metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ From elharo at metalab.unc.edu Mon May 26 18:21:22 2008 From: elharo at metalab.unc.edu (Elliotte Harold) Date: Mon, 26 May 2008 18:21:22 -0700 Subject: File System metadata In-Reply-To: <483AB89C.1050601@sun.com> References: <4839FF3A.9000405@metalab.unc.edu> <483A7E85.5070305@sun.com> <483AAEA0.40007@metalab.unc.edu> <483AB89C.1050601@sun.com> Message-ID: <483B6212.8060908@metalab.unc.edu> Alan Bateman wrote: > Elliotte Harold wrote: >> : >> There are a few extra bits but not as much as I expected. There's a >> lot more that's out there that isn't supported by the current API. > Which file attributes are you specifically thinking about and are they > interesting to main-stream applications? > The first thing that comes to mind is pretty much everything on Mac OS X. The second is version control information for a custom VFS based on a source code control repository. The third are WebDAV HTTP headers. The fourth are arbitrary NTFS attributes that can be defined by an application. These can't even be enumerated, or predicted by any compile time library whether written by Sun, me, or Microsoft. The fifth are a few standard NTFS attributes like compress that you seem to have missed (unless I just missed them in the JavaDoc). The sixth are whatever new standard attributes Microsoft and others add in future versions of their operating systems before you can rev and release a new version of Java to support them. I see no plausible way we can predict all the likely attributes in advance. > For the Mac port it should support BasicFileAttributeView, > PosixFileAttributeView, AclFileAttributeView, and NamedAttributeFileView > at least. You are correct that if you want to access/manipulate file > system specific attributes then the classes would need to be present. > Reflective access would help with that but you loose compile time safety. There's no need for compile time type safety here. You can program with the knowledge of which attributes you expect to find in a file system without needing to have everything predefined in a class at compile time. Let me reemphasize: I want to be able to write code that inspects the local platform and behaves accordingly without using any platform dependent classes. I do not want to have to use any Apple specific classes just to read the Mac creator code when my program is running on the Mac (for example). Instead I want to to be able to simply ask for the relevant attribute and get it if it's available, and get null if it's not. I don't want to bundle extra classes with my app just to do this. The local, implementation dependent classes in the local VM will know which attributes they do and don't support. That should be enough. >> These will be second class citizens though. Imagine we removed the >> PosixFileAttributes and DosFileAttributes classes and associated >> methods; and relegated them to optional JDK-vendor specific extensions >> that programmers could not assume the presence of. Would you still be >> satisfied with the functionality that was available? > The reason these attributes views are defined is because the respective > attributes are commonly used or supported by many file systems. My point was a though experiment. Suppose POSIX attributes were not supported by many file systems, and were not bundled with the JDK so you couldn't rely on their presence across platforms. (That is remove every method and class from java.nio.file with the word POSIX in its name.) Now suppose you happen to be the developer working in a POSIX VM that provides impl classes that support POSIX attributes. You need to write a program that takes advantage of POSIX attributes when available, but doesn't fall over and die when it runs on a non-POSIX platform. Would you be comfortable using the java.nio.file API? My claim is that you would be very uncomfortable. This is exactly how developers writing Swing applications that behave natively on the Mac have had to work for years, and it is doable but very painful and lot of work. Now this cross-platform pain is going to be extended to anyone working on a file system (including custom virtual file systems) that is not bundled with the JDK. I think that some basic redesigns of the attributes mechanism so that much less detail and foreknowledge was baked into the method and class names at compile time would make it all much more flexible and far less painful. >> That's fine. You could of course have a generic getAttributes method >> that returned a map of all the attributes on the file on the given >> file system. > Except there isn't much you can do with them without their definitions. > For example, if the map contains the entry "hfsplus.checkedData" for the > HFS+ specific attribute that is the date/time that the volume was > checked for consistency then you can't interpret the value without > implementation specific specification. No one's saying you'd write code without knowledge of the definitions. You'd still know what getAttributes().get("readonly") was likely to return. You'd just encode that foreknowledge in the method argument instead of the method name. -- Elliotte Rusty Harold elharo at metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ From Alan.Bateman at Sun.COM Tue May 27 00:28:31 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 27 May 2008 08:28:31 +0100 Subject: exists and notExists In-Reply-To: <483B5CEA.4010509@metalab.unc.edu> References: <483AB5B1.6050101@metalab.unc.edu> <483AB74D.30709@sun.com> <483B5CEA.4010509@metalab.unc.edu> Message-ID: <483BB81F.90602@sun.com> Elliotte Harold wrote: > : > As I read the JavaDoc, the only reason the exists() method won't be > able to say is if it throws a SecurityException. Correct? This is nothing to do with security managers and SecurityExceptions. The Java virtual machine may not have access to the file or one of the directories in the path. In that case, it is not possible to say if the file exists or not. There can be many other I/O error related reasons too. > (If not, the JavaDoc needs to be clarified.) If the javadoc isn't clear then we can improve it. In this case it says it returns false "if the file does not exist or its existence cannot be determined". > > I don't feel like notExists is convenient enough to justify its > existence. Presumably if one cannot tell if a file exists, one cannot > tell if it doesn't exist either. Both are SecurityExceptions. If we can't determine the file exists then the exists() method will return false. You cannot interpret this to mean the file does not exist. This is the reason for the notExists method. It's a trivial convenience method to allow you take action when it is confirmed that a file does not exit. > Can you imagine the bloat if every isXXX() method in Java was matched > by a isNotXXX() method? Let's not start down this path. A single > exists() method is fully sufficient. > The existence check differs from the other access checks and a boolean result is insufficient. There is no plan to add complement variants of the other methods. -Alan. From mthornton at optrak.co.uk Tue May 27 00:58:48 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Tue, 27 May 2008 08:58:48 +0100 Subject: exists and notExists In-Reply-To: <483BB81F.90602@sun.com> References: <483AB5B1.6050101@metalab.unc.edu> <483AB74D.30709@sun.com> <483B5CEA.4010509@metalab.unc.edu> <483BB81F.90602@sun.com> Message-ID: <483BBF38.1080301@optrak.co.uk> Alan Bateman wrote: > If we can't determine the file exists then the exists() method will > return false. You cannot interpret this to mean the file does not > exist. This is the reason for the notExists method. It's a trivial > convenience method to allow you take action when it is confirmed that > a file does not exit. So in the case where existence can't be determined, both methods will return false. I would prefer exists() to throw an exception which gave the reason as accurately as possible. The existing File.delete() method is very frustrating, as when it returns false there is a laundry list of possible reasons but no clue as to which is true. Mark Thornton From Alan.Bateman at Sun.COM Tue May 27 01:07:59 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 27 May 2008 09:07:59 +0100 Subject: exists and notExists In-Reply-To: <483BBF38.1080301@optrak.co.uk> References: <483AB5B1.6050101@metalab.unc.edu> <483AB74D.30709@sun.com> <483B5CEA.4010509@metalab.unc.edu> <483BB81F.90602@sun.com> <483BBF38.1080301@optrak.co.uk> Message-ID: <483BC15F.1030001@sun.com> Mark Thornton wrote: > So in the case where existence can't be determined, both methods will > return false. I would prefer exists() to throw an exception which gave > the reason as accurately as possible. The existing File.delete() > method is very frustrating, as when it returns false there is a > laundry list of possible reasons but no clue as to which is true. > The checkAccess method does what you want. It checks the existence of a file and optionally its accessibility. It throws an exception and also documents a number of specific exceptions for specific cases. The exists/notExists methods that Elliotte is concerned about are convenience methods built on that. Yes, File.delete is frustrating and many other methods have the same problem. We can finally fix these problems. -Alan. From Alan.Bateman at Sun.COM Tue May 27 02:18:10 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 27 May 2008 10:18:10 +0100 Subject: File System metadata In-Reply-To: <483B6212.8060908@metalab.unc.edu> References: <4839FF3A.9000405@metalab.unc.edu> <483A7E85.5070305@sun.com> <483AAEA0.40007@metalab.unc.edu> <483AB89C.1050601@sun.com> <483B6212.8060908@metalab.unc.edu> Message-ID: <483BD1D2.9070204@sun.com> Elliotte Harold wrote: > : > The first thing that comes to mind is pretty much everything on Mac OS X. Nick may want to chime in here but I believe almost everything is already covered by the file attributes views that we have included. HFS+ does have a number of HFS+ specific attributes but I don't know if many non-specialized applications make use of these or even if they are accessible to user-mode applications. > > The second is version control information for a custom VFS based on a > source code control repository. > > The third are WebDAV HTTP headers. > > The fourth are arbitrary NTFS attributes that can be defined by an > application. These can't even be enumerated, or predicted by any > compile time library whether written by Sun, me, or Microsoft. Are you thinking of NTFS extended attributes? I'm not aware that these are accessible to user-mode applications. You might be thinking of NTFS Alternative Data Streams in which case this is what NamedAttributeView uses on that file system. > > The fifth are a few standard NTFS attributes like compress that you > seem to have missed (unless I just missed them in the JavaDoc). There are a few other NTFS specific attributes but it's so rare to find applications that make use of them that we didn't include a NTFS specific attribute view. > > The sixth are whatever new standard attributes Microsoft and others > add in future versions of their operating systems before you can rev > and release a new version of Java to support them. > > I see no plausible way we can predict all the likely attributes in > advance. The approach we have taken to date is that each provider is required to support BasicFileAttributeView that provides access to a basic set of attributes that are common to many file systems. For many applications this should be sufficient as they won't care about other attributes. For other file attributes then there are choices on how they can be supported. The approach we have taken is to allow the provider implementor define views of the attributes that it supports. Out of the box, the platform can define optional views for common sets of file attributes. The provider may define others. As you have observed, this means that if you want to access these file system specific attributes then you do need to compile against the interface that the provider defines. No big deal for an application that targets a specific platform or provider but a pain if you are a generic file attribute browser or have semantic knowledge about certain file systems that you use when running on those file systems. The other approach, which isn't incompatible with the first approach, is to provide generic or reflective access. At one point we had a prototype file attribute view that did exactly that. Okay for simple types but messy for anything more complicated. All I can say is that I will check with the group about re-visiting this topic but I'm prettry sure we don't want to re-invent JNDI :-) -Alan. From mthornton at optrak.co.uk Tue May 27 03:14:28 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Tue, 27 May 2008 11:14:28 +0100 Subject: File System metadata In-Reply-To: <483BD1D2.9070204@sun.com> References: <4839FF3A.9000405@metalab.unc.edu> <483A7E85.5070305@sun.com> <483AAEA0.40007@metalab.unc.edu> <483AB89C.1050601@sun.com> <483B6212.8060908@metalab.unc.edu> <483BD1D2.9070204@sun.com> Message-ID: <483BDF04.60603@optrak.co.uk> Alan Bateman wrote: > when running on those file systems. The other approach, which isn't > incompatible with the first approach, is to provide generic or > reflective access. At one point we had a prototype file attribute view > that did exactly that. Okay for simple types but messy for anything > more complicated. All I can say is that I will check with the group > about re-visiting this topic but I'm prettry sure we don't want to > re-invent JNDI :-) > I wrote a JNDI provider that allowed access to most Windows file/directory attributes. While it had the advantage that (almost) everything was possible, the price was that nothing was simple. The NTFS compressed attribute and compressed size information is commonly used by file browsers and also file open/save dialogs. You can't do a faithful emulation of the Windows open/save dialog without access to the compressed atribute (on my system compressed directories/files are shown in blue). This would be relevant to the Windows L&F implementation of JFileChooser. Mark Thornton From elharo at metalab.unc.edu Tue May 27 07:01:39 2008 From: elharo at metalab.unc.edu (Elliotte Harold) Date: Tue, 27 May 2008 07:01:39 -0700 Subject: exists and notExists In-Reply-To: <483BB81F.90602@sun.com> References: <483AB5B1.6050101@metalab.unc.edu> <483AB74D.30709@sun.com> <483B5CEA.4010509@metalab.unc.edu> <483BB81F.90602@sun.com> Message-ID: <483C1443.5010908@metalab.unc.edu> Alan Bateman wrote: >> (If not, the JavaDoc needs to be clarified.) > If the javadoc isn't clear then we can improve it. In this case it says > it returns false "if the file does not exist or its existence cannot be > determined". > But what is gained? I still don't understand in what circumstances notExists() will tell you something that !exists() does not. Can you please clarify when !path.exists() might return a different answer than path.notExists()? Might they both return false if the existence cannot be determined? If so, I'd argue that the non-Aristotelian logic here is likely to be deeply confusing. (It's certainly confusing me.) Better solutions would be to either 1. Use an enumerated return type rather than a boolean that has three states: exists, not exists, unknown. or 2. Throw an IOException if the existence cannot be determined. I'm not sure which I prefer. I think #2 is probably easier, but I'm not sure of that. Regardless the current scheme is just asking for confusion. -- Elliotte Rusty Harold elharo at metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ From Alan.Bateman at Sun.COM Tue May 27 07:35:13 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 27 May 2008 15:35:13 +0100 Subject: exists and notExists In-Reply-To: <483C1443.5010908@metalab.unc.edu> References: <483AB5B1.6050101@metalab.unc.edu> <483AB74D.30709@sun.com> <483B5CEA.4010509@metalab.unc.edu> <483BB81F.90602@sun.com> <483C1443.5010908@metalab.unc.edu> Message-ID: <483C1C21.5000509@sun.com> Elliotte Harold wrote: > : > But what is gained? I still don't understand in what circumstances > notExists() will tell you something that !exists() does not. Can you > please clarify when > > !path.exists() might return a different answer than path.notExists()? > > Might they both return false if the existence cannot be determined? Correct! If we cannot determine if the file exists then both methods would return false as documented. > > If so, I'd argue that the non-Aristotelian logic here is likely to be > deeply confusing. (It's certainly confusing me.) Better solutions > would be to either > > 1. Use an enumerated return type rather than a boolean that has three > states: exists, not exists, unknown. > > or > > 2. Throw an IOException if the existence cannot be determined. > > I'm not sure which I prefer. I think #2 is probably easier, but I'm > not sure of that. Regardless the current scheme is just asking for > confusion. > The motivation for these two convenience methods was to make testing for file existence to be very easy. It wasn't intended to be confusing so I'm glad you've brought it up. -Alan. From Alan.Bateman at Sun.COM Wed May 28 05:45:40 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 28 May 2008 13:45:40 +0100 Subject: NIO: missing createTempFile() and deleteOnExit() In-Reply-To: <000801c8c0aa$a5207440$d705a8c0@inet> References: <000801c8c0aa$a5207440$d705a8c0@inet> Message-ID: <483D53F4.6030608@sun.com> xxxxxxxxxxxxxxx wrote: > > I'm very interested to play with the NIO in the fields of portable > applications to use it for encrypted filesystems in a singel file and > so on. To port existing applications and dbs it would be nice to have > two more things in the NIO: createTempFile() and deleteOnExit(). > > If I missed it in the existing NIO please give me a hint. > > Otherwise my proposals just need very little modification of the > existing interfaces. > > PROPOSALS: > > static File createTempFile(String prefix, String suffix) > static File createTempFile(String prefix, String suffix, File directory) > ---> public abstract Path createFile(Attribute... attrs) throws > IOException > with Attributes for prefix, suffix [and directory] > ( or by breaking the existing interface > ---> public abstract Path createTempFile(...) throws IOException ) > > > void deleteOnExit() > ---> public static final StandardOpenOption DELETE_ON_EXIT > (I've moved this to nio-discuss as that is the mailing list for feedback) Thank you for bringing up these topics. The summary answer is that they aren't present but they aren't forgotten either. You've suggested adding a DELETE_ON_EXIT option to the standard open options. I may be reading too much into this but did you mean DELETE_ON_CLOSE instead? A delete-on-close option may be useful but it's not supported on many operating systems and isn't really feasible to implement without support from the kernel (deleting the file after close isn't exactly the same thing as the file may have been replaced by an attacker and so we would delete the wrong file). If you mean the File deleteOnExit method then you are correct that this isn't an equivalent. Arguably we haven't really needed the delete on exit mechanism since the addition of the shutdown hooks in 1.3. The shutdown hooks allow for other types of tasks in addition to removing individual files before the VM shuts down. They can also be cancelled which is something that isn't (currently) possible with the delete mechanism. Another point is that with the provider interface there is potential for other types of file systems and it may be that you want is for the file to be registered for deletion when the FileSystem is closed (VM exit is too late). More generally you may have tasks to perform before the file system is closed. It would be good to get more feedback in this area so that we do the right thing. As regards temporary files: File.createFile(prefix,suffix).getFileRef() creates a temporary file and gives you an object in the new API to access that file. If you are instead asking about creating temporary file in a given FileSystem then we currently don't have a method to do that, unless of course you choose the temporary file name yourself and invoke createFile. The notion of "temporary directory" is traditionally something that is configured for the platform rather than a per-file system basis. It could be extended of course so feedback on this area is welcome too. -Alan.