Re: java.util.zip

[Jochen Hoenicke]

> John Leuner wrote:
> 
> > > > Jochen has also completed a pure-java implementation of java.util.zip. 
> > > > I don't know if this will be the preferred implementation for 
> > > > classpath, but I suggest that it at least be a compile-time option.
> > > >
> > > > You can get the source and compiled classes at 
> > > > http://jazzlib.sourceforge.net/
> > >
> > > Yeah! This is great!
> > > I would love to have this as the default implementation in Classpath.
> > > Would there be any reason to not make the pure java version the default?
> >
> > I don't see any. The code is functionally equivalent.

Bryce McKinlay wrote:
>
> I agree, this is very cool.
> 
> Have you run any tests to compare performance with the JDK's native
> zlib-based implementation?

Reading compressed streams takes ca. 50% more time than with Sun's zlib
based implementation.  IIRC creating compressed streams was around
factor 2 slower.  This is with the IBM Java2-1.3 virtual machine and
its JIT compiler.

Some of this slow down is due to array bound checks in java.  I don't
know how good the JIT compiler is in inlining short functions, this
may also explain some slow-down.

> Does it pass the ZipVerify test case? (see
> http://gcc.gnu.org/ml/java/2001-03/msg00374.html)

Thanks for the link, I haven't seen this test before.  There is a
problem with ZipEntry.setExtra().  My version is more stringent at
what kind of extra fields it allows.  It doesn't allow a NullPointer
and it only allows extra fields formed as described in appnotes.iz
(zip file format spec).  Sun's jdk doesn't care at all about the
content but my implementation makes use of it to read the extended
timestamp.

When changing my implementation to ignore wrong parameters to
setExtra() all tests pass.

  Jochen