harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: Jar tool?
Date Fri, 31 Jul 2009 10:36:20 GMT
Turned out to be simpler than it seemed - to get the size/crc info at 
the end of the data section to be read, we simply need to call 
zis.closeEntry() before calling getSize(). I've committed the change at 
r799569. Now "jar -tvf foo.jar" prints:

Reading jar file: foo.jar
Listing files:
     0 Thu Jul 30 15:53:08 GMT+01:00 2009 META-INF/
    62 Thu Jul 30 15:53:08 GMT+01:00 2009 META-INF/MANIFEST.MF
   717 Thu Jul 30 15:36:54 GMT+01:00 2009 HelloWorld.class

Regards,
Oliver

Oliver Deakin wrote:
> 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.deakin@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.deakin@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.deakin@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


Mime
View raw message