Re: Code review request: 7151348: Build breaks due to warning clean up in sun.rmi.*(7146763)

On 3/5/12 5:33 PM, Stuart Marks wrote: Actually I think I see the problem. In the original changeset, sun/rmi/rmic/Main.java was changed as follows: - environmentClass = envClass; + environmentClass = BatchEnvironment.class.asSubclass(environmentClass); This should have been + environmentClass

Re: Asking about the interesting behaviours of TreeMap.putAll

Hi guys, Sorry for the late reply. I agree with David. There are two types of "effect" in my mind: 1. "Associates the specified value with the specified key in this map (optional operation). If the map previously contained a mapping for the key, the old value is replaced by the specified value

hg: jdk8/tl/jdk: 7149012: jarsigner needs not warn about cert expiration if the jar has a TSA timestamp

Changeset: 26ed9a64a318 Author:weijun Date: 2012-03-06 10:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26ed9a64a318 7149012: jarsigner needs not warn about cert expiration if the jar has a TSA timestamp Reviewed-by: xuelei ! src/share/classes/sun/security/tools/JarSign

hg: jdk8/tl/jdk: 7151348: Build breaks due to warning clean up in sun.rmi.*(7146763)

Changeset: ce6b852bf4e2 Author:khazra Date: 2012-03-05 17:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce6b852bf4e2 7151348: Build breaks due to warning clean up in sun.rmi.*(7146763) Summary: Undo changes to sun/rmi/rmic/* commited as fix for 7146763 Reviewed-by: smarks

Re: Code review request: 7151348: Build breaks due to warning clean up in sun.rmi.*(7146763)

On 3/5/12 5:13 PM, Kurchi Hazra wrote: jdk8 build is breaking if SKIP_BOOT_CYCLE is set to false due to some changes made as a part of warnings cleanup in sun.rmi.* (see 7146763) that are incompatible with the code in the corba respository. This CR is simply to revert back the changes made to fi

Code review request: 7151348: Build breaks due to warning clean up in sun.rmi.*(7146763)

Hi, jdk8 build is breaking if SKIP_BOOT_CYCLE is set to false due to some changes made as a part of warnings cleanup in sun.rmi.* (see 7146763) that are incompatible with the code in the corba respository. This CR is simply to revert back the changes made to files in sun/rmi/rmic for the ti

Re: Asking about the interesting behaviours of TreeMap.putAll

I've been on both sides of these "bugs" over the years. The problem in general is that there is no definition of what "equivalent" means. In this particular case I don't think there was any need for Map to even mention the "equivalence": "Copies all of the mappings from the specified map to th

Re: RFR 7147666 : High lock time for com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance()

Thanks Andrew, Alan and Lance for the quick review! I agree, there's no need for the synchronization in the current code. It was historical. There was a public set method in its earlier versions. The whitespace was intentional to keep it in sync with Apache code, just so we don't get the cla

Re: RFR 7147666 : High lock time for com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance()

looks ok joe -lance On Mar 5, 2012, at 1:46 PM, Joe Wang wrote: > Hi all, > > This is a low risk, proven patch made in Xerces back in 2007 [1], removing > unnecessary "synchronization" in DTDDVFactory. As reported in 7147666, this > patch improves performance in one of the xml test. > > Webr

Re: RFR 7147666 : High lock time for com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance()

On 05/03/2012 18:46, Joe Wang wrote: Hi all, This is a low risk, proven patch made in Xerces back in 2007 [1], removing unnecessary "synchronization" in DTDDVFactory. As reported in 7147666, this patch improves performance in one of the xml test. Webrev : http://cr.openjdk.java.net/~joehw/7

Re: RFR 7147666 : High lock time for com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance()

- Original Message - > Hi all, > > This is a low risk, proven patch made in Xerces back in 2007 [1], > removing unnecessary "synchronization" in DTDDVFactory. As reported > in > 7147666, this patch improves performance in one of the xml test. > > Webrev : http://cr.openjdk.java.net/~joeh

RFR 7147666 : High lock time for com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance()

Hi all, This is a low risk, proven patch made in Xerces back in 2007 [1], removing unnecessary "synchronization" in DTDDVFactory. As reported in 7147666, this patch improves performance in one of the xml test. Webrev : http://cr.openjdk.java.net/~joehw/7u4/cr7147666/webrev/ [1] http://svn.a

hg: jdk8/tl/jdk: 7078053: Solaris JDK build: C compiler writing tmp files into the make tree

Changeset: 8b4309cbd999 Author:prr Date: 2012-03-05 09:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b4309cbd999 7078053: Solaris JDK build: C compiler writing tmp files into the make tree Reviewed-by: ohair, alanb ! make/java/nio/Makefile ! make/sun/xawt/Makefile

Re: Asking about the interesting behaviours of TreeMap.putAll

I'm in agreement with Doug on this. "The effect of this call is equivalent to that of calling put(k, v) on this map once for each mapping from key k to value v in the specified map." is not the same as "The effect of this call is to call put(k, v) on this map once for each mapping from key k to

hg: jdk8/tl/jdk: 2 new changesets

Changeset: a9840446d677 Author:vinnie Date: 2012-03-05 14:13 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a9840446d677 7151109: backout CR 6988842 Reviewed-by: mullan ! make/sun/security/Makefile ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/s

Reviewer needed: 6282196 There should be Math.mod(number, modulo) methods

Hi, CR 6282196 There should be Math.mod(number, modulo) methods http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282196 Requests that floor and modulus methods be provided for primitive types. Floor division is pretty straight-forward, rounding toward minus infinity. For modulus of int and

Re: Asking about the interesting behaviours of TreeMap.putAll

On 03/05/12 05:53, David Holmes wrote: Charles, I just realized that your webrev is for Map not AbstractMap and that it is Map the states putAll does a put() on each entry. No, Map says: The effect of this call is equivalent to that of calling put(k, v) on this map once for each mapping from

Re: Asking about the interesting behaviours of TreeMap.putAll

Charles, I just realized that your webrev is for Map not AbstractMap and that it is Map the states putAll does a put() on each entry. This changes things. It is much harder, perhaps not even possible to change Map even if we think the spec is overly constraining. David - On 5/03/2012 8

Re: Asking about the interesting behaviours of TreeMap.putAll

FYI CR 7151065 filed. David On 5/03/2012 7:50 PM, David Holmes wrote: On 5/03/2012 7:13 PM, Charles Lee wrote: Hi David, I am sorry for the unclear. I was suggesting to add some implementation notes on the TreeMap The change as you suggested is great. The patch is @ http://cr.openjdk.jav

Re: Asking about the interesting behaviours of TreeMap.putAll

On 5/03/2012 7:13 PM, Charles Lee wrote: Hi David, I am sorry for the unclear. I was suggesting to add some implementation notes on the TreeMap The change as you suggested is great. The patch is @ http://cr.openjdk.java.net/~littlee/map-putall/webrev.00/

Re: Asking about the interesting behaviours of TreeMap.putAll

Hi David, I am sorry for the unclear. I was suggesting to add some implementation notes on the TreeMap The change as you suggested is great. The patch is @ http://cr.openjdk.java.net/~littlee/map-putall/webrev.00/ . Is it ok