David Holmes - Sun Microsystems wrote:
:
But a runtime exception is better than silent failure when the file
will not be deleted. And the exception here is not new.
Is this a flaw in the File#deleteOnExit API - because it gives the
illusion that it can always succeed when in fact the code requesting
this can be running concurrently with the code responsible for making
it happen? Maybe that is a deficiency of the whole mechanism - really
we should be using a native deletion mechanism that is only done once
the VM arrives at the termination safepoint - as that is the only time
we know for sure that no more Java code can be executed. But that
would be a RFE on the deleteOnExit mechanism.
I agree that a runtime exception is better than silently not registering
but it really needs to be specified or as you suggest, delete the files
once we have reached the termination safepoint. As creating a file and
registering it for delete via deleteOnExit is not an atomic operation
then there will always be a window where the VM may exit before the
application registers the delete. An IllegalStateException gives some
opportunity to explicitly delete the file but there is no guarantee that
such a recovery action will execute. It is somewhat helpful in that it
may prevent code from writing sensitive information to a file that it
expects to be deleted.
Anyway, the history is that this mechanism used to be completely in
native code and the files deleted via a VM exit hook. I haven't looked
at this code in a while but my memory is that these exit hooks are
executed by before_exit after the shutdown hooks but before the
cancellation safepoint. The IllegalStateException came with the re-write
in jdk6 to keep the list in the java heap to make it easier to diagnose
resource issues caused by applications that registered tens of thousands
of files to be deleted. At that point the spec should have been looked
at. As it happens, there was a bug in that code (6526376) that caused
NPE to be thrown so jdk7 b10 is the first build where
IllegalStateException is possible.
I don't think we want to force Mandy into fixing issues that aren't of
her doing so submitting a bug and letting her move on is probably the
best thing to do.
-Alan.
