zlib1.2.3

[Xueming Shen]

This is a different issue. I would prefer to separate the "to upgrade to 
zlib 1.2.3" and
"to use host platform zlib on linux, if preferable" into two different 
tasks. We tend to
try to put too many "similar" things into one project and end up missing 
the primary
goal:-) Given the zlib is so "important", I would like to safe-land the 
zlib1.2.3 first,
without touching too many other stuff.

Personally I agree, there is good reason to use the zlib from native 
platform/resource,
"depending on your perspective", as Joe said. However there is also good 
reason to
stick with the approach of "using our own zlib, even there is a native 
zlib". The linux is
an open platform and zlib itself is NOT a real "standard" library like 
libc, there is no
guarantee that the zlib loaded on the platform is the one you want to 
use. Sure you
can do your best try to "detect"...the reason I don't want to bundle 
this issue into the
upgrade work.

Sherman

Martin Buchholz wrote:
> It is reasonable for jni code to be built against the system zlib.
> Such jni code should not accidentally invoke the jdk bundled zlib.
> zlib includes support for symbol renaming (Z_PREFIX),
> but better is to build the jdk so that jni does not have direct access
> to the zlib functions under any name (but that might be a lot of work).
>
> Martin
>
> On Mon, Aug 24, 2009 at 00:20, Florian Weimer <fweimer at bfk.de 
> <mailto:fweimer at bfk.de>> wrote:
>
>     * Martin Buchholz:
>
>     >   45 +#ifdef _LP64
>     >   46 +typedef unsigned int  uLong;  /* 32 bits or more */
>     >   47 +#else
>     >   48  typedef unsigned long  uLong; /* 32 bits or more */
>     >   49 +#endif
>
>     This is guaranteed to break interoperability with the system zlib.  If
>     you want to make such adjustments, you really have to rename all
>     functions to avoid name clashes.  Such clashes materialize if you load
>     a DSO which contains code linked to the system zlib (usually via JNI).
>
>     Technically, this is not a regression because OpenJDK's existing zlib
>     1.1 code is incompatible with 1.2 zlibs used on most systems, so the
>     same problem happens.
>
>     --
>     Florian Weimer                <fweimer at bfk.de <mailto:fweimer at bfk.de>>
>     BFK edv-consulting GmbH       http://www.bfk.de/
>     Kriegsstraße 100              tel: +49-721-96201-1
>     D-76133 Karlsruhe             fax: +49-721-96201-99
>
>