[io] Filenames: String or java.io.File?

[Jeremias Maerki <de...@greenmail.ch>]

Working with filenames often means paying attention to the path
separator. java.io.File already does a pretty good job handling that.
Example:

        File f = new File("C:\\Temp");
        f = new File(f, "foo/bar/hello.txt");

This will evaluate nicely to "C:\Temp\foo\bar\hello.txt" on a Windows
machine. (Obviously the statement above doesn't make sense on a unix box.
It's only an illustration.) I expect FileUtils do be equally flexible
and I don't think it is right now.

The issue I'd like to point out is the following: Most of the methods in
FileUtils currently have String parameters. Some have two flavors: once
with java.io.File and once with String. I consider the variant with the
String parameter a convenience method over the one with java.io.File
parameters. In the past I've see a lot of this:

String baseDir = ...
String filename = ...
String fullPath = baseDir + File.pathSeparatorChar + filename;

where you could have written:

File baseDir = ....
String filename = ...
File fullPath = new File(baseDir, filename);

The second variant is less error-prone IMO. I make myself use
java.io.File for every normal file or directory (non-VFS, non-URL stuff)
just to avoid any OS-dependency problems. And it turned out to be a good
move.

Most of the methods in FileUtils should be written based on java.io.File.
But there is a problem: If these methods should also work on URLs (or
maybe some kind of VFS filename), they may fail if implemented that way.
So, the question is: Should we make sure that URLs (as Strings) should
be supported by the methods with String parameters in FileUtils? As for
VFS filenames, the VFS thing should probably have its own set of utility
methods. If yes, we will have to mark methods that support URLs clearly,
because not every method in FileUtils will be able to support them
(cleanDirectory() for example).

Alternatively, we could create a FilenameUtils class that has some of
the same methods from FileUtils but with String parameters and
supporting URL syntax.

I'm not really proposing anything here because I don't have a strong
opinion in either way, yet. But I'd be grateful for any thoughts.

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [io] Filenames: String or java.io.File?

["J.Pietschmann" <j3...@yahoo.de>]

Jeremias Maerki wrote:
> Alternatively, we could create a FilenameUtils class that has some of
> the same methods from FileUtils but with String parameters and
> supporting URL syntax.

Neat idea.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [io] Filenames: String or java.io.File?

[__matthewHawthorne <mh...@alumni.pitt.edu>]

I've had a very rough time in the past dealing with conversions between 
Strings,
URLs, and Files. I think that adding URL support to FileUtils may get 
ugly, it
seems easier to try your suggested FilenameUtils approach. Or, the set of
methods could be defined in a FilenameUtils interface, which would be 
extended
by each file syntax:

FilenameUtils
    URLFilenameUtils
    FileFilenameUtils
    VFSFilenameUtils
   
Each subclass would know how to properly parse the string.

I think that finding a way to break out the String methods will make things
cleaner, FileUtils can just focus on Files, and the other classes can 
also just
focus on one type.

Thoughts?




Jeremias Maerki wrote:

>Working with filenames often means paying attention to the path
>separator. java.io.File already does a pretty good job handling that.
>Example:
>
>        File f = new File("C:\\Temp");
>        f = new File(f, "foo/bar/hello.txt");
>
>This will evaluate nicely to "C:\Temp\foo\bar\hello.txt" on a Windows
>machine. (Obviously the statement above doesn't make sense on a unix box.
>It's only an illustration.) I expect FileUtils do be equally flexible
>and I don't think it is right now.
>
>The issue I'd like to point out is the following: Most of the methods in
>FileUtils currently have String parameters. Some have two flavors: once
>with java.io.File and once with String. I consider the variant with the
>String parameter a convenience method over the one with java.io.File
>parameters. In the past I've see a lot of this:
>
>String baseDir = ...
>String filename = ...
>String fullPath = baseDir + File.pathSeparatorChar + filename;
>
>where you could have written:
>
>File baseDir = ....
>String filename = ...
>File fullPath = new File(baseDir, filename);
>
>The second variant is less error-prone IMO. I make myself use
>java.io.File for every normal file or directory (non-VFS, non-URL stuff)
>just to avoid any OS-dependency problems. And it turned out to be a good
>move.
>
>Most of the methods in FileUtils should be written based on java.io.File.
>But there is a problem: If these methods should also work on URLs (or
>maybe some kind of VFS filename), they may fail if implemented that way.
>So, the question is: Should we make sure that URLs (as Strings) should
>be supported by the methods with String parameters in FileUtils? As for
>VFS filenames, the VFS thing should probably have its own set of utility
>methods. If yes, we will have to mark methods that support URLs clearly,
>because not every method in FileUtils will be able to support them
>(cleanDirectory() for example).
>
>Alternatively, we could create a FilenameUtils class that has some of
>the same methods from FileUtils but with String parameters and
>supporting URL syntax.
>
>I'm not really proposing anything here because I don't have a strong
>opinion in either way, yet. But I'd be grateful for any thoughts.
>
>Jeremias Maerki
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org