Alan.Bateman at oracle.com
Sat Jun 23 13:44:36 PDT 2012
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).
More information about the nio-dev