java.io.File vs java.nio.Files which is the preferred in new code?

Question

While writing answers around SO, a user tried pointing out that java.io.File should not be used in new code, instead he argues that the the new object java.nio.Files should be used instead; he linked to this article.

Now I have been developing in Java for several years now, and have not heard this argument before; since reading his post I have been searching, and have not found many other sources that confirm this, and personally, I feel like many of the points argued in the article are weak and that if you know how to read them, errors thrown by the File class will generally tell you exactly what the issue is.

As I am continually developing new code my question is this:

Is this an active argument in the Java community? Is Files preferred over File for new code? What are the major advantages / disadvantages between the two?

Bigwig

One good reason is the utilization of streams for file operations for eg: reading a list of files as a stream rather than an arraylist – Codicil

In case of NIO, Memory Mapped Buffers allow mapping a file directly from the file system (without loading into memory). It would be possible to handle very large files without running out of heap space. – Malamute

Answer 1

The documentation that you linked give the answer:

The java.nio.file package defines interfaces and classes for the Java virtual machine to access files, file attributes, and file systems. This API may be used to overcome many of the limitations of the java.io.File class. The toPath method may be used to obtain a Path that uses the abstract path represented by a File object to locate a file. The resulting Path may be used with the Files class to provide more efficient and extensive access to additional file operations, file attributes, and I/O exceptions to help diagnose errors when an operation on a file fails.

Grandnephew

Answer 2

File has a newer implementation: Path. With a builder Paths.get("..."). And Files has many nice utility functions with better implementations too (move instead of the sometimes failing File.renameTo).

A Path maintains its file system. Hence you can copy out of a zip file system ("jar:file:..... .zip") some path to another file system and vice versa.

File.toPath() may help an incremental transition.

The utilities alone in Files make a move to the newer classes profitable.

Cons