RFR JDK-8174996: jar leaves temporary file when exception occur in creating jar

[Paul Sandoz]

Hi Sherman,

Can you use File.deleteOnExit instead of explicitly deleting?

Paul.

> On 16 Feb 2017, at 12:09, Xueming Shen <xueming.shen at oracle.com> 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
>