Deprecate java.io.File or at least some methods

[Gary Gregory]

On Fri, Aug 10, 2018, 09:25 Stephen Colebourne <scolebourne at joda.org> 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 <forax at univ-mlv.fr> 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
> >
> >
> >
> >
> >
>