Oliver Deakin wrote:
Andrew Myers wrote:
Hi Oliver,
Thanks for the feedback.
I suspect the reason it is returning -1 is because I am not calling the
setSize method on the ZipEntry when I create it. There's a few other
setters I think I need to call that I'm not, such as
setCompressedSize
setMethod
and probably some others
If anyone can give me a hand with this I would very much appreciate a
nudge
in the right direction.
I tried setting the ZipEntry size with
"zEntry.setSize(file.length());" in processFile() but this doesn't
make a difference - when I come to list the files getSize() and
getCompressedSize() still return -1.
I had a feeling this might be a bug in ZipOutputStream/ZipInputStream,
so I took a look in the code there for the putNextEntry() and
closeEntry() methods. It looks like when we are just storing the data
(no compression) we write the sizes first. When we compress the data
we store the sizes after the data is written, so we know the
compressed size, in a different location in the file. However, looking
into ZipInputStream.getNextEntry() we only seem to read the size in
the case where the data is stored uncompressed, and don't read it at
all in the case where the data is compressed. This leaves the sizes
(and the crc) as the default values, which are -1. I've discovered we
also display the entry size as -1 when the jar is created by the RI.
So it appears the way we write the ZipEntry is correct, but the way we
read it is broken, which explains why the RI can read the ZipEntry
size correctly when the jar is created by our tool. I'll see if I can
figure out the right thing to do in getNextEntry() to read the sizes
from the correct location.
I've tried running our jar Main.class on the RI and it gives me the same
-1 size value as it does on the Harmony runtime, so I think the
behaviour of ZipInputStream is actually correct. It looks like we need
to read ahead and get those size values ourselves in the jar tool code -
so if the ZipEntry is flagged as compressed we continue reading after
the data and get the crc, uncompressed and compressed sizes. Ill keep
investigating...
Regards,
Oliver
So in the default
I'll fix the other issue with the buffering - that one I do know how
to do
:-)
Cool - thanks!
Regards,
Oliver
Andrew.
2009/7/30 Oliver Deakin <oliver.dea...@googlemail.com>
Hi Andrew,
I've applied the patch from HARMONY-6255 now and it's looking good. The
only slightly strange thing I've noticed is that when I create an
archive
with a command line something like:
jar -cf foo.jar HelloWorld.class
and then list it's contents with "jar -tvf foo.jar", I get -1 as the
size
of the ZipEntry for some reason:
target\hdk\jdk\bin\jar -tf foo.jar
-1 Thu Jul 30 09:46:38 GMT+01:00 2009 HelloWorld.class
However, if I run with jar from the RI it displays the ZipEntry size
correctly:
717 Thu Jul 30 09:46:38 BST 2009 HelloWorld.class
In the listJar() method we use ze.getSize() to get the ZipEntry size to
display, which works for jars not packed by our own jar tool. Any
idea why
it wouldn't work for jars packed by our jar?
Just a quick note on the processFile() method - I notice that it
reads the
entire file to be packed into a buffer and then writes it all out
again in
one go. This is ok for small files, but I could see a problem when
we get to
packing files which are very large - do you think it would be better
to have
a predefined buffer size here (say 1000 bytes) and read/write in a
loop, one
chunk at a time? We can use the return value from
FileInputStream.read() to
tell us how many bytes have been read and then pass this value to
ZipOutputStream.write().
Regards,
Oliver
Oliver Deakin wrote:
No problem Andrew :)
Regards,
Oliver
Andrew Myers wrote:
I might have worked this out myself. Sorry I'm so slow with this
- but I
am
progressing. I will have something to show tomorrow I hope.
2009/6/16 Oliver Deakin <oliver.dea...@googlemail.com>
Hi Andrew,
Great to hear you've got back into the jar tool! I think the best
thing
is
to direct your questions to the dev@ list, however simple or complex
they
may be. Everyone here is happy to help, and you'll receive answers
quicker
and get more ideas/opinions when the whole list can see your mails.
Regards,
Oliver
Andrew Myers wrote:
Hi Oliver,
Just letting you know that I've commenced work on the Jar Tool
again.
It's a bit more complicated than I first expected (processing
wildcards
and
nested directories in particular). I wouldn't mind a bit of a hand
with
this, if anyone is willing to assist. My questions might be a
little
"newbie-ish" so I wasn't sure whether to ask on the list or take it
off-list
with some nice person(s) who are willing to help out. What's the
protocol
here?
Thanks!
Andrew.
2009/5/12 Oliver Deakin <oliver.dea...@googlemail.com>
Hi Andrew,
Did you get the paperwork completed ok? Is there anything we
can give
you
a
hand with?
Regards,
Oliver
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with
number
741598. Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire
PO6 3AU
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with
number
741598. Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire
PO6 3AU
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
