Blah, I think you need to take a break.
Actually, yes. I've just been poached to be CTO of a new games company and life has been very manic recently, with JGF falling behind (and now with less than a week before I have to start a new job; it's one of those "start tomorrow" situations). Other issues, like book-writing etc, have made it a hectic month. I was considering posting in off-topic a general apology for being somewhat unclear/off-centre/bizarre/wrong the last few weeks. Trouble is, I never know specificially which concepts are silly and which aren't until later on.
The JavaDocs clearly spell out the semantics of the call, as well as why it might fail.
No, sadly, mine don't
. /me wonders if this is a doc fix for java 5?
public boolean renameTo(File dest)
Renames the file denoted by this abstract pathname.
Whether or not this method can move a file from one filesystem to another is platform-dependent. The return value should always be checked to make sure that the rename operation was successful.
dest - The new abstract pathname for the named file
true if and only if the renaming succeeded; false otherwise
SecurityException - If a security manager exists and its SecurityManager.checkWrite(java.lang.String) method denies write access to either the old or new pathnames
NullPointerException - If parameter dest is null
Unfortunately, I read "filesystem" to mean what I believe is a fairly standard interpretation: "local filesystem" == all drives not network shares == one filesystem. "remore filesystems" == each network share == N additional filesystems.
It could be worded much better. But...it's certainly a bug that it throws no exception (look at the since - it's one of the many methods that needed updating / deprecating and renaming in 1.2 and 1.3, but obviously is one of the few that got forgotten).
The original is just fine, as well as guaranteed on JVM's earlier than 1.4. Your method is definitely a cool optimization though. :-)
Sorry, yes, I should have been more clear: if you are writing server code, which is when most people encounter this issue (especially the "store files as OS-temp files, then move them to local locations when you've had a chance to examine / CRC check / whatever you do" pattern, which seems to be quite common, for obvious reasons) then you will be using 1.4 anyway (server without NIO == sludge).
Without 1.4, then you need lots of code to do it, and it will ALWAYS be very inefficient, streaming from disk, to RAM, to CPU, to RAM, to disk (instead of disk-to-disk). With 1.4, you haev a *chance* that it's bearable.
@tom: yes, that's a sensible thing. I'd actually already done that in my code, but it adds a few extra lines, and I was trying to provide the shortest piece of code that solves the problem