Jacques Le Roux reassigned OFBIZ-9562:

    Assignee: Jacques Le Roux

> [FB] Package org.apache.ofbiz.base.concurrent
> ---------------------------------------------
>                 Key: OFBIZ-9562
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-9562
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: base
>    Affects Versions: Trunk
>            Reporter: Dennis Balkir
>            Assignee: Jacques Le Roux
>            Priority: Minor
>         Attachments: OFBIZ-No_org.apache.ofbiz.base.concurrent_bugfixes.patch
> ExecutionPool.java:122, EQ_COMPARETO_USE_OBJECT_EQUALS
> Eq: org.apache.ofbiz.base.concurrent.ExecutionPool$Pulse defines 
> compareTo(Object) and uses Object.equals()
> This class defines a compareTo(...) method but inherits its equals() method 
> from java.lang.Object. Generally, the value of compareTo should return zero 
> if and only if equals returns true. If this is violated, weird and 
> unpredictable failures will occur in classes such as PriorityQueue. In Java 5 
> the PriorityQueue.remove method uses the compareTo method, while in Java 6 it 
> uses the equals method.
> From the JavaDoc for the compareTo method in the Comparable interface:
> It is strongly recommended, but not strictly required that 
> {{(a.compareTo(b)==0) == (a.equals(b))}}. Generally speaking, any class that 
> implements the Comparable interface and violates this condition should 
> clearly indicate this fact. The recommended language is "Note: this class has 
> a natural ordering that is inconsistent with equals."

This message was sent by Atlassian JIRA

Reply via email to