You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Felix Knecht (JIRA)" <ji...@apache.org> on 2010/06/05 08:16:27 UTC
[jira] Created: (DIRSERVER-1516) Classes implementing compareTo
should also implement equals (and thus hashCode)
Classes implementing compareTo should also implement equals (and thus hashCode)
-------------------------------------------------------------------------------
Key: DIRSERVER-1516
URL: https://issues.apache.org/jira/browse/DIRSERVER-1516
Project: Directory ApacheDS
Issue Type: Bug
Environment: All
Reporter: Felix Knecht
Following classes are lacking this problem
[apacheds-protocol-ntp]
org.apache.directory.server.ntp.messages.LeapIndicatorType
org.apache.directory.server.ntp.messages.ModeType
org.apache.directory.server.ntp.messages.ReferenceIdentifier
org.apache.directory.server.ntp.messages.StratumType
http://findbugs.sourceforge.net/bugDescriptions.html#EQ_COMPARETO_USE_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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRSERVER-1516) Classes implementing compareTo
should also implement equals (and thus hashCode)
Posted by "Felix Knecht (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Knecht updated DIRSERVER-1516:
------------------------------------
Description:
Following classes are lacking this problem
[apacheds-protocol-dhcp]
org.apache.directory.server.dhcp.messages.MessageType
[apacheds-protocol-ntp]
org.apache.directory.server.ntp.messages.LeapIndicatorType
org.apache.directory.server.ntp.messages.ModeType
org.apache.directory.server.ntp.messages.ReferenceIdentifier
org.apache.directory.server.ntp.messages.StratumType
http://findbugs.sourceforge.net/bugDescriptions.html#EQ_COMPARETO_USE_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:
Following classes are lacking this problem
[apacheds-protocol-ntp]
org.apache.directory.server.ntp.messages.LeapIndicatorType
org.apache.directory.server.ntp.messages.ModeType
org.apache.directory.server.ntp.messages.ReferenceIdentifier
org.apache.directory.server.ntp.messages.StratumType
http://findbugs.sourceforge.net/bugDescriptions.html#EQ_COMPARETO_USE_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."
> Classes implementing compareTo should also implement equals (and thus hashCode)
> -------------------------------------------------------------------------------
>
> Key: DIRSERVER-1516
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1516
> Project: Directory ApacheDS
> Issue Type: Bug
> Environment: All
> Reporter: Felix Knecht
>
> Following classes are lacking this problem
> [apacheds-protocol-dhcp]
> org.apache.directory.server.dhcp.messages.MessageType
> [apacheds-protocol-ntp]
> org.apache.directory.server.ntp.messages.LeapIndicatorType
> org.apache.directory.server.ntp.messages.ModeType
> org.apache.directory.server.ntp.messages.ReferenceIdentifier
> org.apache.directory.server.ntp.messages.StratumType
> http://findbugs.sourceforge.net/bugDescriptions.html#EQ_COMPARETO_USE_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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRSERVER-1516) Classes implementing compareTo
should also implement equals (and thus hashCode)
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSERVER-1516:
-----------------------------------------
Fix Version/s: 2.0.0-RC1
Scheduled to RC1, but can be finished on RC2
> Classes implementing compareTo should also implement equals (and thus hashCode)
> -------------------------------------------------------------------------------
>
> Key: DIRSERVER-1516
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1516
> Project: Directory ApacheDS
> Issue Type: Bug
> Environment: All
> Reporter: Felix Knecht
> Fix For: 2.0.0-RC1
>
>
> Following classes are lacking this problem
> [apacheds-protocol-dhcp]
> org.apache.directory.server.dhcp.messages.MessageType
> [apacheds-protocol-ntp]
> org.apache.directory.server.ntp.messages.LeapIndicatorType
> org.apache.directory.server.ntp.messages.ModeType
> org.apache.directory.server.ntp.messages.ReferenceIdentifier
> org.apache.directory.server.ntp.messages.StratumType
> http://findbugs.sourceforge.net/bugDescriptions.html#EQ_COMPARETO_USE_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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.