Deprecate java.io.File or at least some methods
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
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. Stephen On 6 August 2018 at 13:15, Remi Forax <forax@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
On Fri, Aug 10, 2018, 09:25 Stephen Colebourne <scolebourne@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@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
I'd venture to suggest File is more widely used because it was around from the beginning, whereas Path is significantly more recent. Once you know to look on the Files API, using Path is generally easy and way preferable. -- Jon On 08/10/2018 08:23 AM, Stephen Colebourne 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.
Stephen
On 6 August 2018 at 13:15, Remi Forax <forax@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
participants (4)
-
Gary Gregory
-
Jonathan Gibbons
-
Remi Forax
-
Stephen Colebourne