8193072: File.delete() should remove its path from DeleteOnExitHook.files

Roger Riggs Roger.Riggs at oracle.com
Tue Jul 9 15:25:56 UTC 2019

Hi Brian,

The interesting part will be writing/updating the specification to make 
it clear what happens and under what conditions.
How often are File instances re-used vs creating new ones.
And any interactions with other APIs that create or delete files with 
the same name.  (file channels, zip, etc...)

Since deleteOnExit() is an deliberate act, perhaps there should be a 
corresponding withdrawDeleteOnExit() that reverses it so that it is 
intentional and not a side-effect of other File methods.


On 7/9/19 11:07 AM, Brian Burkhalter wrote:
> Hi Roger,
> You might be correct but I wrote up a different version at the end of 
> yesterday. Not sure it is right but I might as well post it:
> http://cr.openjdk.java.net/~bpb/8193072/webrev.01/
> Thanks,
> Brian
>> On Jul 9, 2019, at 7:34 AM, Roger Riggs <Roger.Riggs at oracle.com 
>> <mailto:Roger.Riggs at oracle.com>> wrote:
>> The sequence described is the specified behavior of the API, whether 
>> it is a developer mistake or not is unknowable but it would be a 
>> compatibility issue to change it. The filename is the key and there 
>> is no way to determine if it is the original file or a replacement. 
>> deleteOnExit Wins!

More information about the core-libs-dev mailing list