You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Spark Shen <sm...@gmail.com> on 2006/08/02 08:43:38 UTC
[classlib][luni] Is fully comply with Comparator.compare(T, T) necessary
(Re JIRA harmony 1026)
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)
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
Re: [classlib][luni] Is fully comply with Comparator.compare(T, T)
necessary (Re JIRA harmony 1026)
Posted by Spark Shen <sm...@gmail.com>.
Stepan Mishura 写道:
> On 8/2/06, Spark Shen wrote:
>>
>> 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.
>
>
> In other words, you don't expect that in your testcase the mock
> comparator
> will compare 'null's. Right?
No,it does not. This comparator is used to test the condition that once
null is used as the head element,
then no other elements can be contained in the returned SortedMap, even
if the other element is null.
So, to the extreme, I construct the mocked comparator like that.
Best regards
>
> Thanks,
> Stepan.
>
> 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
Re: [classlib][luni] Is fully comply with Comparator.compare(T, T) necessary (Re JIRA harmony 1026)
Posted by Stepan Mishura <st...@gmail.com>.
On 8/2/06, Spark Shen wrote:
>
> 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.
In other words, you don't expect that in your testcase the mock comparator
will compare 'null's. Right?
Thanks,
Stepan.
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
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
------------------------------------------------------
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
Re: [classlib][luni] Is fully comply with Comparator.compare(T, T)
necessary (Re JIRA harmony 1026)
Posted by Spark Shen <sm...@gmail.com>.
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 <sm...@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
Re: [classlib][luni] Is fully comply with Comparator.compare(T, T) necessary (Re JIRA harmony 1026)
Posted by Alexei Zakharov <al...@gmail.com>.
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,
2006/8/2, Spark Shen <sm...@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
>
>
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
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
Re: [classlib][luni] Is fully comply with Comparator.compare(T, T)
necessary (Re JIRA harmony 1026)
Posted by Spark Shen <sm...@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
Re: [classlib][luni] Is fully comply with Comparator.compare(T, T)
necessary (Re JIRA harmony 1026)
Posted by Richard Liang <ri...@gmail.com>.
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?
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
>
--
Richard Liang
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