Hi Sherman, Can you use File.deleteOnExit instead of explicitly deleting?
Paul. > On 16 Feb 2017, at 12:09, Xueming Shen <[email protected]> wrote: > > Hi, > > Please help review the change for > > issue: https://bugs.openjdk.java.net/browse/JDK-8174996 > webrev: http://cr.openjdk.java.net/~sherman/8174996/webrev > > The cause/trigger of this "regression" is that the jdk9 jar implementation > now builds > the target jar file on a temporary file first and then copies it to the the > target > destination, after sanity check if any. Same as what the "update" operation > has been > implemented (which means this is A problem for "update" operation as well, if > ZipException/IOException gets thrown in the middle of the operation the > temporary > file is left un-deleted. In case of "update" operation, the temp file is at > the same > directory as the existing target jar file, if the "jar" is not from the > stdin). > > In fact, in releases before jdk9, even there is no temporary file left behind > in this > situation, the destination jar file is left as a "broken jar" without being > deleted. So > for the use scenario described in this issue report, with jdk 8 or earlier, > command > > jar cf test.jar -C a test test > > will create a broken jar file "test.jar", after the exception thrown. > > So strictly speaking, this is a not really a "regression", but a bug in > different > form, though it is still desired to be addressed/fixed. Given the nature the > temporary > file, it is relatively hard to create a regression test to check/verify the > remove > of the temporary after the exception. I'm not adding an auto regression test > for this fix, though the fix has been verified manually. > > > Thanks, > Sherman >
