harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Spark Shen <smallsmallor...@gmail.com>
Subject Re: [classlib][luni] Is fully comply with Comparator.compare(T, T) necessary (Re JIRA harmony 1026)
Date Wed, 02 Aug 2006 09:23:25 GMT
Alexei Zakharov 写道:
> Hi Spark,
>
>> When both are null, -1 will be returned. This mocked comparator is used
>> as a boundary test condition, and under this condition,
>> if there is null entry contained in tree map, is will not be included in
>> the SortedMap returned by headMap(null) method.
>
> IMHO you need to be carefull here since if o1==null and o2==null then
> both compare(o1,o2) and compare(o2,o1) will return -1. And the size of
> SortedMap depends on actual execution order of the comparison
> operators.
>
> SortedMap headMap(K key) {
> ...
> K curKey = ...;
> if (comparator.compare(curKey, key) < 0) {
> // true if key == null && curKey == null
> result.put(curKey,...)
> }
> ...
> return result;
> }
>
> Regards,
Agree. I think I'd better add:
if(o1 == o2) return 0; in the begining to deal with null comparision
problem.

But still, I hold to my point that under this condition it is not so
helpful to write extra code to fully comply with
the description on Spec about java.util.Comparator.compare(T, T) method.
Since the concern is only about null value.

Best regards.
>
> 2006/8/2, Spark Shen <smallsmallorgan@gmail.com>:
>> Richard Liang 写道:
>> >
>> >
>> > Spark Shen wrote:
>> >> I constructed a MockComparator as below:
>> >> public static class MockComparator<T> implements Comparator<T>
{
>> >> public int compare(T o1, T o2) {
>> >> if(null == o1) return -1;
>> >> if(o1.equals(o2)) {
>> >> return 0;
>> >> }
>> >> return 1;
>> >> }
>> >> }
>> >>
>> >> This comparator regards null as the smallest object and TreeMap uses
>> >> this Comparator as a null-tolerable comparator.
>> >> And this comparator is used to test the behavior of TreeMap.headMap()
>> >> when the input is null.
>> >>
>> >> Since null is recognized as smallest, the expected length of the
>> >> returned SortedMap of TreeMap.headMap(null) will be zero.
>> >>
>> >> My point here is that, under this situation, the MockComparator does
>> >> not care about the order of non-null objects, it just know
>> >> null is always smaller. So, is it acceptable that - in this
>> >> comparator, compare method does not judge the order of all the
>> >> non-null objects?
>> >> (does not comply with doc of comparator.compare)
>> >>
>> > What will happen when both o1 and o2 are null?
>> When both are null, -1 will be returned. This mocked comparator is used
>> as a boundary test condition, and under this condition,
>> if there is null entry contained in tree map, is will not be included in
>> the SortedMap returned by headMap(null) method.
>>
>> Best regards,
>>
>> >
>> > My understanding about mocked objects is that: we could only implement
>> > some necessary logic, but the logic must be compliant with the
>> > specification. Correct me if I'm wrong. Thanks a lot.
>> >
>> > Best regards,
>> > Richard
>> >> Best regards
>> >>
>> >
>>
>>
>> -- 
>> Spark Shen
>> China Software Development Lab, IBM
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>


-- 
Spark Shen
China Software Development Lab, IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message