I need to implement equals() and hashCode() for an Address class.
I believe,the non null fields are taken to determine hashCode() and equals().In my application,Any of the fields except addressLine1 and country can be null.If that is the case,what happens if two different addresses have the same addressline1 and country?
Address1:(in state of NH which is omitted by user)
addressline1:111,maple avenue
country: US
Address2:
addressline1:111,maple avenue
state: Illinois
country: US
In such cases if I build a hashCode based only on non null fields ,it will give same for both addresses above.
Is this the right way to create hashCode?
int hash = addressline.hashCode();
if(addressLine2!=null){
hash += addressLine2.hashCode();
}
and so on...
Typically you would check whether one is null and the other is not in your equals method. For hashcode, you would just use 0 as the null hashcode. Example:
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((addressLine1 == null) ? 0 : addressLine1.hashCode());
result = prime * result + ((state == null) ? 0 : state.hashCode());
result = prime * result + ((country == null) ? 0 : country.hashCode());
return result;
}
If you use an IDE, it will usually generate these for you. In eclipse, choose Source, Generate equals and hashcode and it will let you select the fields you want to be a part of your equals and hashcode methods. For the equals method and your fields, this is what eclipse creates:
public boolean equals(Object obj) {
if (this == obj) return true;
if (obj == null) return false;
if (getClass() != obj.getClass()) return false;
YourClass other = (YourClass) obj;
if (addressLine1 == null) {
if (other.addressLine1 != null) return false;
} else if (!addressLine1.equals(other.addressLine1)) return false;
if (country == null) {
if (other.country != null) return false;
} else if (!country.equals(other.country)) return false;
if (state == null) {
if (other.state != null) return false;
} else if (!state.equals(other.state)) return false;
return true;
}
I would use that as a starting point and make any changes you think are neccessary from there.
Even fields that are null should be compared for equality. Use code like the following
to compare two fields of nonprimitive types, like String:
this.addressline==null ? other.addressline==null : this.addressline.equals(other.addressline)
For hash codes, use the same fields you used in equals, but you can treat null values as
having a hash code of 0 (or any other hash code value).
Here's the canonical question:
What issues should be considered when overriding equals and hashCode in Java?
And here are discussions of libraries that help you implement these methods properly:
Apache Commons equals/hashCode builder (also discusses Guava)
Related
i'm new in java collections so i tried to codes using Map.
i set my collection like this
Map<Integer, Person> people = new HashMap<>();
people.put(1, new Person("Arnold", "Maluya", 25));
people.put(2, new Person("Mison", "Drey", 3));
people.put(3, new Person("James", "Valura", 54));
people.put(4, new Person("Mikee", "Sandre", 24));
so my goal is i want to check if people contains object like "new Person("Arnold", "Maluya", 25)" so what i did is this
boolean test = people.containsValue(new Person("Arnold", "Maluya", 25));
System.out.println(test);
which is i getting "false" result. so am i getting it right so if sumthing is wrong what did i miss?
Implement an equals, example:
public class Person {
private String name;
private String lastName;
private String age;
#Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Person person = (Person) o;
if (name != null ? !name.equals(person.name) : person.name != null) return false;
if (lastName != null ? !lastName.equals(person.lastName) : person.lastName != null) return false;
return age != null ? age.equals(person.age) : person.age == null;
}
#Override
public int hashCode() {
int result = name != null ? name.hashCode() : 0;
result = 31 * result + (lastName != null ? lastName.hashCode() : 0);
result = 31 * result + (age != null ? age.hashCode() : 0);
return result;
}
}
The methods hashCode() and equals() play a distinct role in the objects you insert into Java collections.
equals() is used in most collections to determine if a collection contains a given element.
When inserting an object into a hastable you use a key. The hash code of this key is calculated, and used to determine where to store the object internally. When you need to lookup an object in a hashtable you also use a key. The hash code of this key is calculated and used to determine where to search for the object.
When you use your custom java objects in collections, its always advisable to override hashCode() & equals() methods, to avoid weird behaviors.
The behavior is correct as you are not overriding the equals method in Person class. Map will consult with equals method of the object stored in it to identify whether the query is matching with stored values. You must override the equals method in your object and implement logic appropriately to determine whether object passed as an argument is matching or not.
Note: Below code doesn't check for null values and hence may throw an exception. You need to put additional conditions to avoid null pointer exceptions.
#Override
public boolean equals(Object obj) {
if (!(obj instanceof Person)) {
return false;
}
Person other = (Person) obj;
if ((other.firstName.equals(this.firstName)) && (other.lastName.equals(this.lastName))
&& (other.age == this.age)) {
return true;
}
return false;
}
I have a Class Levels which has a hashMap declared.
public class Levels{
private final Map<Unit, Object1> rateUnitCost;
public Levels(Map<Unit, Object1> levels) {
this.rateUnitCost = new HashMap<Unit, Object1>(levels);
}
public Object1 getCoverageLevel(Unit unit, Phase aP) {
return rateUnitCost.get(unit);
}
}
I am calling getCoverageLevel() method from other class and i am instantiating the Levels class rateUnitCost property as well from another class.
When seeing in debugger i am finding this value for rateUnitCost and unit object.
rateUnitCost: - Hash Map Values
rateUnitCost HashMap<K,V> (id=1248)
[0] HashMap$Node<K,V> (id=1266)
key >Unit (id=1249)
amount Money (id=1267)
flags ArrayList<E> (id=1268)
procedureId 7156
ParticipationId 104152413
value >Object1 (id=1250)
Now value of unit object is below :-
unit Unit (id=1251)
amount Money (id=1258)
flags ArrayList<E> (id=1259)
procedureId 7156
ParticipationId 104152413
when i match the value of key with this object then its matching .
But at the time of rateUnitCost.get(unit) its returning null even though Object1 is set. Object1 is getting returned from other class using below line: -
return new Object1();
Can anyone please help me to resolve this mystery.?
BasicUnit is a class which is implementing the Unit interface. BasicUnit have equals method as below :-
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
BasicUnit basicUnit = (BasicUnit) o;
if (flags != basicUnit.flags) return false;
if (procedureId != basicUnit.procedureId) return false;
if (ParticipationId != basicUnit.ParticipationId) return false;
if (amount != null ? !amount.equals(basicUnit.amount) : basicUnit.amount != null) return false;
return true;
}
and HashCode :-
public int hashCode() {
int result = procedureId;
result = 31 * result + ParticipationId;
result = 31 * result + (amount != null ? amount.hashCode() : 0);
result = 31 * result + (flags == null ? null : flags.hashCode());
return result;
}
if (flags != basicUnit.flags) return false;
You are checking for whether your Unit objects have exactly the same ArrayList of flags. This is not an equals()-type equality check; this is checking for literally the same ArrayList of flags. Now, you haven't provided the constructor etc, but I highly doubt you are reusing the same ArrayList.
Check for !(flags.equals(basicUnit.flags)) instead. Do note that ArrayList.equals() uses the E.equals() implementation, so be sure that that is implemented.
Also, note that ArrayList.equals() checks for the same list entries in the same order. I don't know if the order of your flags matters but I suspect it probably does not. You might consider making your flag collection a Set if this is the case.
If I have a map and an object as map key, are the default hash and equals methods enough?
class EventInfo{
private String name;
private Map<String, Integer> info
}
Then I want to create a map:
Map<EventInfo, String> map = new HashMap<EventInfo, String>();
Do I have to explicitly implement hashCode() and equals()? Thanks.
Yes, you do. HashMaps work by computing the hash code of the key and using that as a base point. If the hashCode function isn't overriden (by you), then it will use the memory address, and equals will be the same as ==.
If you're in Eclipse, it'll generate them for you. Click Source menu → Generate hashCode() and equals().
If you don't have Eclipse, here's some that should work. (I generated these in Eclipse, as described above.)
#Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((info == null) ? 0 : info.hashCode());
result = prime * result + ((name == null) ? 0 : name.hashCode());
return result;
}
#Override
public boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (obj == null) {
return false;
}
if (!(obj instanceof EventInfo)) {
return false;
}
EventInfo other = (EventInfo) obj;
if (info == null) {
if (other.info != null) {
return false;
}
} else if (!info.equals(other.info)) {
return false;
}
if (name == null) {
if (other.name != null) {
return false;
}
} else if (!name.equals(other.name)) {
return false;
}
return true;
}
Yes, you need them else you won't be able to compare two EventInfo (and your map won't work).
Strictly speaking, no. The default implementations of hashCode() and equals() will produce results that ought to work. See http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode()
My understanding is that the default implementation of hashCode() works by taking the object's address in memory and converting to integer, and the default implementation of equals() returns true only if the two objects are actually the same object.
In practice, you could (and should) probably improve on both of those implementations. For example, both methods should ignore object members that aren't important. In addition, equals() might want to recursively compare references in the object.
In your particular case, you might define equals() as true if the two objects refer to the same string or the two strings are equal and the two maps are the same or they are equal. I think WChargin gave you pretty good implementations.
Depends on what you want to happen. If two different EventInfo instances with the same name and info should result in two different keys, then you don't need to implement equals and hashCode.
So
EventInfo info1 = new EventInfo();
info1.setName("myname");
info1.setInfo(null);
EventInfo info2 = new EventInfo();
info2.setName("myname");
info2.setInfo(null);
info1.equals(info2) would return false and info1.hashCode() would return a different value to info2.hashCode().
Therefore, when you are adding them to your map:
map.put(info1, "test1");
map.put(info2, "test2");
you would have two different entries.
Now, that may be desired behaviour. For example, if your EventInfo is collecting different events, two distinct events with the same data may well want to be desired to be two different entries.
The equals and hashCode contracts is also applicable in a Set.
So for example, if your event info contains mouse clicks, it may well be desired that you would want to end up with:
Set<EventInfo> collectedEvents = new HashSet<EventInfo>();
collectedEvents.add(info1);
collectedEvents.add(info2);
2 collected events instead of just 1...
Hope I'm making sense here...
EDIT:
If however, the above set and map should only contain a single entry, then you could use apache commons EqualsBuilder and HashCodeBuilder to simplify the implementation of equals and hashCode:
#Override
public boolean equals(Object obj) {
if (obj instanceof EventInfo) {
EventInfo other = (EventInfo) obj;
EqualsBuilder builder = new EqualsBuilder();
builder.append(name, other.name);
builder.append(info, other.info);
return builder.isEquals();
}
return false;
}
#Override
public int hashCode() {
HashCodeBuilder builder = new HashCodeBuilder();
builder.append(name);
builder.append(info);
return builder.toHashCode();
}
EDIT2:
It could also be appropriate if two EventInfo instances are considered the same, if they have the same name, for example if the name is some unique identifier (I know it's a bit far fetched with your specific object, but I'm generalising here...)
I get headaches when I have to write nearly 10 lines of code to say 2 Objects are equal, when their type is equal and both's attribute is equal. You can easily see that in this way of writing the number of lines increase drastically with your number of attributes.
public class Id implements Node {
private String name;
public Id(String name) {
this.name = name;
}
public boolean equals(Object o) {
if (o == null)
return false;
if (null == (Id) o)
return false;
Id i = (Id) o;
if ((this.name != null && i.name == null) || (this.name == null && i.name != null))
return false;
return (this.name == null && i.name == null) || this.name.equals(i.name);
}
}
Google's guava library has the Objects class with Objects#equal that handles nullness. It really helps get things smaller. With your example, I would write:
#Override public boolean equals(Object other) {
if (!(other instanceof Id)) {
return false;
}
Id o = (Id) other;
return Objects.equal(this.name, o.name);
}
The documentation is here.
Also note that there is Objects#hashCode and Objects#toStringHelper to help with hashCode and toString as well!
Please also see Effective Java 2nd Edition on how to write equals().
If you use Eclipse, click "Source" -> "generate hashCode() and equals()". There're many options to create equals() automatically.
There are libraries that'll do it for you. For example, commons-lang has EqualsBuilder
Also, these two lines appear to do the same thing:
if (o == null)
return false;
if (null == (Id) o)
return false;
Maybe you meant this:
if (o == null)
return false;
if (this == o)
return true;
Project Lombok also has a equals and hashCode generator using the #EqualsAndHashCode annotation which has the advantage of being in sync with the current class/source code. I'm not sure about the implementation details but definitely worth looking into if you need to cut down the cruft.
A simpler way (other than generating the code) might be.
public boolean equals(Object o) {
return o instanceof Id
&& (name == null ? ((Id)o).name == null : name.equals(((Id)o).name);
}
I read this SO post after I wrote out the title but still decided to go through with the question on bug-proof implementations of equals in Java. This is my normal implementation
#Override
public boolean equals(Object o){
if(o == null) return false;
if(o instanceof CompositePk == false) return false;
if(this == o) return true;
CompositePk that = (CompositePk)o;
return new EqualsBuilder().append(this.id, that.id)
.append(this.bucketId, that.bucketId)
.isEquals();
}
using Apache's EqualsBuilder to do the mundane stuff. Even easier than this is my Netbean's automatically generated equals(o) implementation
#Override
public boolean equals(Object obj){
if (obj == null) {
return false;
}
if (getClass() != obj.getClass()) {
return false;
}
final TemplatesWrapper other = (TemplatesWrapper) obj;
if (this.timeAdded != other.timeAdded && (this.timeAdded == null || !this.timeAdded.equals(other.timeAdded))) {
return false;
}
return true;
}
I take these from 2 diff projects but they both try to accomplish the same thing but using diff approaches. Which style would you rather or are there any flaws you spot?
First of all, there's no need to test for null, then test for instanceof, since foo instanceof Bar evaluates to false when foo is null.
It's weird to compare the result of the instanceof operator to false, since instanceof is a boolean operation.
Comparing classes with getClass() is at best controversial. Joshua Bloch, who wrote much of the Java collections framework and a lot of other important stuff besides, says
This technique ("getClass-based equals
methods") does satisfy the equals
contract, but at great cost. The
disadvantage of the getClass approach
is that it violates the "Liskov
Substitution Principle," which states
(roughly speaking) that a method
expecting a superclass instance must
behave properly when presented with a
subclass instance. If a subclass adds
a few new methods, or trivially
modifies behavior (e.g., by emitting a
trace upon each method invocation),
programmers will be surprised when
subclass and superclass instances
don't interact properly. Objects that
"ought to be equal" won't be, causing
programs to fail or behave
erratically. The problem is
exacerbated by the fact that Java's
collections are based on the equals
method.
You should use instanceof instead of comparing via getClass() unless you have some specific technical reason not to.
After establishing that the other object is comparable to this, you then compare primitives with == and objects with equals. It's more complicated if any of your member objects can be null; you must then write verbose clauses to compare possibly null things to each other (or write a bothNullOrEqual(Object a, Object b) method).
The EqualsBuilder approach looks bogus to me, but that's just a "smell", which I won't argue against technically. In general, I don't like extra method calls in a method that may be called frequently.
The Apache one is bogus because it tests for null and uses the getClass() comparison.
Here's mine:
#Override
public boolean equals(final Object o) {
if (!(o instanceof MyClass))
return false;
final MyClass om = (MyClass)o;
// compare om's fields to mine
}
I would do it this way:
public boolean equals(Object ob) {
if (ob == null) return false;
if (ob == this) return true;
if (!(ob instanceof MyClass)) return false; // OR
if (ob.getClass() != getClass()) return false;
// check relevant members
}
The two lines in the middle are different. One allows for subclasses to be equal (the first one), the other doesn't. Use whichever one is appropriate.
To give you an example, Java's AbstractList class will probably use the second form, because the exact implementation of List is irrelevant. what matters is if the members are equal and in the same position.
Conversely, a Person class should use the first form (instanceof) because if there is a Student subclass and you call Person.equals(Student) it may return true without checking the extra fields in Student whereas Student.equals(Person) will probably return false. If equals() isn't commutative, you're asking for trouble.
I tend to use equals() methods generated by my IDE (IntelliJ IDEA) rather than creating an unnecessary dependency to some Apache library for little gain.
Apache's is better than yours or cletus'.
As far as my vague memory suggests, there is a problem with using instanceof in equals; I can't quite put my finger on why yet, perhaps someone will elaborate. I could be wrong.
-- Edit:
As Chris and Steve helpfully explain below, I was thinking of the "symmetric property" of equals implementation. On this basis, I can back up my claim of prefering the Apache implementation :)
Honestly, the less code you have to write, the better off you are (in most cases).
The code that's generated has been debugged and used by many MANY people. You might as well use what's generated (and if you need to enhance the performance, do so).
The advantage of using the generated code: any time your instance fields changes (and this generated code wasn't modified), you can simply regenerate code.
Sometimes, it's easier to think about maintainability. Rule of thumb: the less code you write yourself, the less you have to debug. If the generated code doesn't take a huge performance hit, generate it!
Explanation: When overriding the equals method, the hashCode() method must be overrided too. So, considering a class with 3 properties as show below and considering that all the properties are significant to equality, the equals() implementation must test all these fields. The order of conditionals isn't important, but all the fields must to be tested for equality to consider the equality between objects at all.
public class SampleClass {
private Long id;
private String description;
private Date creation;
#Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((creation == null) ? 0 : creation.hashCode());
result = prime * result + ((description == null) ? 0 : description.hashCode());
result = prime * result + ((id == null) ? 0 : id.hashCode());
return result;
}
#Override
public boolean equals(Object obj) {
boolean isEquals = true;
if (this == obj) { isEquals = true; }
else if (obj == null) { isEquals = false; }
else if (getClass() != obj.getClass()) { isEquals = false; }
else {
SampleClass other = (SampleClass) obj;
if (creation == null) {
if (other.creation != null) isEquals = false;
} else if (!creation.equals(other.creation)) {
isEquals = false;
} else if (description == null) {
if (other.description != null) isEquals = false;
} else if (!description.equals(other.description)) {
isEquals = false;
} else if (id == null) {
if (other.id != null) isEquals = false;
} else if (!id.equals(other.id)) {
isEquals = false;
}
}
return isEquals;
}