method name

[Michael Hall]

On Jun 23, 2012, at 3:44 PM, Alan Bateman wrote:

> On 23/06/2012 21:04, Michael Hall wrote:
>> :
>> One thing on this. With these nio.2 API's going in a more extensible direction. Wouldn't it make sense to have some of these classes more accessible.
>> For example, it looks like the watch service api's follow a similar pattern of including a Runnable Poller class to handle the threaded concerns. These extend a inaccessible, non-public, internal AbstractPoller class. Getting the threaded part of the code right for performance and scalability concerns would be an important concern in attempting a 3rd party watch services implementation. I would and am imagining. Modeling the existing implementations as much as possible would be helpful?
> cc'ing nio-dev as that is the right place for this discussion.

Fine. I probably should of put it there. I just haven't frequented there as much as OS X port.
> 
> The extensions points are via the provider mechanism, see java.nio.file.spi.FileSystemProvider. I can't quite tell what you are doing but if you are looking to "extend" the default provider without changing it then you will need to create your own FileSystemProvider that sits on what would otherwise be the default provider - see the javadoc in FileSystems.getDefault for the details. Also if you rummage around in the tests then you'll find a skeleton implementation that might get your started.

I have the FileSystemProvider mechanism (fwiw [1]), that I used to provide some extended functionality for Mac specific file attributes (Current api's - Finder, Launch Services, NSFileManager derived, and xattr type extended attributes). I was thinking about a possibly custom provider where sync type functionality would be nice. I immediately thought - well this is where watch services is nice now isn't it? I remembered you had mentioned that OS X could use something better than the current polling api for doing this. kqueue I think you mentioned although I've seen it also said that for OS X FSEvents might be a alternative worth considering. I thought I might take a shot at a 'naive' implementation of these two. A learning experience for the api.

> 
> The AbstractWatch* and AbstractPoller classes in sun.nio.fs provide the base classes for the 4 implementations that we currently have in OpenJDK. I would be very slow about moving them to java.nio.file.spi (which I think is what you are suggesting) because it is a relatively niche area and likely only interesting when porting to a new platform that has such a facility (many operating systems do not have anything and for those platforms we have the portable PollingWatchService).

Yes, my purpose is for the OS X platform. Although it did occur to me that both kqueue and possibly FSEvents could be cross-platform at least to Unix type systems.
> 
> -Alan.

[1] http://www195.pair.com/mik3hall/index.html#macattr