Alternative to File.delete() and deleteOnExit()

Question

Is there any GOOD way to delete physical files from a Java app running under Windows besides the File object's incredibly lame and emasculated delete() and deleteOnExit() methods?
Despite my best efforts, I have yet to find ANY circumstances under which calling File.delete() will actually delete a file under Windows XP... It's as though the mere act of a running Java application becoming AWARE that a file exists is enough to make the JVM lock the file so nothing else can touch it (including the running app itself).
Is there perhaps some alternate JNI-based alternative that treats deletions as more than polite suggestions that a file be considered for future removal, and PERSONALLY sees to it that the underlying OS makes an immediate and determined effort to physically delete the file IMMEDIATELY?

Answer 1

The File object referenced above is used to open a FileInputStream, which is subsequently closed prior to calling the File object's delete() method.
From what I've read about this problem over the past few days, it arises because Sun didn't follow their own best practices and left releasing the file lock to the Stream's finalize() method (or otherwise left some critical prerequisite to the lock's release to a garbage collection run)... which, as we all know, is something you should never do when you're DEPENDING upon having something executed because there's NO guarantee it will run in a timely manner, or even run at all (if, say, the application throws an Exception).
Apparently, the problem arises something like this:
A running Java app creates a File object and does something that requires doing actual I/O upon it, like opening an input/output stream.
The JVM asks its abstraction layer to ask Windows to open the file. A delegate is dispatched to contact win32 and request a file lock. Windows creates a file lock in the thread's name, and gives the delegate the good news.
The running app does its stream I/O.
The running app closes the stream, and nullifies the object's reference just to be safe.
Unfortunately, the JVM has other plans in mind. It throws the old Stream object into the garbage collector's work heap, then forgets it ever existed without bothering to stick around and personally make sure the file lock is released RIGHT AWAY.
The running app continues... it's done with the file and has no further use for it, so it calls the File object's delete() method as its final act before nullifying the File object itself.
The JVM dispatches another delegate to ask Windows to delete the file. Unfortunately, windows notices that the JVM still holds a lock on the file and tartly sends it home empty-handed, with instructions to tell its parent to make up its mind what it wants to do with the file. The delegate meekly reports failure, and the message is passed back to the running app without further action.
What SHOULD happen:
Calling Stream.close() should cause a delegate to be IMMEDIATELY dispatched to notify Windows that the lock should be released.
OR, if Sun doesn't want to do that for performance reasons, then the JVM should double-check to make sure that the failure wasn't its own fault -- forcing an IMMEDIATE sweep through the garbage collector to return any queued-for-release file locks (possibly after taking a side trip to verify that the file still physically exists), followed by a second deletion attempt once it's certain that windows has responded to its request to release the lock.
Calling System.gc() before calling File.delete() seems to work for now... but it's a really bad kludge that Sun needs to address since there's technically no guarantee that the garbage collector will actually run and release the lock.
IMHO, this is an outright shameful bug. Sun can make all the lame excuses it wants to make about enforcing platform abstraction, but the fact is... anyone who calls File.delete() after personally making sure they've cleaned up after themselves by closing their streams has every reasonable expectation that the file will, in fact, be physically deleted unless some OTHER app or thread has acquired a secondary lock in the meantime. The buck has to stop somewhere. File deletion is one of those unglamorous tasks that nobody really thinks about until it doesn't work... and when it fails, it comes as a really rude surprise. If Sun can't alter the behavior of File.delete() for legacy reasons, then they should add an alternate method, like "File.deleteNow() throws RuntimeException" that guarantees the following behavior:
"The JVM asks the host operating system to delete the file. If the OS refuses, the JVM tries to figure out why, and whether the failure might be its own fault. If it has reason to believe it's its own fault, it will force an immediate garbage collection run to clean up any outstanding mess, then ask the host OS to delete the file again. If it succeeds, the method returns true. If it fails, a RuntimeException (or subclass that actually lets the caller figure out why it failed) gets thrown."
The key point is that File.delete() must NEVER fail unless some OTHER app, process, or thread that's completely unrelated to the one that locked the file and now wants it deleted has acquired a lock on the file in the meantime. I think just about everyone will agree that the current behavior of File.delete() under win32 absolutely violates the implicit contract that developers reasonably expect of a function to delete a file.
Just to give one concrete example of a scenario where File.deleteOnExit() isn't feasible... suppose you have some emergency maintenance task that needs to be launched (with manually-supplied arguments) every few months when Something Bad happens... usually at night or over a weekend. To make life easy, the emergency app is implemented as a Servlet (so the notified individual can quickly and easily fix it in 3 minutes with his PalmOS phone and browser). The problem is, deleteOnExit() won't do much good when called from a Servlet, because the JVM running Tomcat hosting the Servlet is almost guaranteed to run for months without actually exiting... and when it finally DOES exit, it probably WON'T be graceful or intentional...