----- Original Message ----- > > On 19/09/2012 18:22, Andrew Hughes wrote: > > Sure, http://cr.openjdk.java.net/~andrew/zlib/webrev.01/ is the > > combined webrev. > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/35e024c6a62c is the > > original > > jdk8 changeset for 7110151. > > Thanks - let's get approval from Alan/Sherman then. I think Sherman > may > be OOTO at the moment. Once they're ok, I'll log a request for you to > integrate into 7u10 forests (once available). > > Well, I did propose it prior to stage 2. We're weren't given much > > notice that > > was going to happen (<1 week). > Yes, dates may not have been too clear around code freeze. I had > indicated that phase 2 process would begin in mid September though! >
Yes, I'm afraid the security update has meant 7u hasn't been high on the priority list the last couple of weeks. > On the subject of backports, are you still planning on porting > 7192804 > to 7u ? Yes, that does need to be backported. It's a simple fix. Does it look ok for u10? > > regards, > Sean. > > > > The reviewers were CCed on my original e-mail. > > > >> regards, > >> Sean. > >> > >> On 19/09/12 01:38, Andrew Hughes wrote: > >>> The MacOS X changes have added an option to jdk7u to use the > >>> system > >>> zlib library > >>> via setting SYSTEM_ZLIB=true. However, at present, this is > >>> broken > >>> on 64-bit GNU/Linux > >>> platforms, such that setting SYSTEM_ZLIB=true causes a build > >>> failure. > >>> > >>> I've already pushed a fix for this (7110151) to jdk8, which > >>> required a pre-requisite > >>> fix (7188852) to remove local changes to the zlib library. This > >>> is > >>> the first of two > >>> requests to get these fixes into 7u. > >>> > >>> 7188852, the subject of this request, moves the tracking of bytes > >>> read/written into > >>> Java code from native code. Standard system zlib tracks these > >>> values, but has an issue > >>> with possible overflow when the size of the zip goes over 4GB, > >>> such > >>> that the developers > >>> recommend that the application provides its own tracking: > >>> http://zlib.net/zlib_faq.html#faq32 > >>> At present, 7u has a fix applied to the in-tree zlib code to > >>> change > >>> the type of these > >>> fields. 7188852 removes this fix and instead implements tracking > >>> in the Java code. > >>> > >>> Bug report: > >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7188852 > >>> Public review: > >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/011011.html > >>> Webrev: http://cr.openjdk.java.net/~andrew/7188852/webrev.01/ > >>> > >>> The webrev is nearly identical to the original jdk8 changeset: > >>> > >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1468b0af0d06 > >>> > >>> The only necessary changes were to fix the paths to the zlib code > >>> (7u has 1.2.3, 8 has 1.2.5) > >>> and to apply the changes to Changelog_java & inflate.c manually, > >>> as > >>> the context differed slightly. > >>> The 7u webrev builds and the included test case passes. > >>> > >>> Ok for 7u10? > >>> > >>> Thanks, > >> > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
