Re: Asking about the interesting behaviours of TreeMap.putAll

2012-03-05 Thread Charles Lee
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

Re: Asking about the interesting behaviours of TreeMap.putAll

2012-03-05 Thread David Holmes
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: Asking about the interesting behaviours of TreeMap.putAll

2012-03-05 Thread Mike Duigou
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

Re: Asking about the interesting behaviours of TreeMap.putAll

2012-03-05 Thread Doug Lea
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

2012-03-05 Thread David Holmes
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

2012-03-05 Thread David Holmes
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

2012-03-05 Thread David Holmes
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

2012-03-05 Thread Charles Lee
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

Re: Asking about the interesting behaviours of TreeMap.putAll

2012-03-04 Thread David Holmes
Hi Charles, I'm not quite sure what you are suggesting. In my opinion all that is needed is for AbstractMap.putAll to read: Copies all of the mappings from the specified map to this map (optional operation). The behavior of this operation is undefined if the specified map is modified while t

Re: Asking about the interesting behaviours of TreeMap.putAll

2012-03-04 Thread Charles Lee
Hi David, I also notice that in the AbstractMap doc, it also says: "The documentation for each non-abstract method in this class describes its implementation in detail. Each of these methods may be overridden if the map being implemented admits a more efficient implementation. " If this is th

Re: Asking about the interesting behaviours of TreeMap.putAll

2012-03-02 Thread David Holmes
HI Charles, I tend to agree with you. In this case, in my opinion, AbstractMap.putAll has no business saying that it is equivalent to calling put() as that should be part of the implementation note, not the actual spec. Subclasses should be free to implement putAll in the most efficient manne

Asking about the interesting behaviours of TreeMap.putAll

2012-03-02 Thread Charles Lee
Hi guys, I have a small test case[1] and the two invokes of putAll have different behaviors: the first invocation does not use the override put but the second invocation does. The root cause about this can be find in the TreeMap code: /if (size==0 && mapSize!=0 && map instanceof SortedMap) {