Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of aleksey.shipilev@gmail.com
 designates 209.85.198.244 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=w2xR87mnrfg5d2LOKcFIjjAsLg/nbduYpvhE3jbWEU45bnWLIpficasPEex6bPPbZr
         x/jAjA8qo/lklRpZb9SDrntsxq7+A2x6wg9awOkT8vdNgzQfQpAOdHGJo3Hgm7s7CN1U
         34hSaeabrQuJS++LaVGerJ6RaTlxelVAJn1N4=
MIME-Version: 1.0
In-Reply-To: <49771881.7020704@gmail.com>
References: <49770FB7.5020404@gmail.com>
	 <4bebff790901210421y2a8bbb39ge833cccf849e145a@mail.gmail.com>
	 <49771881.7020704@gmail.com>
Date: Wed, 21 Jan 2009 15:47:45 +0300
Message-ID: <4bebff790901210447h77f1b8fbt36f0f1122450bf42@mail.gmail.com>
Subject: Re: [eut][classlib][luni] different behaviors of TreeSet.remove()
	between RI and Harmony
From: Aleksey Shipilev <aleksey.shipilev@gmail.com>
To: dev@harmony.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Yeah, that was a lucky coincidence.

I had changed:
-       Entry temp = new Entry(2);
+       Entry temp = new Entry(10);

...and both RI and Harmony prints out "false".

Thanks,
Aleksey.

On Wed, Jan 21, 2009 at 3:43 PM, Regis <xu.regis@gmail.com> wrote:
>
> Aleksey Shipilev wrote:
>>
>> Hi Regis,
>>
>>> From Java class library side, the behaviour in this case is unspecified.
>>
>> I believe you hit on the known issue with EUT, please refer to
>> archived Harmony thread [1]. Reading back that thread you might notice
>> that this is the inconsistency in EUT which (by some miracle occasion)
>> works well with RI. There's the Eclipse bug against that submitted
>> [2].
>>
>> Thanks,
>> Aleksey.
>>
>> [1] http://markmail.org/message/svoktdxopww6sv7p
>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=212583
>>
>> On Wed, Jan 21, 2009 at 3:06 PM, Regis <xu.regis@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I track the eut test testAddWorkingSet in org.eclipse.ui.tests, found
>>> this
>>> failure was caused by Harmony TreeSet can't remove a element already in
>>> the
>>> set. After further investigation, I found the test changed the elements
>>> after added them to set, that corrupt the set, but RI could remove the
>>> element successfully even the set is not ordered.
>>>
>>> Following test demo the scenario:
>>>
>>> public class TestTreeSet {
>>>   public static void main(String[] args) {
>>>       TreeSet set = new TreeSet();
>>>       Entry temp = new Entry(2);
>>>       set.add(new Entry(1));
>>>       set.add(temp);
>>>       set.add(new Entry(3));
>>>       set.add(new Entry(4));
>>>       set.add(new Entry(5));
>>>       set.add(new Entry(6));
>>>       temp.setValue(0);
>>>
>>>       for (Iterator iterator = set.iterator(); iterator.hasNext();) {
>>>           Entry entry = (Entry) iterator.next();
>>>           System.out.println(entry.value);
>>>       }
>>>
>>>       System.out.println(set.remove(temp));
>>>   }
>>>
>>>   public static class Entry implements Comparable {
>>>       private int value;
>>>
>>>       public Entry(int value) {
>>>           this.value = value;
>>>       }
>>>
>>>       public void setValue(int value) {
>>>           this.value = value;
>>>       }
>>>
>>>       public int getValue() {
>>>           return value;
>>>       }
>>>
>>>       public int compareTo(Object arg0) {
>>>           return value - ((Entry) arg0).value;
>>>       }
>>>   }
>>>
>>>   public static class TestComparator implements Comparator {
>>>
>>>       public int compare(Object arg0, Object arg1) {
>>>           return ((Entry) arg0).getValue() - ((Entry) arg1).getValue();
>>>       }
>>>
>>>   }
>>> }
>>>
>>> output of RI:
>>> 1
>>> 0
>>> 3
>>> 4
>>> 5
>>> 6
>>> true
>>>
>>> output of Harmony:
>>> 1
>>> 0
>>> 3
>>> 4
>>> 5
>>> 6
>>> false
>>>
>>> In Harmony, binary search is used to find the element, in this case, the
>>> array is not ordered, so it can't work correctly. From spec:
>>>
>>> "The set will not contain the specified element once the call returns"
>>>
>>> So I think RI's behavior is more reasonable.
>>>
>>> This can be fixed by comparing every element in set when remove, but will
>>> cause performance downgrade, what do you think? Any suggestions/ideas?
>>>
>>> --
>>> Best Regards,
>>> Regis.
>>>
>>
>
> Thanks for your informations, Aleksey.
>
> --
> Best Regards,
> Regis.
>