Brian, Just a note, one issue I see with webrev.01 is that JDK-7092892 is not resolved. On one hand more calls to DeleteOnExitHook should trigger class init sooner avoiding the issue. On the other it seems this could be more methods that could fail by throwing ExceptionInInitializerError that wouldn't have before the change. I would think that you would want to mark JDK-7092892 as blocker of JDK-8193072 before you go this route.
Jason ________________________________________ From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Brian Burkhalter <brian.burkhal...@oracle.com> Sent: Tuesday, July 9, 2019 10:07 AM To: Roger Riggs Cc: core-libs-dev@openjdk.java.net Subject: Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files 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> 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!
