RFR: JDK-8031767 Support system or alternative implementations of zlib
sean.coffey at oracle.com
Wed Feb 10 13:57:58 UTC 2016
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. When JDK was upgraded to zlib v1.2.8,
we received reports of performance/OOM issues .
> 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 ?
More information about the build-dev