Flag Path.toFile() calls as WARNING

[hakanai]

Description of the problem / feature request:

Usage of Path.toFile() should be introduced as WARNING due to frequent misunderstandings of its behaviour.

Feature requests: what underlying problem are you trying to solve with this feature?

In code review I often find code where a Path has been passed in, and they want to pass it to an API which only accepts File, and the developer has thought Path.toFile() to be a convenient conversion.

The reality is that Path.toFile() breaks the abstraction of the Path API, defeating most of the purpose of using it. If we start using an in-memory filesystem to provide Path objects in order to speed up tests, calls to toFile() will throw UnsupportedOperationException, and code failing to handle this in a sensible fashion will just break.

So it would be nice if calls to Path.toFile() were treated as WARNING level.

Alternatively, perhaps it could be ERROR if an escape hatch were to be used?

For example, this is bad:

    public ArchiveFile openArchive(Path file) {
        return new ArchiveFile(file.toFile());
    }

This is okay because createTempFile is documented to return a file on the default filesystem:

    public ArchiveFile openArchive(Path file) {
        Path copy = Files.createTempFile();
        Files.copy(file, copy);
        return new ArchiveFile(copy.toFile());
    }

This is what you'd probably do if you wanted the best of both worlds:

    public ArchiveFile openArchive(Path file) {
        try {
            return new ArchiveFile(file.toPath());
        } catch (UnsupportedOperationException e) {
            // Expected situation of the file not being on the default filesystem
            Path copy = Files.createTempFile();
            Files.copy(file, copy);
            return new ArchiveFile(copy.toFile());
        }
    }

(Though both of these carry an interesting question of whose job it is to clean up that temp file.)

Or perhaps this is OK in some situation, though I'm not that fond of it:

    public ArchiveFile openArchive(Path file) {
        try {
            return new ArchiveFile(file.toFile());
        } catch (UnsupportedOperationException e) {
            throw new IllegalArgumentException("You were supposed to copy the file to temp first", e);
        }
    }

[cpovirk]

(Anecdote: Error Prone has to work around a toFile() call inside javac :))

[hakanai]

javac confirmed to be the enemy. :)

[hakanai]

New discovery: Path.toString() is possibly even more evil.

For files on the default filesystem it does what you expect, and if that's all you ever test, you get lulled into a false sense of security. But if someone passes you a Path from inside a zip file, it produces the path from the root of the zip file. If someone then converts that back to Path using Path.of, they will get the wrong result entirely. You could possibly use this to fool some bad code into reading the contents of something like /etc/passwd.

The worst thing is, like most toString() calls, finding all the usages is less than trivial because it can occur inside things like string concatenation.

[hakanai]

And just to complete the set, Path.toUri() is semi-evil.

For any filesystem it produces a URI which can be correctly converted back to Path provided:

1. You do so in the same JVM, and
2. The filesystem has not been closed before you try to do so.