Investigate better use of java.nio.file.Path in our JavaIoFilesystem

[philwo]

Taras suggested the following on bazel-dev:

when implementing JavaIoFilesystem methods you frequently use java.nio.file.Path, but instead of directly creating a java.nio.file.Path an extra allocation is used everywhere file.toPath() is used. In other words I'm only talking about implementation details - not changes to APIs. The other advantage I see is that if java.nio.file.Path was used instead of java.io.File, it would be possible to implement InMemoryFilesystem by just overriding a newly suggested getNioPath() method and jimfs would do the rest, which has an advantage of having to maintain one fewer FS implementations in Bazel :)

On a related note, I've noticed that some methods, like delete can be replaced with standard library functions like Files.delete and getDirectoryEntries can be implemented using Files.list. I'm guessing that it's because this filesystem implementation had to support older Java versions. Does anyone have any objections to migrate or at least add an additional getNioPath method in addition to getIoFile that can be used by methods that operate on java.nio.file.Path instead of java.io.File?

I'll look into this.

[aiuto]

Is this really a P2?
What team should own it?

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen (or ping me to reopen) if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.