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.
Roger
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.ri...@oracle.com
<mailto:roger.ri...@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!
