On 12/05/2016 20:16, Xueming Shen wrote:
Hi,
Please help review the proposed change for #8147588
issue: https://bugs.openjdk.java.net/browse/JDK-8147588
webrev: http://cr.openjdk.java.net/~sherman/8147588/webrev
This is a regression on Windows platform triggered by the change for
https://bugs.openjdk.java.net/browse/JDK-8145260, in which we brought
the ZipFile native natively code to java for better performance (both
memory and access).
As showed the from ln#107-114 at webrev below
http://cr.openjdk.java.net/~sherman/8145260/webrev.push/src/java.base/share/native/libzip/ZipFile.c-.html
The original native implementation uses a special "Windows-only"
option O_TEMPORARY to open the zip/jar file on Windows to support
this OPEN_DELETE functionality.
There is no corresponding public open/delete functionality at java.io
API right now. The proposed the change here is to add a private
constructor for RandomAccessFile and access from ZipFile via
SharedSecrets. This O_TEMPORARY is only supported on Windows
platform.
I assume O_TEMPORARY maps to Windows FILE_FLAG_DELETE_ON_CLOSE flag. In
the new file system API then this gets exposed as the DELETE_ON_CLOSE
open option but it isn't exposed via RAF. I assume it would be too much
of a change to move ZipFile, particularly with behavior changes related
to interruption.
I've looked through the patch but I just wondering if there are cleaner
alternatives. What would you think about not pushing O_TEMPORARY to RAF
but instead have ZipFile open the zip file with ZFILE_Open, wrap it with
a FileDescriptor and then create a RAF to that FileDescriptor. I realize
RAF doesn't have a public constructor for this so it needs plumbing but
the nice this is that it keeps this specific mode issue out of RAF.
-Alan
