aspose file tools*
The moose likes Beginning Java and the fly likes java.io (File) - Why no copy? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "java.io (File) - Why no copy?" Watch "java.io (File) - Why no copy?" New topic
Author

java.io (File) - Why no copy?

Greg Ostravich
Ranch Hand

Joined: Jul 11, 2002
Posts: 112
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)?


Greg Ostravich - SCPJ2
Stuart Gray
Ranch Hand

Joined: Apr 21, 2005
Posts: 410
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
Ranch Hand

Joined: Jul 11, 2002
Posts: 112
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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

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.


[Jess in Action][AskingGoodQuestions]
Steve Morrow
Ranch Hand

Joined: May 22, 2003
Posts: 657

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
Ranch Hand

Joined: Jul 11, 2002
Posts: 112
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
Marshal

Joined: Mar 22, 2005
Posts: 41877
    
  63
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 ]

Ping & DNS - my free Android networking tools app
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: java.io (File) - Why no copy?