I've been using the java.nio.file.Path API in the last few days and
have found it a little tricky to use. I'd like to understand if the
following ideas were ever considered (to consider whether an issue
should be raised).
Currently, developers create a Path instance and it contains various
methods for managing the path, plus a few that actually access the
filing system. However, for most filing system operations, developers
have to use the static methods on Files. This feels very non-intuitive
and hard to discover. Current code:
Path path = Paths.get("/my/path/to/file.txt");
if (Files.exists(path)) {
boolean dir = Files.isDirectory(path);
...
}
Almost all methods on Files simply obtain the FileSystemProvider from
the FileSystem and invoke methods on that. Why not add a new class
PathOperations that binds the Path to the static methods?
Path path = Paths.get("/my/path/to/file.txt");
if (path.operations().exists()) {
boolean dir = path.operations().isDirectory();
...
}
I can't see any reason why this wouldn't work, but perhaps I'm missing
something obvious. (All methods on Files would need to be replicated
on PathOperations, and maybe Files could be deprecated if the
deprecation tools improve.)
Separately, it is a little tricky grasping the ZIP file system, and
that it needs to be opened and closed separately. Could we see a new
method to indicate if a given path/file can be expanded to another
FileSystem?
if (path.operations().isExpandableToFileSystem()) {
try (FileSystem fs = path.operations().expand()) {
// work with ZIP or similar
}
}
This would be a lot more discoverable with appropriate docs.
BTW, this also relates to Jigsaw as the new JFS provider may make
expandable paths more widely used.
Stephen
