harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib]bug-to-bug compatibility: HashMap
Date Sat, 18 Mar 2006 22:20:27 GMT
Did we ever come to consensus on how to track these?

We are making a very deliberate and reasonable decision here to not be 
spec compliant, right?

I really would like us to note this.  I'll be happy to do it of course, 
but that won't scale - we should come to agreement on how we want to 
handle this, and make it the responsibliity of every committer to do the 
Right Thing when this happens in the future.

geir


Paulex Yang wrote:
> Hi,
> 
> I've raised JIRA-206 and attached patch to comply with RI.
> 
> Richard Liang wrote:
>> Hello Paulex,
>>
>> According to Java 5 Spec, "Note: great care must be exercised if 
>> mutable objects are used as map keys. The behavior of a map is not 
>> specified if the value of an object is changed in a manner that 
>> affects equals comparisons while the object is a key in the map...."
>>
>> As the behavior of a map is not specified, we can either keep 
>> compatible with RI, or leave it as is. But keeping compatible with RI 
>> may be a better solution. :-)
>>
>> Paulex Yang wrote:
>>> Hi, Mikhail,
>>>
>>> Mikhail Loenko wrote:
>>>> Hi Paulex,
>>>>
>>>> IMHO from compatibility point of view any behavior is legal.
>>>> HashMap is mostly designed for keys that do not change over time, at 
>>>> least
>>>> spec silent about changing the keys. So, I think implementation 
>>>> specsific is
>>>> allowed here.
>>>>
>>>> But I think that aiming stability we'd better compare current hash
>>>> with the original one - in this case get() result will depend on the 
>>>> hash
>>>> rather that on the inernal state of HashMap (such as HashMap length)
>>>>   
>>> I'm afraid the problem here is not the HashMap length,  whatever the 
>>> length is, this kind of problem can happen, 16 just make it more 
>>> easier, because it is not a prime number.
>>>
>>> So if my understanding is right, you suggest to cache the key's hash 
>>> value as *original* hash into HashMap.Entry, when the key/value pair 
>>> is put into HashMap; and when someone want to get back the value from 
>>> HashMap by the same key, the cached *original* hash will be compared 
>>> with the *current* hash, and if they are not equal, HashMap will 
>>> consider them as non-match, even the keys are *same* object. In fact 
>>> that's also my point of view to fix this non-compatibility. This fix 
>>> is not difficult, but the only concern is, this behaviour may be 
>>> controversial.
>>>
>>> thoughts?
>>>> Thanks,
>>>> Mikhail
>>>>
>>>> 2006/3/15, Paulex Yang <paulex.yang@gmail.com>:
>>>>  
>>>>> Pls. try the test case on HashMap below.
>>>>>
>>>>> On RI, it print out:
>>>>> null
>>>>> null
>>>>>
>>>>> On Harmony, it print out
>>>>> null
>>>>> value1
>>>>>
>>>>> it is definitely bad practice to reuse a object as hash key by modify
>>>>> its hashcode, but I DID see some similar cases before, after all, you
>>>>> cannot force but only can *suggest* developers what to do.
>>>>>
>>>>> So, what should we do?  Try to replicate RI's behavior?
>>>>>
>>>>>
>>>>> public class HashMapTest {
>>>>>  public static void main(String[] args) {
>>>>>  ReusableKey k = new ReusableKey();
>>>>>  HashMap map = new HashMap();
>>>>>  k.setKey(1);
>>>>>  map.put(k, "value1");
>>>>>
>>>>>  k.setKey(18);
>>>>>  //both RI and Harmony get null here
>>>>>  System.out.println(map.get(k));
>>>>>
>>>>>  k.setKey(17);
>>>>>  //RI get null
>>>>>  //Harmony get "value1"
>>>>>  //the number of 17 is *magic* because the default length of 
>>>>> HashMap is 16.
>>>>>  System.out.println(map.get(k));
>>>>>  }
>>>>> }
>>>>>
>>>>> class ReusableKey{
>>>>>  private int key = 0;
>>>>>  public void setKey(int key){
>>>>>  this.key = key;
>>>>>  }
>>>>>  public int hashCode(){
>>>>>  return key;
>>>>>  }
>>>>>  public boolean equals(Object o){
>>>>>  if(o == this){
>>>>>   return true;
>>>>>  }
>>>>>  if(!(o instanceof ReusableKey)){
>>>>>   return false;
>>>>>  }
>>>>>  return key == ((ReusableKey)o).key;
>>>>>  }
>>>>> }
>>>>>
>>>>>
>>>>> -- 
>>>>> Paulex Yang
>>>>> China Software Development Lab
>>>>> IBM
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>
>>>>   
>>>
>>>
>>
>>
> 
> 

Mime
View raw message