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
