Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap

It looks to me like Collections.reverseOrder no longer deserializes to the same object. It also looks like the definition for that in Collections.java hasn't changed recently. So I suspect that there has been some serious incompatible change to deserialization itself. (It's another matter whether

Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap

On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz wrote: > It looks to me like Collections.reverseOrder no longer deserializes to the > same object. It also looks like the definition for that in > Collections.java hasn't changed recently. So I suspect that there has been

Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap

m(serialBytes(o))); T clone = (T) ois.readObject(); return clone; } catch (Throwable t) { throw new Error(t); } } } On Sat, Feb 9, 2013 at 3:31 PM, Martin Buchholz wrote: > > > On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz wrote: > &

Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap

Alright, now that the problem (if not the solution) is well understood, I leave it to you. Martin On Sun, Feb 10, 2013 at 2:54 AM, Alan Bateman wrote: > On 09/02/2013 23:31, Martin Buchholz wrote: > >> On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz >> wrote: >>

Backport 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

I think we should backport changeset: 6660:14e49a70729a user:martin date:2013-03-06 17:43 -0800 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so Summary: Define FILES_m to force use of linker script Reviewed-by: sherman, alanb, ohair If yes, please p

[7uN] Request for approval for CR 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

Here's the email thread http://mail.openjdk.java.net/pipermail/build-dev/2013-February/008076.html and here's the webrev: http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ On Fri, Mar 8, 2013 at 2:21 PM, Martin Buchholz wrote: > I think we should backport > >

Re: [7u-dev] Request for Review + Request for Approval to Backport: 8064391: More thread safety problems in core reflection

Approved! On Wed, Nov 26, 2014 at 3:36 AM, Ivan Gerasimov wrote: > Hello! > > Would you please approve the (almost) direct backport from jdk 8u to 7u? > > The difference, comparing to 8u changeset, is due to change in Class.java, > (which is already there in 8) and in GenericDeclRepository.java

Re: [7u-dev] Request for Review + Request for Approval to Backport: 8064391: More thread safety problems in core reflection

Approved! On Fri, Nov 28, 2014 at 5:37 AM, Ivan Gerasimov wrote: > Hello! > > Would you please approve the backport from jdk 8u to 7u? > > The patch didn't apply cleanly due to generics in these two files: > src/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java > src/share/classes/s

Re: [7u-dev] Request for Review + Request for Approval to Backport: 8064846: Lazy-init thread safety problems in core reflection

Looks good! On Fri, Dec 19, 2014 at 7:55 AM, Ivan Gerasimov wrote: > Hello! > > This is a request to approve the partial backport of the fix JDK-8064846. > The backport is very similar to the one for jdk8u. > I only had to modify GenericDeclRepository.java a bit due to omitted > generics. > > Tes

Re: [7u communication] 7u80 Timeline

When Oracle stopped working on openjdk6 update releases, our friends on distro-pkg-dev volunteered to take over maintenance. Perhaps there needs to be a staged handoff for openjdk7 as well? On Tue, Dec 30, 2014 at 3:35 AM, dalibor topic wrote: > Hi, > > In line with prior communication [1] to th

Re: RFR: 8134248: Fix recently backported tests to work with OpenJDK 7u

Looks good to me! (This may be the first time I've used my jdk7u Reviewer superpowers...) On Fri, Aug 21, 2015 at 2:52 PM, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8134248 > Webrev: http://cr.openjdk.java.net/~andrew/openjdk7/8134248/webrev.01/ > > As pointed out by

Re: OpenJDK 7u Tarballs

Thanks for doing this. It's sufficiently tricky (as you discovered) for someone to grab a revision of openjdk that is closest to having been an "official release") that it's a valuable service. I've also spent some time reading the hg tag tea leaves in the past. Some of those early "u" releases

Re: [PATCH] jdk7u91-b01 retro-active security patch review

Hi Andrew, thanks for your hard work. We will probably use these changes, and do a fair amount of testing. But that will take a while, probably too long for you to wait on us for review. I recently did a "mega-commit", and published a hg mq directory in addition to webrev. These kinds of change

Re: [PATCH] jdk7u91-b01 retro-active security patch review

On Wed, Oct 28, 2015 at 3:39 PM, Andrew Hughes wrote: > > > It is, but both versions of the webrev script I have produce them. Do you > know where I can get the latest version? webrev is the most forked piece of software in history. Naturally I have my own... But today there is a canonical one

Re: [PATCH] jdk7u91-b01 retro-active security patch review

> > > The 7u tree can always be retrieved from the IcedTea trees by checking out > the appropriate tag (jdk7u91-b01 in this case). This is worth bearing in > mind > if an updated raw OpenJDK tree is required before this upstream review > process > completes. Thanks - that's useful to know. If th

Re: [PATCH] jdk7u91-b01 retro-active security patch review

Unanswered patch on webrev-dev looks related: http://mail.openjdk.java.net/pipermail/webrev-dev/2015-November/000134.html My own old copy of webrev is working for me, so I dare not touch it! --- Thanks for your work on jdk7u91 - we are happily using it without problems! On Wed, Nov 18, 2015 at

Re: [PATCH] jdk7u101-b00 retro-active security patch review

A minor versioning bug: My latest IcedTea report $ java -version java version "1.7.0_101" OpenJDK Runtime Environment (IcedTea 2.6.6) (7u101-2.6.6-0ubuntu0.14.04.1) OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode) But notice that hotspot's minor version is still stuck at 95. ./hotspot/make/

Re: RFR(7u): JDK-8136570: Avoid setting environment variables related to /usr/dt

I support this backport. It fixes a crash! On Sun, Nov 6, 2016 at 12:30 PM, Tiago Daitx wrote: > Hi, > > Please review the backported changes for JDK-8136570 to 7u in the > inline patch bellow. > > JDK-8136570 : Stop > changing user environment