[
https://issues.apache.org/jira/browse/OFBIZ-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-9562.
----------------------------------
Resolution: Implemented
Fix Version/s: Upcoming Release
Thanks Dennis,
Your patch is in trunk at revision: 1804634
> [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
> Fix For: Upcoming Release
>
> 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
(v6.4.14#64029)
