harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib]bug-to-bug compatibility: HashMap
Date Sun, 19 Mar 2006 15:16:53 GMT
Mikhail Loenko wrote:
> Geir,
> 
> 2006/3/19, Geir Magnusson Jr <geir@pobox.com>:
>> 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?
> 
> not exactly. The spec says that "behavior of a map is not specified"
> so anything we do is spec compliant.
> 
> what we did is we chose the best behavior from many compliant ones

well, the proposal on the table is to 'copy the reference implementation
behavior' (if that is how you choose to define 'best').

Regards,
Tim

> Thanks
> Mikhail
> 
>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message