You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Dennis Balkir (JIRA)" <ji...@apache.org> on 2017/08/09 10:05:00 UTC
[jira] [Updated] (OFBIZ-9562) [FB] Package
org.apache.ofbiz.base.concurrent
[ https://issues.apache.org/jira/browse/OFBIZ-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Balkir updated OFBIZ-9562:
---------------------------------
Description:
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 {{(x.compareTo(y)==0) == (x.equals(y))}}. 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."
was:
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 (x.compareTo(y)==0) == (x.equals(y)). 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."
> [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
> Priority: Minor
>
> 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 {{(x.compareTo(y)==0) == (x.equals(y))}}. 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)