RE: java.util.zip.InflaterInputStream patch

[Wu, Gansha]

Hi Mark,
     You're right. GNU Classpath's java.util.zip doesn't need the padding 
because it doesn't use zlib, but a patch there doesn't change the
correctness 
of GNU Classpath's pure Java java.util.zip implementation. ORP has another 
java.util.zip implementation which implements some critical methods by JNI 
native methods, and as such improves the performance of some real-world 
business applications significantly. This alternative implementation is
using 
zlib and so needs the patch. 
     BTW, ORP's zlib implementation is turned off in current ORP release,
and 
can be turned on by USE_NATIVE_ZIP_LIB with some changes to 
java.util.zip.ZipFile/Inflator/ZipEntry which are not in our submission.

Best regards...
Gansha

-----Original Message-----
From: Mark Wielaard [mailto:address@hidden
Sent: 2002?10?22? 7:08
To: address@hidden
Cc: Wu, Gansha; address@hidden
Subject: Re: java.util.zip.InflaterInputStream patch


Hi,

On Sat, 2002-10-19 at 21:50, Tom Tromey wrote:
> Mark> +          //add a padding byte, 
> Mark> +          //it's necessary when using native zlib
> Mark> +          ++len;
> 
> Mark> When is this needed?
> 
> I wonder if it is related to this comment in libgcj:
> 
>       /* Using the no_header option, zlib requires an extra padding byte
at the
>       end of the stream in order to successfully complete decompression
(see
>       zlib/contrib/minizip/unzip.c). We don't do this, so can end up with
a 
>       Z_BUF_ERROR at the end of a stream when zlib has completed inflation
>       and there's no more input. Thats not a problem. */

Thanks, that seems to be the situation when this code would be
triggered. But this shouldn't be a problem with our java.util.zip
(jazzlib) implementation since that doesn't use zlib.

What is the experience of other VM developers? Do you use jazzlib or
some form of native zlib java.util.zip?

If only we had a way to more easily share CNI and JNI code... Any VMs
(except libgcj) that support CNI btw? I heard that Kaffe once had
interoperability with gcj compiled native code but that it was not kept
up to date with the current gcj.

Thanks,

Mark