The current API still uses java.io.File in several objects. Java 7 provided the java.nio.Path object which has richer semantics than the older java.io class. Without support for the newer class, the API appears dated.
I'd like to see support for using java.nio.Path objects added to the FileDataSource constructors. I'd like to see the internal implementation changed to use the java.nio APIs. The existing constructor that uses the File object can be retained but marked in the javadocs that the Path constructor should be preferred.
Additionally, new methods could be added to the FileTypeMap and MimetypesFileTypeMap classes to accept java.nio.Path objects in addition to the existing methods that accept java.io.File objects. Again, the javadocs for the methods that accept File object should be altered to indicate that the methods that take Path objects should be preferred.
The current API still uses
java.io.Filein several objects. Java 7 provided thejava.nio.Pathobject which has richer semantics than the olderjava.ioclass. Without support for the newer class, the API appears dated.I'd like to see support for using
java.nio.Pathobjects added to theFileDataSourceconstructors. I'd like to see the internal implementation changed to use thejava.nioAPIs. The existing constructor that uses theFileobject can be retained but marked in the javadocs that thePathconstructor should be preferred.Additionally, new methods could be added to the
FileTypeMapandMimetypesFileTypeMapclasses to acceptjava.nio.Pathobjects in addition to the existing methods that acceptjava.io.Fileobjects. Again, the javadocs for the methods that acceptFileobject should be altered to indicate that the methods that takePathobjects should be preferred.