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

[Seán Coffey]

On 11/02/2016 00:25, Xueming Shen wrote:
>
> One of the benefits of moving to the system libz is actually for 
> better/easy
> maintenance. Just replacing the offending version of libz with an 
> earlier/later
> version that works, instead of waiting for a customized jdk/jre image 
> with a
> working/bundled libz, or the next update release. Especially given the 
> fact
> that we have decided not to touch the libz at source level. Having 
> dependency
> on the system libz is really not that bad. The experience suggests those
> binaries are quite stable. And it should always be easier to replace the
> system libz than a java runtime, in case of problem.

I think people overestimate people's ability to 'just replace' a zlib 
library. Adding a new system property is a struggle for some 
enterprises. We'll enjoy supporting a many to one matrix of zlib:JDK 
scenarios now rather than old style 1:1. It's great to have system 
library support - I'm just highlighting a possible risk. A fall back 
option solves that but there's no appetite for such a solution. Let's 
see how it goes.

regards,
Sean.
>
> Sherman
>
> On 02/10/2016 06:41 AM, Seán Coffey wrote:
>>
>> 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.
>>
>> regards,
>> Sean.
>>>
>>> -Alan
>>
>>
>> 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
>>
>