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 Thu, 30 Jul 2009 16:03:07 GMT
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