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.gerasi...@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_mehr...@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
