Name: rmT116609 Date: 05/30/2003


A DESCRIPTION OF THE REQUEST :
The File.deleteOnExit API is flawed and causes JVM crashes on long running servers (or even short running if the API is used enough). See bug 4513817.
The easiest way to circumvent this problem without changing the semantics of File.deleteOnExit is to provide a means to cancel a pending delete on exit. A new java.io.File API (File.cancelDeleteOnExit()) should be provided that allows programmers to manage the state of such files. The new API wont do much for servers that suffer from 4513817, but at least new programs can work around the deleteOnExit behavior. It also seems to make sense that if the user can arrange for something as severe as a file removal to occur on exit, it ought to be something that is also cancellable if the user's intent changes.

In addition, either the semantics of File.deleteOnExit should be modified so that the JVM can run without risk of crashing or the API should be deprecated and removed eventually. The JVM should not rely on clients calling File.cancelDeleteOnExit to avoid JVM crashes.

JUSTIFICATION :
Without this enhancement, servers using File.deleteOnExit are at risk of encountering JVM crashes or poor performance due to large memory loads caused by the JVM memory leak.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
After a call on File.cancelDeleteOnExit, I would expect the JVM to give up all memory allocated due to a prior call on File.deleteOnExit. I would expect the JVM to never crash or slow down due to a memory leak.

CUSTOMER SUBMITTED WORKAROUND :
  Programs cannot use File.deleteOnExit reliably if the API is run repeatedly.
(Review ID: 186747)
======================================================================