Looks good to me.
/Erik
On 2016-03-24 23:31, Xueming Shen wrote:
Thanks Erik!
Webrev has been updated accordingly.
http://cr.openjdk.java.net/~sherman/8031767/webrev/
-Sherman
On 03/24/2016 01:57 PM, Erik Joelsson wrote:
Hello,
Yes, I believe we still need to, the reason being that config
Thanks Erik!
Webrev has been updated accordingly.
http://cr.openjdk.java.net/~sherman/8031767/webrev/
-Sherman
On 03/24/2016 01:57 PM, Erik Joelsson wrote:
Hello,
Yes, I believe we still need to, the reason being that configure automatically
falls back to bundled if the headers are not avai
Hello,
Yes, I believe we still need to, the reason being that configure
automatically falls back to bundled if the headers are not available.
This is what happened when you initially tried your patch in JPRT. I
still think this is a good way for configure to behave in the general
case. In the
Erik,
I'm not familiar with the jib-profiles.js. So just want to confirm before
putting into
the webrev. The proposal is to build with system zlib by default for non-windows
platforms, without the need of specifying the configuration/build opton
--with-zlib=system. Do we still need to update thi
On 3/24/16 1:05 AM, Erik Joelsson wrote:
Hello,
As I wrote in the bug, jdk9/dev currently fails when using
--with-zlib=system with the new devkit on Linux. That will need to be
fixed first.
Has the JDK-8152352 fixed all the problems or there is something other
warning missing?
https://bugs
Hello again. Here is my suggested patch for the jib-profiles.js file.
This will enforce system zlib for Oracle builds on Linux, Solaris and
Macosx.
/Erik
diff -r 6da9e0c79eac common/conf/jib-profiles.js
--- a/common/conf/jib-profiles.js
+++ b/common/conf/jib-profiles.js
@@ -241,7 +241,7 @@
Hello,
As I wrote in the bug, jdk9/dev currently fails when using
--with-zlib=system with the new devkit on Linux. That will need to be
fixed first.
If the intention of this change is to enforce --with-zlib=system on
OracleJDK builds, we should also update the Jib profile definitions for
Li
Hi,
This one was discussed back to Feb, and have been waiting for the devkit
clearance
from the build-dev, which has just been resolved [1]. So here is webrev again.
http://cr.openjdk.java.net/~sherman/8031767/webrev
thanks!
Sherman
[1] https://bugs.openjdk.java.net/browse/JDK-8149545
btw,
, February 11, 2016 10:49 AM
To: Seán Coffey
Cc: build-dev; core-libs-dev
Subject: Re: RFR: JDK-8031767 Support system or alternative implementations of
zlib
Currently the pendulum is swinging away from multiple applications
sharing common libraries towards every application being
self-contained
Currently the pendulum is swinging away from multiple applications
sharing common libraries towards every application being
self-contained, perhaps because disk space is dirt cheap and because
of the rise of "containers". It may be that much of the packaging of
jdks will be picked up by third part
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 l
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 wrote:
>
> One of the benefits of moving to the system libz is actua
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 gi
There's an endless debate about the pros and cons of "dynamic linking".
I think it would be best for the JDK to link to system libraries by
default, if possible.
For a particular JDK image, one can drop a patched libz into a
suitable lib directory to override the system one.
It should also be rel
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
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 conside
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. JD
On 2016-02-05 21:50, Alan Bateman wrote:
On 05/02/2016 18:55, Xueming Shen wrote:
Hi
Please help codereview the change to build the jdk9 runtime to use
the system zlib on
Solaris and Linux platforms by default.
Issue: https://bugs.openjdk.java.net/browse/JDK-8031767
Webrev: http://cr.openjdk
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.
Jus
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.
Regards,
Sean.
On 05/02/2016 18:55, Xuemin
On 05/02/2016 18:55, Xueming Shen wrote:
Hi
Please help codereview the change to build the jdk9 runtime to use the
system zlib on
Solaris and Linux platforms by default.
Issue: https://bugs.openjdk.java.net/browse/JDK-8031767
Webrev: http://cr.openjdk.java.net/~sherman/8031767/webrev/
I'm hap
Hi
Please help codereview the change to build the jdk9 runtime to use the
system zlib on
Solaris and Linux platforms by default.
Issue: https://bugs.openjdk.java.net/browse/JDK-8031767
Webrev: http://cr.openjdk.java.net/~sherman/8031767/webrev/
Background info:
Compression is heavily used in
22 matches
Mail list logo
