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

[Roger Riggs]

Hi Brian,

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!

$.02, Roger


On 7/8/19 5:08 PM, Brian Burkhalter wrote:
> Ivan / Jason,
>
> Thanks for the good observations.
>
>> On Jul 8, 2019, at 1:35 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> I believe this would introduce a behavior change in a scenario lile:
>> File f = ...;
>> f.deleteOnExit();
>> f.delete();
>> f.createNewFile();
>>
>> I.e. when the with the same name is recreated.  Current behavior is to unlink such a file before exiting, no matter if it were explicitly deleted and then recreated or not.
> Good point. Given this consideration I am not sure that this bug can be fixed.
>
>> On Jul 8, 2019, at 1:53 PM, Jason Mehrens <jason_mehrens at hotmail.com> wrote:
>>
>> Previously File.delete wouldn't throw IllegalStateException and with this patch it looks like that is possible (and not desirable).  I would think that this change could the break java.util.logging.FileHandler because Handler.close runs in a shutdown hook.
>
> I think you are correct that the ISE should not be thrown.
>
> Thanks,
>
> Brian