[cp-patches] RE: Patches to java.util.zip by Christian Schlichtherle

[Christian Schlichtherle]

Hi everyone,

the changes from int to long are required as to the ZIP file format
specification available online from PKZIP Inc.

The specification says that all integers are 4 byte unsigned integers.
Java's int type is 4 byte signed, thus the type long is required to hold a
ZIP file integer. You can find this in other popular Java based ZIP file
implementations as well (Apache ant, the JDK, etc.).

I have introduced this fix because jazzlib 0.07 definitely breaks on ZIP
files larger than 2 GB. With my patches however, jazzlib is compatible to
the ZIP 32 spec which can hold up to 4 GB.

Furthermore, the constructors I've introduced are provided to allow an
application developer to have the choice of choosing an encoding: UTF-8 as
with Sun's JDK which is only relevant if you need to exchange ZIP files with
JDK created ZIPs or CP437 to exchange ZIP files created by the rest of the
world (PKZIP, Winzip, infozip, MS Explorer, etc). In my opinion, the latter
is more relevant for real world internationalized applications.

Removing all these fixes/enhancements make my submitted patches pretty
useless and do not solve important bugs/limitations of jazzlib 0.07.

Anyway, as nothing happened on these topics for almost half a year I've
moved away and rolled my own. The resulting ZIP package is available at
http://truezip.dev.java.net and does much more than just providing classes
which are backwards compatible to JDK's java.util.zip package. It provides
an additional layer of abstraction so that an application can treat a ZIP
file like an ordinary directory using classes which are backwards compatible
to JDK's java.io package. Using this you can create for instance an entry
nested in two ZIP files by simply writing to a new
FileOutputStream("outer.zip/inner.zip/file.txt").

With best regards,
Christian Schlichtherle
---
Schlichtherle IT Services
Wittelsbacher Str. 10a
10707 Berlin
 
Mobil: 0173 / 27 12 470
mailto:address@hidden
http://www.schlichtherle.de
 

> -----Original Message-----
> From: Mark Wielaard [mailto:address@hidden 
> Sent: Tuesday, August 30, 2005 11:45 PM
> To: John Leuner
> Cc: address@hidden; Christian Schlichtherle
> Subject: Re: Patches to java.util.zip by Christian Schlichtherle
> 
> Hi (moved to classpath-patches)
> 
> On Tue, 2005-08-30 at 18:02 +0200, Mark Wielaard wrote:
> > I need to go through the rest of these patches.
> > It would help if they could be rediffed against current CVS 
> head and 
> > extra functionality would be moved to a new package.
> 
> I reviewed the rest but dropped everything that would need 
> new constructors. It would be best to rewrite that part so 
> that it is an extension for another (gnu) package.
> 
> While reviewing the classes I fixed some other small issues 
> that I saw in the code. I choose to treat all strings 
> explicitly as UTF-8 encoded although CP437 would probably be 
> also a defensible choice. I did not use any of your int -> 
> long changes in the method signatures since I was not sure 
> how and where that was actually needed. If there is a change 
> in the zip format could you give a reference to that and 
> explain how the patch changes the values that gets written/read?
> 
> I committed the following:
> 
> 2005-08-30  Mark Wielaard  <address@hidden>
>             Christian Schlichtherle  <address@hidden>
> 
>    * java/util/zip/ZipEntry.java (setTime): Use
>    Calendar.setTimeInMillis().
>    (getTime): First parse extra bytes. Use Calendar.getTimeInMillis().
>    (parseExtra): Don't return early to make sure that KNOWN_EXTRA is
>    always set.
>    * java/util/zip/ZipFile.java (readEntries): Parse name and comment
>    as UTF-8 string.
>    (close): Check that raf is not null.
>    * java/util/zip/ZipInputStream.java (getNextEntry): Set name as
>    UTF-8 bytes.
>    * java/util/zip/ZipOutputStream.java (setComment): Set comment as
>    UTF-8 bytes.
>    (putNextEntry): Likewise for name.
>    (finish): Likewise for both.
> 
> Could you check whether I missed something essential from 
> your original patch?
> 
> Thanks,
> 
> Mark
>

smime.p7s
Description: S/MIME cryptographic signature