On 12/14/14 7:43 PM, Wang Weijun wrote:
Several questions:
1. Why cannot I just call os.putNextEntry(ze) or at least os.putNextEntry(new
ZipEntry(ze))? Maybe some fields (say, compressed size) should not be copied
over? If ze2 must be this way, shall I also copy the flag field?
It's the choice of jarsigner. My take on this is (1) it is a defensive
copy. The ZOS uses the input
ze directly without making a defensive copy, so some of its fields get
updated during writing,
for example the "flag" field. (2) The "flag" field is more a
implementation detail of the ZOS
implementation, as well as the csize and the crc32 fields when
deflating. It'd better to leave the
ZOS decide what to do with them instead of passing in a 'known value".
That said, you actually can just pass in a ze with all fields filled
(without creating a new entry
and copying the fields, maybe for a better performance), in that case,
the ZOS will verify the
size, csize and crc32 with the real bytes written out, exception will be
thrown if the input values
and the real values don't match. It's a choice of jar
2. In writeBytes(), why does the getSize() return value need to be used?
Shouldn't we just transfer all bytes from is to os?
In theory, yes you can just try to read all bytes from the input stream
from the ZipeFile entry.
The stream should returns -1 when it reaches the byte numbers of
entry.getSize(). This is
what the jar does when extracting.
-Sherman
Thanks
Max
