I'm actually very happy that we've dropped private patches against libz. And using the system libz seems like the right thing to do on Unix systems, where libz should be ubiquitous.
On Wed, Feb 10, 2016 at 4:25 PM, Xueming Shen <xueming.s...@oracle.com> 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. > > 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 >> >
