zlib1.2.3

[Martin Buchholz]

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> 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>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstraße 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090824/1fd66434/attachment.html>