> On Jul 11, 2019, at 12:52 AM, Peter Levart <peter.lev...@gmail.com> wrote: > > On 7/11/19 9:47 AM, Peter Levart wrote: >> >> http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ >> >> <http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/> >> >> > > Another thing to consider (done in above webrev.02) is what to do with > unbalanced cancelDeleteOnExit(). I think it is better to throw exception than > to silently ignore it. This way unintentional bugs can be uncovered which > would otherwise just cause erratic behavior.
The above patch looks pretty good but unless I am not comprehending the code I think there may still be behavioral incompatibilities which might not be acceptable. For example, for the existing code base with the following sequence of operations File file1, file2, file3; file1.deleteOnExit(); file2.deleteOnExit(); file3.deleteOnExit(); the deletion order is file3, file2, file1. For the proposed patch with the following sequence of operations file1.deleteOnExit(); file2.deleteOnExit(); file3.deleteOnExit(); file1.cancelDeleteOnExit(); // file1 is removed from the map file2.cancelDeleteOnExit(); // file2 is removed from the map file2.createNewFIle(); file2.deleteOnExit(); // file2 is added back into the map file1.createNewFIle(); file1.deleteOnExit(); // file1 is added back into the map the deletion order is (I think) file1, file2, file3 which is the reverse of the order of initial registration. Of course it is conceivable to change the specification but that seems dangerous somehow. Also for the patch above for this sequence of operations file1.deleteOnExit(); file2.deleteOnExit(); file3.deleteOnExit(); file1.cancelDeleteOnExit(); // file1 is removed from the map file2.cancelDeleteOnExit(); // file2 is removed from the map file2.createNewFIle(); file1.createNewFIle(); then file3 is deleted on exit but file1 and file2 are not which differs from current behavior. As Roger wrote > On Jul 9, 2019, at 7:34 AM, Roger Riggs <roger.ri...@oracle.com> wrote: > > The filename is the key and there is no way to determine if it is the > original file or a replacement. deleteOnExit Wins! the filename is the key and if we toss the key then we lose the order of registration. Given this I am not sure any more that it is possible to fix this issue without introducing an incompatible behavioral change. Thanks, Brian