RFR: JDK-8031767 Support system or alternative implementations of zlib
sean.coffey at oracle.com
Wed Feb 10 14:41:40 UTC 2016
On 10/02/16 14:29, Alan Bateman wrote:
> On 10/02/2016 13:57, Seán Coffey wrote:
>> 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 ?
> Don't the LD_* environment variables serve this need already? Once the
> JDK is using the system zlib then this is the simplest way to get it
> to use a different libz library at runtime.
No - I don't see that as a solution. You've still made the default JDK
config become dependent on OS environment for all libzip operations. I
don't think we even capture the zlib version that the JDK would be
operating with in any diagnostics. An application wanting a tried/tested
and stable libzip version has extra work to do now. Letting the default
be system dependent has just increased risk for QA teams also. A system
property just makes this all go away. In fact - I would say that for
JDK9, the default should be the JDK bundled libzip library. For those
looking for libzip experimenting and performance benefits, they could
take the system property approach.
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