On 08/02/16 09:55, Alan Bateman wrote:
On 08/02/2016 10:42, Seán Coffey wrote:
Is there an option to fall back to the older v.1.2.8 implementation
if necessary ? It would certainly alleviate issues for any
applications that might run into issues with the latest and greatest
zlib libraries. JDK-8133206 would be one such example.
Just at build time
so - we introduce a runtime dependency on the underlying zlib libraries
on the OS by default. I would be very concerned with this approach.
We've run JDK 6 for 10+ years with zlib v1.1.3. It was consistent and
reliable for the most part. When we moved JDK7/8 to zlib v1.2.5, we
encountered an inflation issue[1]. When JDK was upgraded to zlib v1.2.8,
we received reports of performance/OOM issues [2].
but if the zlib on the platform is broken then it impacts tools and
probably lots of things. I would assume the OS would patch such issues
quickly. In the case of JDK-8133206 then was the issue addressed in
the libzip wrapper or in the zlib code? I thought it was the former.
The code change is proposed in the libzip wrapper but the issue was
triggered by the zlib library update.
On a fallback or some way to configure at launch time then Sandhya
Viswanathan (Intel) has a proposal here last year. I think we mostly
agreed on that thread that switching the build to use the system zlib
by default would be better.
I'm all for allowing one to introduce a new version of zlib to their JDK
at runtime. I just don't think it's in the interests of enterprises and
stability to introduce a dependency to the JDK on the underlying OS zlib
libraries. Could we at least consider a runtime property to allow
linking to the (currently bundled) zlib v.1.2.8 port in case issues arise ?
regards,
Sean.
[1] https://bugs.openjdk.java.net/browse/JDK-8044725
[2] https://bugs.openjdk.java.net/browse/JDK-8133206
