There is a > 2/4G support issue we will need to address when using the
platform bundled zlib.
The total_in/total_out variables of z_stream_s is "long", which is not "big"
enough (32 bit) for ZIP64 support on a 32-bit platform. The zlib code
bundled with JDK has been updated to use "long long", as the (4)(5)(6)
in ChangeLog_java at
http://cr.openjdk.java.net/~sherman/7110149/webrev/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java.html
The Deflater/Inflater.getgetByteRead/Written() now use
z_stream_s.total_in/out
"directly", so it will not be able to report the correct
totalRead/Written value
if the value > 2G/4G, though it might be rare to deflate/inflate a >2/4G
chunk
of data.
A possible solution is to accumulate the "totalRead/Written" at java
level, so
as long as you don't pass in data > 2g/4g in one invocation, it should
be fine.
-Sherman
On 11/30/2011 02:09 AM, Chris Hegarty wrote:
On 30/11/2011 09:50, David Holmes wrote:
On 30/11/2011 7:43 PM, Alan Bateman wrote:
On 30/11/2011 01:31, Dr Andrew John Hughes wrote:
On 10:23 Tue 29 Nov , Alan Bateman wrote:
snip...
When we talked about the zlib version here (I think back in
February) we
talked about having the option to use the system's zip library where
appropriate. Have you given this any thought recently?
-Alan.
We have changes for this (and other libraries) in IcedTea that we'd
like
to upstream. I'll look at posting a webrev soon.
That would be great. If I remember correctly then the IcedTea patches
remove the zlib code completely but we can't do that of course because
of Windows. So I think a USE_SYSTEM_ZLIB as you suggest would be best.
FYI the macosx port is also adding a SYSTEM_ZLIB option:
http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/
So this is a compile time decision, if you are targeting a platform
that is known to have a system zip library you simply link against
that. Nice!
I've also been looking at the possibility ( for a different reason )
of using supporting the system version of a library (if one is
available) instead of the bundled version. This is to allow support of
more recent versions of the system library to be used, rather than
what may be an older bundled version, and targets platforms where a
system library may or may not be available.
Is this something that may be relevant here, or are we always
guaranteed that the system will have a zip library available on our
targeted OS-ARCH binaries?
-Chris.
David
-Alan.
