On Fri, Aug 10, 2018, 09:25 Stephen Colebourne <[email protected]> wrote:
> From what I can see, File is more widely used than Path. Thats partly > because using Path is non-obvious - it doesn't have any methods for > doing anything. > > I've suggested before that a default method could be added, so you get > > path.operations().isReadable() > path.operations().readAllBytes() > path.operations().delete() > > which would make `Path` more palatable for general use. > +1! Gary > > Stephen > > > On 6 August 2018 at 13:15, Remi Forax <[email protected]> wrote: > > Hi all, > > restarting discussion about JDK-8181098, > > java.io.File has several severe issues so we should alert users to > migrate to use java.nio.file.[Path|Files] ASAP using the deprecation > mechanism (obviously not for removal). > > > > The usual gotchas > > - File used string name which may do not map correctly with the > underlying file system charset. > > - methods that are developer hostile > > - methods that performs an action on the file system file returns a > false if there is an issue instead of an IOException > > - methods that list files return null instead of an IOException if > there is an issue. > > - reading/writing into a file (using > File[InputStream|OutputStream|Reader|Writer]) doesn't default to UTF8. > > > > I see two ways of deprecation, one is to deprecate the whole class, it > has the advantage of making the things clear, the other is to deprecate the > constructors and all methods that acts on the file of the file system. The > later option allows library to still have methods that takes a java.io.File > as parameter if their implementation use toPath() to perform the operations. > > > > regards, > > Rémi > > > > > > > > > > >
