method name

[Alan Bateman]

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.

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.

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).

-Alan.