This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

TreeSet and compareTo Java 5

 
Markus Schmider
Ranch Hand
Posts: 123
1
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hallo I have the following class



I want to add instances of this class to a TreeSet.
As far I have understood Sets you should be able to add an element which is not already contained in this set. To test this the equals() method is used.
When I try to put two different instances of the above class, which differ only in the jarFile field but have the same name value (compareTo returns 0) only the first instance is put into the TreeSet.
When I switch to a HashSet both instances are put into the Set.



Output:


This is totally unexpectated behavior for me, since I thought that only equals() is used to determined if an instance can be put into a Set, and compareTo() is only used for ordering.

Can anybody explain this behavior???

Many thanks,

Hans
 
Rodrigo Lopes
Ranch Hand
Posts: 119
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Extracted from http://java.sun.com/j2se/1.5.0/docs/api/java/util/TreeSet.html
:

"This is so because the Set interface is defined in terms of the equals operation, but a TreeSet instance performs all key comparisons using its compareTo (or compare) method, so two keys that are deemed equal by this method are, from the standpoint of the set, equal."
 
Joanne Neal
Rancher
Pie
Posts: 3742
16
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A HashSet will use the hashCode method first to compare two objects. If two objects return different hashCodes they are assumed to be different and the HashSet will not call either the equals or comapreTo method. As JarFile does not override hashCode it will use Object's implementation.
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects.


So as your hashCode method uses the JarFile hashCode method, unless the two JarFiles are the same object, it is very likely two different JClass objects will return different values from hashCode.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic