RFR: JDK-8031767 Support system or alternative implementations of zlib

[Seán Coffey]

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