On 5/13/16 3:27 AM, Alan Bateman wrote:
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.
something like this?
http://cr.openjdk.java.net/~sherman/8147588/webrev/
-sherman
