> Question is what to do about Comparable ... Compareable<?> does not
> work; since all I really know is that these two things are objects; in
> Java 1.4 you could throw an Object at any Comparable implementation and
> hope for the best; I am a bit worried I need to do instanceof checks here.
>
>> protected int compare( SimpleFeature feature1, SimpleFeature feature2,
>> SortBy order){
>> PropertyName name = order.getPropertyName();
>> Comparable value1 = (Comparable) name.evaluate( feature1 );
>> Comparable value2 = (Comparable) name.evaluate( feature2 );
>> if( order.getSortOrder() == SortOrder.ASCENDING ){
>> return value1.compareTo( value2 );
>> }
>> else return value2.compareTo( value1 );
>> }
The above code is correct regarding Comparable contract, we can keep it
unchanged and just add @SuppressWarnings("unchecked") in the method
declaration.
We can not compare two Comparable<?>. We could compare two Comparable<Object>,
but we have no garantee that it is what we get in the above code.
Unless we had something like PropertyName.getEvaluatedClass(), the above is
really unsafe but still compliant with Java contract, and we can't do much
better. The "instanceof" statement can't take in account the parameterized type
because of the way it is currently implemented in the Java language, by erasure
(note: there is ongoing discussion for "erase erasure" in some future Java
version - hot topic because of compatibility issues).
The Comparable contract said explicitly that ClassCastException are expected
when trying to compare two objects that can not be compared each other:
http://java.sun.com/javase/6/docs/api/java/lang/Comparable.html#compareTo(T)
ClassCastException is also what we get when we break the type safety system
provided by parameterized type through unsafe code. Finally, the above method
is
close in spirit to Comparator.compare(T, T) method, which is also explicitly
defined to throw ClassCastException when trying to compare incomparable objects.
So my proposal is to keep the code as-is, add @SuppressWarnings("unchecked") in
method declaration, add an explicit "throws ClassCastException" clause and
document this exception in the javadoc. This is fully consistent with
Comparable
contract, Comparator contract and the way parameterized type are implemented
for
dealing with unsafe code, so the overall picture seems consistent to me.
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
