You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by "Craig Russell (JIRA)" <ji...@apache.org> on 2006/04/06 20:51:27 UTC

[jira] Commented: (JDO-364) Completness tests fail with generated implementation classes for interfaces

    [ http://issues.apache.org/jira/browse/JDO-364?page=comments#action_12373529 ] 

Craig Russell commented on JDO-364:
-----------------------------------

The implementation of the static compare methods in each class might delegate to a common static method in EqualityHelper to do the comparisons, e.g. 

class Department {
...
static int compare(IDepartment o1, IDepartment o2) {
return EqualityHelper.compare(o1.getDeptid(), o2.getDeptid());
}

class EqualityHelper {
...
static int compare (long l1, long l2) {
        return (l1 < l2 ? -1 : (l1 == l2 ? 0 : 1));
}

Interestingly, there is no static compare method in Integer, Long, Short, etc, although there is a compareTo method if you happen to have an instance of Long etc. For example, I'd like to see in class Long the static compare method above. The alternative is to do (in JDK 1.5 only) return Long.valueOf(l1).compareTo(l2); or in JDK (any) return new Long(l1).compareTo(l2).


> Completness tests fail with generated implementation classes for interfaces
> ---------------------------------------------------------------------------
>
>          Key: JDO-364
>          URL: http://issues.apache.org/jira/browse/JDO-364
>      Project: JDO
>         Type: Bug

>   Components: tck20
>     Versions: JDO 2 rc1
>     Reporter: Craig Russell
>     Assignee: Michael Bouschen
>      Fix For: JDO 2 final

>
> Completeness tests fail while comparing collections of persistent interfaces. This is because EqualityHelper invokes Collections.sort(Collection), which requires that the instances in the parameter Collection implement compareTo. The instances are not required by the specification to implement compareTo; therefore a Comparator must be provided to the sort method.
> Further, classes Department and FullTimeEmployee incorrectly cast to the class instead of the interface in the deepCompareFields method.
> Finally, the root classes Address, Company, Department, Insurance, Person, and Project need to implement the compare(Object, Object) methods directly, as there are three instances involved: the Comparator instance, which is an instance of the class, and the two instances to be compared. Both of the instances to be compared might be of the JDO-generated classes, which don't implement any comparison methods. The compare(Object, Object), compareTo(Object), and compareTo(SpecificInterface) should be refactored to use a common implementation using only the interface for comparison.
> As a specification activity beyond JDO 2.0, we might consider adding metadata to require the JDO implementation to generate comparison methods from the Comparable or Comparator interfaces based on field values. For datastore identity, simply tagging the interfaces, e.g. "interface IDepartment extends Comparable", doesn't give the implementation enough information as to which fields to compare.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira