Any thoughts on this?
Stephen
On 8 August 2016 at 18:29, Stephen Colebourne <scolebou...@joda.org> wrote:
> 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
