From tony.childs at gmail.com Wed Jul 2 09:11:48 2008 From: tony.childs at gmail.com (Tony Childs) Date: Wed, 2 Jul 2008 11:11:48 -0500 Subject: WatchKey#PollEvents() returning more events than expected Message-ID: <29b165210807020911w55fe596dp93259916c2108203@mail.gmail.com> I've been listening to the Google Talks presentationon NIO.2 and reading through the PDF that Alan posted. Upon testing code similar to that on page 22 of the PDF, I noticed unexpected (to me) behavior. When watching a directory and then adding a space to a text file and then saving it, WatchKey#PollEvents() returns two ENTRY_MODIFY events that seem identical but are actually copies of each other. Any idea why there would be two? Also, when I create a new file, in the watched directory, pollEvents() initially returns one ENTRY_CREATE event and then a subsequent call returns three more events: ENTRY_DELETE, ENTRY_CREATE, and ENTRY_MODIFY. I'm confused as to why there are so many events for a seemly simple operation? Thanks, Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20080702/3a14d1d0/attachment.html From Umashankar.Ningaiah at Sun.COM Thu Jul 3 02:22:01 2008 From: Umashankar.Ningaiah at Sun.COM (Umashankar) Date: Thu, 03 Jul 2008 14:52:01 +0530 Subject: WatchKey#PollEvents() returning more events than expected Message-ID: <486C9A39.1010009@sun.com> Hi Tony, Please see my answers inline . Subject: WatchKey#PollEvents() returning more events than expected From: Tony Childs Date: Wed, 02 Jul 2008 11:11:48 -0500 To: nio-discuss at openjdk.java.net I've been listening to the Google Talks presentation on NIO.2 and reading through the PDF that Alan posted. Upon testing code similar to that on page 22 of the PDF, I noticed unexpected (to me) behavior. When watching a directory and then adding a space to a text file and then saving it, WatchKey#PollEvents() returns two ENTRY_MODIFY events that seem identical but are actually copies of each other. Any idea why there would be two? Multiple ENTRY_MODIFY events are normal. This is platform specific. There is a wording in WatchService spec about this. I am pasting it here for your reference "many of the details on how events are detected, their timeliness, and whether their ordering is preserved is highly implementation specific. For example, when a file in a watched directory is modified then it may result in a single |ENTRY_MODIFY| event in some implementations but several events in other implementations." Also, when I create a new file, in the watched directory, pollEvents() initially returns one ENTRY_CREATE event and then a subsequent call returns three more events: ENTRY_DELETE, ENTRY_CREATE, and ENTRY_MODIFY. I'm confused as to why there are so many events for a seemly simple operation? You should get only one ENTRY_CREATE event for this case. One reason why you are getting more events is, may be you are using an editor that creates a temp file and deletes it. You could print the context of the event and check the file which is causing the additional events. Herewith I am attaching a small program for your reference. Please run the same and see if you still get the additional events. Thanks, Umashankar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20080703/64b89d30/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: WatchServiceEx.java Type: text/x-java Size: 2186 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20080703/64b89d30/attachment.bin From javalists at cbfiddle.com Tue Jul 8 13:12:51 2008 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 8 Jul 2008 13:12:51 -0700 Subject: abstract paths Message-ID: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> Thanks to the article by Elliotte Harold, I have become aware of this work. I want to say that it is long overdue and will be much appreciated. I want to make a pitch for supporting fully abstract paths, that is, paths that are not bound to any file system or file system implementation. A fully abstract path is simply a sequence of names. Before it can be used to access a resource, it must be presented to a file system (which might convert it to a bound path as in the current design). Fully abstract paths can be useful whenever you are performing cross file system operations, such as mirroring. The same relative fully abstract path can be presented to two file systems to access resources that correspond by name. Fully abstract paths could also be used in a catalog (as might be created by a backup program), which stores metadata but does not contain the actual files. I would imagine that fully abstract paths could be supported in the current design fairly easily by defining a concrete superclass of Path. Alan From mthornton at optrak.co.uk Tue Jul 8 13:29:56 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Tue, 08 Jul 2008 21:29:56 +0100 Subject: abstract paths In-Reply-To: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> Message-ID: <4873CE44.4070409@optrak.co.uk> Alan Snyder wrote: > Thanks to the article by Elliotte Harold, I have become aware of this > work. I want to say that it is long overdue and will be much appreciated. > > I want to make a pitch for supporting fully abstract paths, that is, > paths that are not bound to any file system or file system > implementation. A fully abstract path is simply a sequence of names. > Before it can be used to access a resource, it must be presented to a > file system (which might convert it to a bound path as in the current > design). > > Fully abstract paths can be useful whenever you are performing cross > file system operations, such as mirroring. The same relative fully > abstract path can be presented to two file systems to access resources > that correspond by name. Fully abstract paths could also be used in a > catalog (as might be created by a backup program), which stores > metadata but does not contain the actual files. > > I would imagine that fully abstract paths could be supported in the > current design fairly easily by defining a concrete superclass of Path. > > Alan > I think only relative 'abstract' paths make much sense and these could be represented as List. So possibly add Path.get(List) and FileSystem.getPath(List) methods. Mark Thornton From tony.childs at gmail.com Thu Jul 10 06:02:04 2008 From: tony.childs at gmail.com (Tony Childs) Date: Thu, 10 Jul 2008 08:02:04 -0500 Subject: WatchKey#PollEvents() returning more events than expected In-Reply-To: <486C9A39.1010009@sun.com> References: <486C9A39.1010009@sun.com> Message-ID: <29b165210807100602h4ed641a7nc4b03d3d8535d15f@mail.gmail.com> Thank you for your help. I don't know how I missed note about ENTRY_MODIFY in the Javadoc. Regarding my second issue, I am creating the file using Windows (XP) Explorer (File-->New-->Text Document). I'm guessing this is an OS behavior as well. Thanks again, Tony On Thu, Jul 3, 2008 at 4:22 AM, Umashankar wrote: > Hi Tony, > Please see my answers inline . > > Subject: > WatchKey#PollEvents() returning more events than expected From: > Tony Childs > Date: > Wed, 02 Jul 2008 11:11:48 -0500 To: > nio-discuss at openjdk.java.net > I've been listening to the Google Talks presentationon NIO.2 and reading through the > PDF that > Alan posted. Upon testing code similar to that on page 22 of the PDF, I > noticed unexpected (to me) behavior. When watching a directory and then > adding a space to a text file and then saving it, WatchKey#PollEvents() > returns two ENTRY_MODIFY events that seem identical but are actually copies > of each other. Any idea why there would be two? > > Multiple ENTRY_MODIFY events are normal. This is platform specific. There > is a wording in WatchService spec about this. I am pasting it here for your > reference > "many of the details on how events are detected, their timeliness, and > whether their ordering is preserved is highly implementation specific. For > example, when a file in a watched directory is modified then it may result > in a single ENTRY_MODIFYevent in some implementations but several events in other implementations." > > Also, when I create a new file, in the watched directory, pollEvents() > initially returns one ENTRY_CREATE event and then a subsequent call returns > three more events: ENTRY_DELETE, ENTRY_CREATE, and ENTRY_MODIFY. I'm > confused as to why there are so many events for a seemly simple operation? > > You should get only one ENTRY_CREATE event for this case. One reason why > you are getting more events is, may be you are using an editor that creates > a temp file and deletes it. You could print the context of the event and > check the file which is causing the additional events. > Herewith I am attaching a small program for your reference. Please run the > same and see if you still get the additional events. > > Thanks, > Umashankar > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20080710/69d89fc6/attachment.html From Alan.Bateman at Sun.COM Sun Jul 13 09:11:26 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 13 Jul 2008 17:11:26 +0100 Subject: MIME Types In-Reply-To: <4865496D.50507@optrak.co.uk> References: <4865496D.50507@optrak.co.uk> Message-ID: <487A292E.6010005@sun.com> Mark Thornton wrote: > The Files.probeContentType documentation includes this sentence: "The > string is guaranteed to be parsable according to the grammar in the > RFC". However, one of the values I get is "image/OLYMPUS Raw Format" > --- the RFC doesn't allow spaces in the sub type. Of course this also > neither an IANA registered type nor does it start with x-. My registry > entry for orf is "image/OLYMPUS Raw Format", so it is difficult to > return anything else, but it does mean the guarantee can't be maintained. I was on vacation so apologies for the late reply. Yes, this is a bug and thanks for finding it. FileTypeDetector implementations are required to return a content type with a syntax that adheres to that specified in the RFC. So in the case of your ORF files, it should return "null" (meaning that the file type is not recognized) as the registry contains garbage. I'll fix this for the next build (Rajendra - thanks for checking the GNOME based FileTypeDetector - it has the same bug). > > Another illegal MIME type > "app/gg" app isn't a legal type (example: Documents\My Google > Gadgets\Analog Clock-Google.gg) The syntax is okay in this case so it okay for a FileTypeDetector to return it. -Alan. From Alan.Bateman at Sun.COM Sun Jul 13 09:11:50 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 13 Jul 2008 17:11:50 +0100 Subject: WatchKey#PollEvents() returning more events than expected In-Reply-To: <29b165210807100602h4ed641a7nc4b03d3d8535d15f@mail.gmail.com> References: <486C9A39.1010009@sun.com> <29b165210807100602h4ed641a7nc4b03d3d8535d15f@mail.gmail.com> Message-ID: <487A2946.4040600@sun.com> Tony Childs wrote: > Thank you for your help. I don't know how I missed note about > ENTRY_MODIFY in the Javadoc. > > Regarding my second issue, I am creating the file using Windows (XP) > Explorer (File-->New-->Text Document). I'm guessing this is an OS > behavior as well. Windows Explorer initially creates a file named "New Text Document.txt" or some such before you name the file so this should explain the sequence of events you observe. To verify this you could try the WatchDir sample in the %JDK_HOME%\sample\nio\file directory as it prints the context for each event. As Umashankar suggested, you can also observe "unexpected" events on other platforms where editors create foo~ or other backup/temporary files. -Alan, From Alan.Bateman at Sun.COM Mon Jul 14 04:41:04 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 14 Jul 2008 12:41:04 +0100 Subject: abstract paths In-Reply-To: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> Message-ID: <487B3B50.5040102@sun.com> Alan Snyder wrote: > Thanks to the article by Elliotte Harold, I have become aware of this > work. I want to say that it is long overdue and will be much appreciated. > > I want to make a pitch for supporting fully abstract paths, that is, > paths that are not bound to any file system or file system > implementation. A fully abstract path is simply a sequence of names. > Before it can be used to access a resource, it must be presented to a > file system (which might convert it to a bound path as in the current > design). As Mark suggests, this probably only makes sense for paths that don't have a root component. In that case, the path is simply a sequence of names. In that case, the only awkward issue is how to represent those names. If you can live with Strings (recalling that converting from the platform representation to String may be lossy, at least on platforms where representation is bytes) then List or String[], as Mark suggests, might be okay. Since Path already implements Iterable and defines the resolve(String) method it means you should be able to try this out now (yes, it would be a bit inefficient but if this is generally useful then we could define methods to import/export as a sequence of names). > > Fully abstract paths can be useful whenever you are performing cross > file system operations, such as mirroring. The same relative fully > abstract path can be presented to two file systems to access resources > that correspond by name. Fully abstract paths could also be used in a > catalog (as might be created by a backup program), which stores > metadata but does not contain the actual files. I'm interested in hearing about the mirroring - are you thinking about mirroring directory structures between file systems associated with different providers? -Alan. From Alan.Bateman at Sun.COM Thu Jul 17 04:26:47 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 17 Jul 2008 12:26:47 +0100 Subject: Anyone tried the multicast support yet? Message-ID: <487F2C77.90204@sun.com> I'm wondering if anyone on this mailing list has tried the multicast and other socket-channel changes yet? While somewhat niche, many developers have been being asking for this feature for many years. If you are willing to try it out then the javadoc, source code, and binaries are available via the project page [1]. To re-cap, the updates allow a DatagramChannel's socket join multicast groups so that multicast datagrams can be received. We've used the opportunity to update the multicast support to the most recent IEFT standards and specifically source-specific multicast (IGMPv3 and MLDv2). Implementation changes include support for the new IPv6 stack on Windows Vista, something that would also be useful to get feedback on. My motive for asking for feedback at this time is that we would like to push the changes for this part of the API to the jdk7 repository soon. The reason for this is make it easier to merge and stay in sync with other bug fixing other in the channels area. Also, there is other on-going work that has dependencies on the changes in the API and implementation changes in the nio repository. If you are interested in trying it then there is some sample code in the $JDK_HOME/sample/nio/multicast directory that exercises the API. This also demonstrates inclusive and exclusive mode filtering for those interesting in trying that out. Thank you, Alan. [1] http://openjdk.java.net/projects/nio From javalists at cbfiddle.com Thu Jul 17 08:04:56 2008 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 17 Jul 2008 08:04:56 -0700 Subject: abstract paths In-Reply-To: <487B3B50.5040102@sun.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> Message-ID: It is not obvious to me that abstract pathnames are meaningful only for relative path names. No argument has been made to justify this claim. Two possible counterexamples: 1. A backup program that creates a catalog of a snapshot of a file system could record absolute paths in the catalog. 2. Copying a file from one file system to another could use the same absolute path for both the source and the destination. A current example of copying between two file systems (providers) would be mirroring files onto an FTP host. (I believe that incremental backup and FTP mirroring are basically equivalent and can be implemented using a common core.) (Perhaps there is a question of how seriously to take the possibility of multiple file system providers. One direction is to assume that the native file system provider will be the interface of choice to all file systems. However, since the API allows multiple providers, I'm assuming this feature is intended to be supported and useful.) I understand that an abstract pathname can be represented as a list of strings, and making the conversion easier is a good idea. I also understand that there is nothing to stop me from creating my own abstract path class (which I have done already). However, since my abstract path class is so close to (a subset of) the Path class in this project, it seems odd not to be able to use a standard class for this purpose. Is there an objection other than a desire to limit change to the API? Is there a document that explains the design rationale? On Jul 14, 2008, at 4:41 AM, Alan Bateman wrote: > Alan Snyder wrote: >> Thanks to the article by Elliotte Harold, I have become aware of >> this work. I want to say that it is long overdue and will be much >> appreciated. >> >> I want to make a pitch for supporting fully abstract paths, that >> is, paths that are not bound to any file system or file system >> implementation. A fully abstract path is simply a sequence of >> names. Before it can be used to access a resource, it must be >> presented to a file system (which might convert it to a bound path >> as in the current design). > As Mark suggests, this probably only makes sense for paths that > don't have a root component. In that case, the path is simply a > sequence of names. In that case, the only awkward issue is how to > represent those names. If you can live with Strings (recalling that > converting from the platform representation to String may be lossy, > at least on platforms where representation is bytes) then > List or String[], as Mark suggests, might be okay. Since > Path already implements Iterable and defines the > resolve(String) method it means you should be able to try this out > now (yes, it would be a bit inefficient but if this is generally > useful then we could define methods to import/export as a sequence > of names). >> >> Fully abstract paths can be useful whenever you are performing >> cross file system operations, such as mirroring. The same relative >> fully abstract path can be presented to two file systems to access >> resources that correspond by name. Fully abstract paths could also >> be used in a catalog (as might be created by a backup program), >> which stores metadata but does not contain the actual files. > I'm interested in hearing about the mirroring - are you thinking > about mirroring directory structures between file systems associated > with different providers? > > -Alan. From mthornton at optrak.co.uk Thu Jul 17 08:17:42 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Thu, 17 Jul 2008 16:17:42 +0100 Subject: abstract paths In-Reply-To: References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> Message-ID: <487F6296.4050501@optrak.co.uk> Alan Snyder wrote: > It is not obvious to me that abstract pathnames are meaningful only > for relative path names. No argument has been made to justify this claim. The syntax for the root of a path is file system specific, so any abstractness is blown whenever the root is included. So an absolute path can only really be applied to a system with a compatible file system, in which case why not just use the regular path? > > 2. Copying a file from one file system to another could use the same > absolute path for both the source and the destination. A current > example of copying between two file systems (providers) would be > mirroring files onto an FTP host. Usually you send the path relative to some place on the source system and resolve it relative to a different path on the destination system. If you are mirroring between identical systems then you don't need an AbstractPath as a regular Path will work. Mark Thornton From javalists at cbfiddle.com Thu Jul 17 08:39:24 2008 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 17 Jul 2008 08:39:24 -0700 Subject: abstract paths In-Reply-To: <487F6296.4050501@optrak.co.uk> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> Message-ID: <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> The kind of abstractness I am referring to is lack of binding to a provider. Consider two file systems of the same kind (e.g. Windows) accessed through different providers (native file system and FTP). The same fully qualified absolute path can be used in both cases, but the providers are different, so a regular Path will not work. On Jul 17, 2008, at 8:17 AM, Mark Thornton wrote: > Alan Snyder wrote: >> It is not obvious to me that abstract pathnames are meaningful only >> for relative path names. No argument has been made to justify this >> claim. > The syntax for the root of a path is file system specific, so any > abstractness is blown whenever the root is included. So an absolute > path can only really be applied to a system with a compatible file > system, in which case why not just use the regular path? > >> >> 2. Copying a file from one file system to another could use the >> same absolute path for both the source and the destination. A >> current example of copying between two file systems (providers) >> would be mirroring files onto an FTP host. > Usually you send the path relative to some place on the source > system and resolve it relative to a different path on the > destination system. If you are mirroring between identical systems > then you don't need an AbstractPath as a regular Path will work. > > Mark Thornton From mthornton at optrak.co.uk Thu Jul 17 08:50:49 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Thu, 17 Jul 2008 16:50:49 +0100 Subject: abstract paths In-Reply-To: <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> Message-ID: <487F6A59.2020405@optrak.co.uk> Alan Snyder wrote: > The kind of abstractness I am referring to is lack of binding to a > provider. > > Consider two file systems of the same kind (e.g. Windows) accessed > through different providers (native file system and FTP). The same > fully qualified absolute path can be used in both cases, but the > providers are different, so a regular Path will not work. > How common is it for an FTP server to allow the use of absolute paths (which map 1-1 to the system path)? In any case, if the file systems are compatible the String form of the Path could be used as an unbound path. There is very little you can actually do with an unbound path --- many operations require the file system to be meaningful. Mark Thornton From Alan.Bateman at Sun.COM Thu Jul 17 09:52:27 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 17 Jul 2008 17:52:27 +0100 Subject: abstract paths In-Reply-To: References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> Message-ID: <487F78CB.1070104@sun.com> Alan Snyder wrote: > It is not obvious to me that abstract pathnames are meaningful only > for relative path names. No argument has been made to justify this claim. Perhaps I mis-understand your original mail, but weren't you asking for a way to represent a path that wasn't tied to a file system or provider? If so, then any path with a root component (say "C:" or "D:\" or "\\server\share" or "disk$:" for example) isn't going to readily translate between providers or into a provider-independent form that you require. The other complication is of course that you may loose the internal representation (many file systems use bytes rather than Unicode strings for example). > > Two possible counterexamples: > > 1. A backup program that creates a catalog of a snapshot of a file > system could record absolute paths in the catalog. I don't see any issue here. > > 2. Copying a file from one file system to another could use the same > absolute path for both the source and the destination. A current > example of copying between two file systems (providers) would be > mirroring files onto an FTP host. The copyTo method can be used to copy between providers. The only restriction is that some of the meta data may not be copied (because it don't make sense to the target file system). You can try this out now with the zip provider to copy files from a zip file system to the default file system for example. The source and target can be absolute paths. When you copy from /dir/foo to C:\dir\foo then the paths aren't the same though (meaning they aren't equal but the String representation of the names may be equal). > > (I believe that incremental backup and FTP mirroring are basically > equivalent and can be implemented using a common core.) > > (Perhaps there is a question of how seriously to take the possibility > of multiple file system providers. We do expect there will be multiple providers available although the number will likely be small. Today we don't have a good solution on how to translate paths between providers (except for Strings which you can use now). > One direction is to assume that the native file system provider will > be the interface of choice to all file systems. However, since the API > allows multiple providers, I'm assuming this feature is intended to be > supported and useful.) > > I understand that an abstract pathname can be represented as a list of > strings, and making the conversion easier is a good idea. It may be "good enough" for most cases but in the longer term we may need to allow for other representations (bytes in particulars). > > I also understand that there is nothing to stop me from creating my > own abstract path class (which I have done already). However, since my > abstract path class is so close to (a subset of) the Path class in > this project, it seems odd not to be able to use a standard class for > this purpose. > > Is there an objection other than a desire to limit change to the API? > Is there a document that explains the design rationale? Could you expand a bit further on what your abstract path is? (from your original mail I gathered it's a sequence of names but perhaps there is more). -Alan. From Alan.Bateman at Sun.COM Thu Jul 17 11:45:19 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 17 Jul 2008 19:45:19 +0100 Subject: abstract paths In-Reply-To: <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> Message-ID: <487F933F.4040207@sun.com> Alan Snyder wrote: > The kind of abstractness I am referring to is lack of binding to a > provider. > > Consider two file systems of the same kind (e.g. Windows) accessed > through different providers (native file system and FTP). The same > fully qualified absolute path can be used in both cases, but the > providers are different, so a regular Path will not work. > If you somehow know that the ftp server is on Windows and allows access to the complete file system using Windows path syntax then this should do it: Path source = FileSystems.getDefault().getPath("C:\\dir\\foo"); Path target = ftpFileSystem.getPath(source.getRoot().toString()); for (Path name: source) { target = target.resolve(name.toString()); } source.copyTo(target); This isn't as efficient as it might be (as I mentioned in my first reply) but should do what you want. -Alan. From javalists at cbfiddle.com Thu Jul 17 16:32:03 2008 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 17 Jul 2008 16:32:03 -0700 Subject: abstract paths In-Reply-To: <487F933F.4040207@sun.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> Message-ID: <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> Well, there does seem to be a disconnect. I am arguing for something that would seem to me to be useful (since I have already found a need to implement a class of my own just like it), would be easy to do (since it is a subset of what is already present), would not break anything, but is not essential because it can be done using strings. The arguments against seem to be either (1) it is not useful, or (2) it is not useful enough, or (3) it is not essential because it can be done using strings. I don't think I've heard that it would be hard to do or that it would break something. An abstract path (in my view) is a sequence of names, that may also have a root name, and that is either absolute or relative. I did not notice this before, but the difference that I now see from Path is that Path.getName(index) and Path.getRoot() return Paths rather than Strings, although I presume that one can use the toString() method on the returned Paths to get these components as strings. I also assume that the above components are a complete abstract description of a Path in its role as a name. In other words, if you deconstruct a path into these components and then reconstruct it (using the same provider), the result would be an equivalent Path. If this is wrong, do say so (and put it in the documentation). In my view, the binding of a Path to a provider does two categories of things, which are separable: (1) Syntactic things, such as defining an external representation for a Path, defining components with special interpretations such as "." and "..", and perhaps imposing restrictions on the values of components. (2) Supporting operations that need to access the file system, such as operating on the file itself, operating on the file metadata, and converting relative Paths to absolute Paths. My concept of abstract Path imposes no restrictions on the values of components, and does not directly support access to any file system. It is just a structured name, already parsed so that programs do not have to use strings. This is primarily a matter of convenience. I suppose one could write a support class that converts a path from one FileSystem to another, following your example. The following Path methods should work on an abstract Path: compareTo equals endsWith getName(both versions) getNameCount getParent getRoot isAbsolute relativize (at least in the simple case) resolve (at least in the simple case) startsWith subpath toString (using a platform dependent syntax) iterator (assuming that this method returns the Name components, the doc does not say) One could argue about collapse(), since "." and ".." are not universal. From mthornton at optrak.co.uk Fri Jul 18 00:40:57 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Fri, 18 Jul 2008 08:40:57 +0100 Subject: abstract paths In-Reply-To: <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> Message-ID: <48804909.5060907@optrak.co.uk> Alan Snyder wrote: > > The following Path methods should work on an abstract Path: > > compareTo > equals > endsWith > startsWith These are all provider dependent. > > One could argue about collapse(), since "." and ".." are not universal. similarly resolve and relativize. Mark Thornton From Alan.Bateman at Sun.COM Fri Jul 18 01:30:53 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 18 Jul 2008 09:30:53 +0100 Subject: abstract paths In-Reply-To: <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> Message-ID: <488054BD.7090106@sun.com> Alan Snyder wrote: > Well, there does seem to be a disconnect. I am arguing for something > that would seem to me to be useful (since I have already found a need > to implement a class of my own just like it), would be easy to do > (since it is a subset of what is already present), would not break > anything, but is not essential because it can be done using strings. > The arguments against seem to be either (1) it is not useful, or (2) > it is not useful enough, or (3) it is not essential because it can be > done using strings. I don't think I've heard that it would be hard to > do or that it would break something. The disconnect may be because it got tied to the discussion as to how to convert a path from one file system into a path suitable for a completely different file system. In any case, the suggestion to group the path related methods into an interface that Path implements seems to be reasonable suggestion to consider. This isn't an easy to do as it might seem. For example, would you expect to be able to match or compare abstract paths? Are methods such as isAbsolute feasible? (for example "/foo" is an absolute path on many file systems but a relative path on Windows). Resolving (or joining) paths can't be done without some knowledge of the platform or file system. What remains is something that would simply represent a sequence of names. That might be okay but perhaps not as useful as you'd want. It would be useful if you could outline the of operations you would expect do with such a path (would you expect to store them in collections for example?). > > An abstract path (in my view) is a sequence of names, that may also > have a root name, and that is either absolute or relative. I did not > notice this before, but the difference that I now see from Path is > that Path.getName(index) and Path.getRoot() return Paths rather than > Strings, although I presume that one can use the toString() method on > the returned Paths to get these components as strings. Correct, and the reason that methods such as getName don't return a String is because this would cause the platform representation to be lost. > > I also assume that the above components are a complete abstract > description of a Path in its role as a name. In other words, if you > deconstruct a path into these components and then reconstruct it > (using the same provider), the result would be an equivalent Path. Correct. > : > My concept of abstract Path imposes no restrictions on the values of > components, and does not directly support access to any file system. > It is just a structured name, already parsed so that programs do not > have to use strings. This kinda sounds like a type that encapsulates an array of Strings - is that right? -Alan. From mthornton at optrak.co.uk Fri Jul 18 01:46:29 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Fri, 18 Jul 2008 09:46:29 +0100 Subject: abstract paths In-Reply-To: <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> Message-ID: <48805865.5080302@optrak.co.uk> Alan Snyder wrote: > I also assume that the above components are a complete abstract > description of a Path in its role as a name. In other words, if you > deconstruct a path into these components and then reconstruct it > (using the same provider), the result would be an equivalent Path. > > If this is wrong, do say so (and put it in the documentation). I think there are instances of File such that new File(f.toString()) is not equal to the original file 'f' (and in fact doesn't work at all). JFileChooser can return such objects on Windows. These files represent paths based on locations like "My Documents". Windows has never defined a programmatic string form for these paths. It would be rather useful if we had a way to obtain such 'roots' as Paths (as the actual underlying location can vary; i.e. "My Documents" isn't always called that). Mark Thornton From Alan.Bateman at Sun.COM Fri Jul 18 03:40:43 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 18 Jul 2008 11:40:43 +0100 Subject: desktop provider (was "Re: abstract paths") In-Reply-To: <48805865.5080302@optrak.co.uk> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> <48805865.5080302@optrak.co.uk> Message-ID: <4880732B.7010502@sun.com> Mark Thornton wrote: > I think there are instances of File such that > new File(f.toString()) > is not equal to the original file 'f' (and in fact doesn't work at > all). JFileChooser can return such objects on Windows. These files > represent paths based on locations like "My Documents". Windows has > never defined a programmatic string form for these paths. It would be > rather useful if we had a way to obtain such 'roots' as Paths (as the > actual underlying location can vary; i.e. "My Documents" isn't always > called that). Someday it would be great to have a "desktop provider" that uses the shell API and handles the various desktop/shell concepts like this. It would delegate to the default provider for actual access to the file system. A desktop file system could treat these special shell folders as root directories, it could handle short cuts, it could allow the progress of copy/move operations to be monitored, map content types to icons, etc. It would be great to find a volunteer for this. -Alan. From mthornton at optrak.co.uk Fri Jul 18 03:48:43 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Fri, 18 Jul 2008 11:48:43 +0100 Subject: desktop provider (was "Re: abstract paths") In-Reply-To: <4880732B.7010502@sun.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> <48805865.5080302@optrak.co.uk> <4880732B.7010502@sun.com> Message-ID: <4880750B.4080500@optrak.co.uk> Alan Bateman wrote: > Mark Thornton wrote: >> I think there are instances of File such that >> new File(f.toString()) >> is not equal to the original file 'f' (and in fact doesn't work at >> all). JFileChooser can return such objects on Windows. These files >> represent paths based on locations like "My Documents". Windows has >> never defined a programmatic string form for these paths. It would be >> rather useful if we had a way to obtain such 'roots' as Paths (as the >> actual underlying location can vary; i.e. "My Documents" isn't always >> called that). > Someday it would be great to have a "desktop provider" that uses the > shell API and handles the various desktop/shell concepts like this. It > would delegate to the default provider for actual access to the file > system. A desktop file system could treat these special shell folders > as root directories, it could handle short cuts, it could allow the > progress of copy/move operations to be monitored, map content types to > icons, etc. It would be great to find a volunteer for this. > > -Alan. A related issue is finding suitable locations for log files, caches, general program data, etc. Many operating systems have standard locations for these purposes, but they differ from each other. This of course is also relevant for server applications. I have implemented something of this sort (a bit crude, Windows, Linux only). Mark From javalists at cbfiddle.com Tue Jul 22 13:58:39 2008 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 22 Jul 2008 13:58:39 -0700 Subject: abstract paths In-Reply-To: <488054BD.7090106@sun.com> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> <488054BD.7090106@sun.com> Message-ID: I'll try to respond to all the comments at once, since they seem to be related. What I have in mind when I say abstract path (I'll call it AbstractPath for now, even though the name is already taken) is a type whose attributes are (1) a sequence of Strings, (2) an optional String representing a Root, (3) a boolean indicating whether the path is absolute or relative. There would need to be a way of constructing an AbstractPath from these attributes as separate objects (this is not the same as parsing a single string). There would need to be a method on Path that directly converts a bound Path to an AbstractPath, preserving the interpretation of the Path, such as whether it is absolute or relative (i.e., not necessarily just unparsing and parsing it). There should probably be a method on a FileSystem that takes an AbstractPath and returns a bound Path, again, preserving the original interpretation rather than unparsing and parsing. I would expect the following code Path p1; // already obtained from somewhere AbstractPath a = p1.toAbstractPath(); FileSystem fs = p1.getFileSystem(); Path p2 = fs.bind(a); to result in p1.equals(p2) being true. I would expect the methods I listed in my previous email to work on AbstractPaths without using any provider-dependent code. I would expect that the methods on AbstractPaths would mirror the equivalent methods on the bound Paths. (If I remember my college math, the mapping is a homeomorphism. :-) ) There may be cases where an operation that the bound Path can do (such as resolve using a relative path having a root) is either rejected by AbstractPath or does something different. I don't see that as a problem, but I'm not sure I understand enough about possible provider dependent behaviors. I would expect AbstractPaths to interoperate with bound Paths wherever that makes sense. In particular, it should work in the simple cases, such as passing a relative, rootless AbstractPath as a parameter to resolve() on a bound Path. (In current cases of interoperation between Paths from different providers, an AbstractPath would be the ideal intermediate form, would it not?) One place where I would use AbstractPaths is in situations where I want to make sure my code does not access the actual file system. For a file catalog, I might create a subclass of (my) AbstractPath that can return file metadata (from the catalog). The file catalog program needs to serialize AbstractPaths when writing the catalog, but when it runs, it should not need to be doing any parsing of paths. Hopefully, it is now obvious that "/foo" is not an AbstractPath, it is a string. When an AbstractPath is created, the absolute/relative attribute must be specified. (It sounds like the "My Documents" example would be best handled using a symbolic root. In other words, the Windows provider might support a root of "${MY_DOCUMENTS}" just as the Unix provider might support a root of "${HOME}". Just a thought, and a separate topic, I believe.) On Jul 18, 2008, at 1:30 AM, Alan Bateman wrote: > > In any case, the suggestion to group the path related methods into > an interface that Path implements seems to be reasonable suggestion > to consider. This isn't an easy to do as it might seem. For example, > would you expect to be able to match or compare abstract paths? Are > methods such as isAbsolute feasible? (for example "/foo" is an > absolute path on many file systems but a relative path on Windows). > Resolving (or joining) paths can't be done without some knowledge of > the platform or file system. What remains is something that would > simply represent a sequence of names. That might be okay but perhaps > not as useful as you'd want. It would be useful if you could outline > the of operations you would expect do with such a path (would you > expect to store them in collections for example?). > >> My concept of abstract Path imposes no restrictions on the values >> of components, and does not directly support access to any file >> system. It is just a structured name, already parsed so that >> programs do not have to use strings. > This kinda sounds like a type that encapsulates an array of Strings > - is that right? > > -Alan. From mthornton at optrak.co.uk Tue Jul 22 14:29:40 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Tue, 22 Jul 2008 22:29:40 +0100 Subject: abstract paths In-Reply-To: References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> <488054BD.7090106@sun.com> Message-ID: <48865144.5040301@optrak.co.uk> Alan Snyder wrote: > I'll try to respond to all the comments at once, since they seem to be > related. > > What I have in mind when I say abstract path (I'll call it > AbstractPath for now, even though the name is already taken) is a type > whose attributes are (1) a sequence of Strings, (2) an optional String > representing a Root, (3) a boolean indicating whether the path is > absolute or relative. There would need to be a way of constructing an > AbstractPath from these attributes as separate objects (this is not > the same as parsing a single string). There would need to be a method > on Path that directly converts a bound Path to an AbstractPath, > preserving the interpretation of the Path, such as whether it is > absolute or relative (i.e., not necessarily just unparsing and parsing > it). There should probably be a method on a FileSystem that takes an > AbstractPath and returns a bound Path, again, preserving the original > interpretation rather than unparsing and parsing. > > I would expect the following code > > Path p1; // already obtained from somewhere > AbstractPath a = p1.toAbstractPath(); > FileSystem fs = p1.getFileSystem(); > Path p2 = fs.bind(a); > > to result in p1.equals(p2) being true. > > I would expect the methods I listed in my previous email to work on > AbstractPaths without using any provider-dependent code. How well does a URI match what you expect of an abstract path? It seems to me that you are looking for a universal path form (not to be confused with UNC). Mark Thornton From javalists at cbfiddle.com Tue Jul 22 15:03:04 2008 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 22 Jul 2008 15:03:04 -0700 Subject: abstract paths In-Reply-To: <48865144.5040301@optrak.co.uk> References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> <488054BD.7090106@sun.com> <48865144.5040301@optrak.co.uk> Message-ID: A similar idea, but differing in the details. Extra attributes, no parsing of the path attribute. Did you consider using any of the java.net classes in your design? Alan On Jul 22, 2008, at 2:29 PM, Mark Thornton wrote: > How well does a URI match what you expect of an abstract path? It > seems to me that you are looking for a universal path form (not to > be confused with UNC). > > Mark Thornton From Alan.Bateman at Sun.COM Wed Jul 23 00:54:58 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 23 Jul 2008 08:54:58 +0100 Subject: abstract paths In-Reply-To: References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> <488054BD.7090106@sun.com> <48865144.5040301@optrak.co.uk> Message-ID: <4886E3D2.7020709@sun.com> Alan Snyder wrote: > A similar idea, but differing in the details. Extra attributes, no > parsing of the path attribute. > > Did you consider using any of the java.net classes in your design? > Just URI, and there are methods to convert between Paths and URIs. -Alan. From Alan.Bateman at Sun.COM Wed Jul 23 03:00:12 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 23 Jul 2008 11:00:12 +0100 Subject: abstract paths In-Reply-To: References: <48173D76-3009-432E-80BD-2715521C9448@cbfiddle.com> <487B3B50.5040102@sun.com> <487F6296.4050501@optrak.co.uk> <6C1D2CA4-6DC4-40F7-A53F-3B7FAEF861E1@cbfiddle.com> <487F933F.4040207@sun.com> <5473480D-7C4A-4DAB-99F7-A358BBF0DA1B@cbfiddle.com> <488054BD.7090106@sun.com> Message-ID: <4887012C.9020307@sun.com> Alan Snyder wrote: > I'll try to respond to all the comments at once, since they seem to be > related. > > What I have in mind when I say abstract path (I'll call it > AbstractPath for now, even though the name is already taken) is a type > whose attributes are (1) a sequence of Strings, (2) an optional String > representing a Root, (3) a boolean indicating whether the path is > absolute or relative. There would need to be a way of constructing an > AbstractPath from these attributes as separate objects (this is not > the same as parsing a single string). There would need to be a method > on Path that directly converts a bound Path to an AbstractPath, > preserving the interpretation of the Path, such as whether it is > absolute or relative (i.e., not necessarily just unparsing and parsing > it). There should probably be a method on a FileSystem that takes an > AbstractPath and returns a bound Path, again, preserving the original > interpretation rather than unparsing and parsing. > > I would expect the following code > > Path p1; // already obtained from somewhere > AbstractPath a = p1.toAbstractPath(); > FileSystem fs = p1.getFileSystem(); > Path p2 = fs.bind(a); Maybe the best thing is to try it out. As it doesn't require anything special in the java.nio.file package to prototype this then maybe you could try it and send back your experiences. The following will do the conversion you are looking for (as I mentioned in a previous mail this isn't as efficient as it could be but should be good enough to try). private final String root; private final String[] names; private final boolean isAbsolute; AbstractPath(Path path) { this.root = (path.getRoot() != null) ? path.getRoot().toString() : null; int count = path.getNameCount(); this.names = new String[count]; for (int i=0; i > to result in p1.equals(p2) being true. Unfortunately, you couldn't guarantee this with a round trip as the conversion to a String may cause the platform representation to be lost. > > I would expect the methods I listed in my previous email to work on > AbstractPaths without using any provider-dependent code. In that case, equals, compareTo, startsWith, and endsWith would be String operations and so would behave differently to the equivalent methods defined by Path. > > I would expect that the methods on AbstractPaths would mirror the > equivalent methods on the bound Paths. (If I remember my college math, > the mapping is a homeomorphism. :-) ) There may be cases where an > operation that the bound Path can do (such as resolve using a relative > path having a root) is either rejected by AbstractPath or does > something different. I don't see that as a problem, but I'm not sure I > understand enough about possible provider dependent behaviors. You could implement resolve for two cases: (i) the given AbstractPath is absolute in which case the result is the given AbstractPath, and (ii) the given AbstractPath does not have a root component in which case this is a simply join. I don't think other cases are feasible. Relativization is likely to be only feasible for limited cases too. > > I would expect AbstractPaths to interoperate with bound Paths wherever > that makes sense. In particular, it should work in the simple cases, > such as passing a relative, rootless AbstractPath as a parameter to > resolve() on a bound Path. (In current cases of interoperation between > Paths from different providers, an AbstractPath would be the ideal > intermediate form, would it not?) As I mentioned previously, we don't currently have a good solution on how to convert a path from a file system to an "equivalent" path in a different type of file system. Converting to Strings, while not ideal, is probably good enough for most needs. > > One place where I would use AbstractPaths is in situations where I > want to make sure my code does not access the actual file system. For > a file catalog, I might create a subclass of (my) AbstractPath that > can return file metadata (from the catalog). The file catalog program > needs to serialize AbstractPaths when writing the catalog, but when it > runs, it should not need to be doing any parsing of paths. > > Hopefully, it is now obvious that "/foo" is not an AbstractPath, it is > a string. When an AbstractPath is created, the absolute/relative > attribute must be specified. > > (It sounds like the "My Documents" example would be best handled using > a symbolic root. In other words, the Windows provider might support a > root of "${MY_DOCUMENTS}" just as the Unix provider might support a > root of "${HOME}". Just a thought, and a separate topic, I believe.) Someday it would be good to have a desktop provider that knows about virtual folders and other desktop/shell concepts. -Alan. From Alan.Bateman at Sun.COM Mon Jul 28 07:52:18 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 28 Jul 2008 15:52:18 +0100 Subject: nio2 build 93 available Message-ID: <488DDD22.1070206@sun.com> Thanks to everyone that has been trying out the builds and sending feedback and bug reports over the last few weeks. Xiomara has pushed an updated build (b93) for us to the download area [1]. This build is sync'ed with jdk7 build 31 and contains a small number of bug fixes [2] since the previous build. Regards, -Alan. [1] http://download.java.net/jdk7/jsr203/binaries [2] http://openjdk.java.net/projects/nio/changes/nio2-b93.html From studdugie at gmail.com Mon Jul 28 11:43:35 2008 From: studdugie at gmail.com (studdugie) Date: Mon, 28 Jul 2008 14:43:35 -0400 Subject: nio2 build 93 available In-Reply-To: <488DDD22.1070206@sun.com> References: <488DDD22.1070206@sun.com> Message-ID: <5a59ce530807281143y70902389y167c64e2e9780f2a@mail.gmail.com> Is there any way to get NIO2 w/o JDK 7? On Mon, Jul 28, 2008 at 10:52 AM, Alan Bateman wrote: > > Thanks to everyone that has been trying out the builds and sending feedback > and bug reports over the last few weeks. Xiomara has pushed an updated build > (b93) for us to the download area [1]. This build is sync'ed with jdk7 build > 31 and contains a small number of bug fixes [2] since the previous build. > > Regards, > > -Alan. > > [1] http://download.java.net/jdk7/jsr203/binaries > [2] http://openjdk.java.net/projects/nio/changes/nio2-b93.html > > From Alan.Bateman at Sun.COM Mon Jul 28 13:01:17 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 28 Jul 2008 21:01:17 +0100 Subject: nio2 build 93 available In-Reply-To: <5a59ce530807281143y70902389y167c64e2e9780f2a@mail.gmail.com> References: <488DDD22.1070206@sun.com> <5a59ce530807281143y70902389y167c64e2e9780f2a@mail.gmail.com> Message-ID: <488E258D.7070302@sun.com> studdugie wrote: > Is there any way to get NIO2 w/o JDK 7? > This came up on the nio-dev mailing list a few weeks ago too. This API targets jdk7 and we don't plan to release a standalone version. There is some interest in using the file system API with existing JDK releases and to that end, Kevin Bourrillion (Google) has been looking into back-porting this part for use with jdk6 on Linux. I'm not aware of any efforts to back-port other areas of the API. -Alan.