java.io (File) - Why no copy?

[Greg Ostravich]

I know you can use streams to perform a file copy in Java, but why was the method "copy" not added to Java with the Merlin release (1.4)?

[Stuart Gray]

Well I guess a line has to be drawn somewhere. If you want a copy method, you have to think about things like the destination directory, whether we should overwrite the file if it already exists, and so on. I guess before long you could have so many methods with so many different parameters that they might be better in a separate FileUtilities class instead.

[Greg Ostravich]

Thanks for the reply.

As far as destination directory that's not a problem - it isn't with the renameTo method. It accepts the destination as the only argument.

I just didn't understand why the File class had rename, delete, et. al. but not copy. I realize you have to draw the line somewhere, but why there?
Copy is very useful and I thought it was lame you have to implement your own copy everywhere because that's the one thing missing from File.

As far as over-writes they could pick one way or the other to do it and we could adjust. Worst case it doesn't over-write and you have to call the createNewFile method to do that before a copy method is called. Otherwise they could have decided to over-write and you have to see if the File exists first in case you want to preserve it using the exists method.

The reason I posted this question was that I was hoping somebody who knew of the debate (if there was one) over whether or not to include a copy functionality in the File class might shed some light on the decision.

I'm sure there must have been a good reason for that decision, but I just don't have a clue what that reason was.

[Ernest Friedman-Hill]

I would guess that the reason is that 'rename' and 'delete' correspond to individual UNIX system calls, while 'copy' does not. The File class's capabilities are a simple reflection of what's available in the UNIX filesystem API. You can implement 'copy' in terms of other available facilities, but 'rename' and 'delete' are primitive filesystem operations that have to be implemented in the kernel.

[Steve Morrow]

Copy is very useful and I thought it was lame you have to implement your own copy everywhere because that's the one thing missing from File.

You don't!

http://jakarta.apache.org/commons/io/

[Greg Ostravich]

Thanks - that makes sense that it would be because of what mapped to the O/S the JVM ran on.

Thanks for the link to to the commons project.
I recently changed a kludgy roll-your-own debug to use Log4J and now I'll check out the Commons project to see what's there and start using some of that for what I need.

[Ulf Dittmer]

java.io.File is quite platform-specific in a few spots - as it would be, given its nature. E.g. the javadocs of renameTo even mention that -depending on the platform- the method may succeed in different circumstances on different platforms.
File copying would have been tricky in the early days on Mac OS pre-X, where in addition to the data fork, there was also a resource fork, and an information stream. To this day, using OS X 'cp' on those files results in only the data fork being copied (i.e., file corruption). Which, incidentally, I suspect is also what the Commons IO package does, because there is no way to get at the other parts of the file using plain Java.
And since I'm reminiscing about pre-OS X days: it was perfectly OK to have two file systems with the same name, which would result in one (or both) of them being inaccessible in Java, since there was no notion of a 'root' directory (and java.io.File.listRoots came later).
[ August 07, 2005: Message edited by: Ulf Dittmer ]