Java HashMap, hashCode() equals() - how to be consistent with multiple keys?

Question

I have an ID class. It refers to identification for a unique person. There are two forms of ID. Username and user number. If either username matches or user number matches, the ID's refer to the same person. I want to use the ID class as a key in a hashmap for looking up persons. I overrode the equals method to make it clear that if two ID's are equal, that means they refer to the same person. I am under the presumption that I need to override the hashCode() method because I want a hashmap of < key: ID, value: Person >. But I don't know how. How do I make the ID class an acceptable key for my HashMap?

public final class ID {

    // These are all unique values. No 2 people can have the same username or id value.
    final String username_;
    final long idNumber_;

    public ID(String username, Byte[] MACaddress, long idNumber) {
    username_ = username;
    idNumber_ = idNumber;
    }

    /**
     * Checks to see if the values match. 
     * If either username or idNumber matches, then both ID's refer to the same person.
     */
    public boolean equals(Object o) {
    if (!(o instanceof ID)) {
        return false;
    }
    ID other = (ID) o;
    if (this.username_ != null && other.username_ != null) {
        if (this.username_.equals(other.username_)) {
            return true;
        }
    }
    if (this.idNumber_ > 0 && other.idNumber_ > 0) {
        if(this.idNumber_ == other.idNumber_) {
            return true;
        }
    }
    return false;
    }
}

Followup: What if I wanted to add a third field for unique social security number? How would that change my person lookup hashmap and the ID class?

Note that the Wikipedia page for hashCode says:

The general contract for overridden implementations of this method is that they behave in a way consistent with the same object's equals() method: that a given object must consistently report the same hash value (unless it is changed so that the new version is no longer considered "equal" to the old), and that two objects which equals() says are equal must report the same hash value.

Update

Best solution thus far: Make a separate HashMap for each immutable unique identifier and then wrap all the HashMaps in a wrapper object.

Are you saying, you'll put a key in the map which is the ID number and then look it up by giving a ID which is just the name? Or is it like if you put a number id, you'll always have a number id and vice versa? — Praba, Jun 08 '15 at 06:14
@Jayan - I doubt that this is a duplicate. the OP is not asking about the contract details/pitfalls. Just that how to design it for his requirement. — Praba, Jun 08 '15 at 06:16
@prabugp >> Are you saying, you'll put a key in the map which is the ID number and then look it up by giving a ID which is just the name? -- No. If you looked at how the equals method was implemented, either the ID would have to match or the name would have to match or both for it to be a matching key to obtain that person value. It's like I make an ID that has both my social security number and my name and I put it in the HashMap with a value that references me. Then someone makes a new ID that is just my name and they put it in the hashmap and it returns me. Same if it was just my number. — , Jun 08 '15 at 06:21
Or maybe like I change my name but my number is still the same. Then people who have my old name and number can still look me up in the hashmap because even though my name is not a match, my number is a match. Does that make sense? — , Jun 08 '15 at 06:22

score 1 · Accepted Answer · answered Jun 08 '15 at 06:22

1

I think your question really goes a long way beyond plain implementation of hashCode - it's really about the design of when two IDs should be considered equal.

If you have multiple fields all of which are unique, you're actually in a tricky situation. Ignoring the MAC address part, there's nothing in the ID code itself to stop:

ID a = new ID("a", 0);
ID b = new ID("b", 0);
ID c = new ID("a", 1);

Now by your rules, those three IDs shouldn't all be able to co-exist - because they're all equal in one way or another. (a and b share the same name, and a and c share the same number.)

Additionally, it looks like the number and name are both effectively optional - that's likely to end up being painful, in my experience.

It may still make sense to keep your class as it is, but the rules around "No two entities can have the same name" and "No two entities can have the same number" aren't really the same as "no two entities can have the same ID", so you'd have to enforce that separately.

It's entirely possible that you'll want to keep a HashMap<String, Entity> for "entities by name" and a HashMap<Integer, Entity> for "entities by number". I would then implement equals and hashCode in ID to check for complete equality - so that after looking up an ID by just one part of the ID, you can check that the ID you've found is actually the right one.

Alternatively, change your identity scheme to only have a single part, so that you never need to worry about this. Even if you have a "secondary identifier" of some kind, it's worth deciding on one of them being your primary identifier which you normally use to look entities up, store them etc - and then you'd just have a secondary mapping (whether that's in memory or in a database etc) between the primary and secondary identifiers. If all your "real" identifiers are optional, you may even want to have a surrogate identifier which is guaranteed to exist, and then all the mappings between that and the secondary identifiers can be optional. (They may even be mutable - you may be able to "discover" and record a social security number later against an existing entity, for example.)

answered Jun 08 '15 at 06:22

Jon Skeet

1,421,763
867
9,128
9,194

>> Additionally, it looks like the number and name are both effectively optional - that's likely to end up being painful, in my experience. -- Yes, that was what I wanted. If someone had either my name or my number, they should be able to look me up. – Jun 08 '15 at 06:29
@Sacha: Then they haven't got an ID, they've got a name or a number. – Jon Skeet Jun 08 '15 at 06:31
>> If you have multiple fields all of which are unique, you're actually in a tricky situation. -- I could add a non-unique field if I wanted. Something like "age" that is non-unique for a given person, if that would make things easier. – Jun 08 '15 at 06:31
>> Then they haven't got an ID, they've got a name or a number. -- Sorry. You could call it a lookup key if you'd like. – Jun 08 '15 at 06:32
If it were really bad, I could just replace the HashMap with another data-structure. Something that would quickly allow me to look up a person by either name or id and that would allow me to provide both name and id and still get a match even if one of those fields changed. – Jun 08 '15 at 06:34
The point here is when you look up a key (which is a partial match), HashMap is not the structure. Unless you iterate through all the keys and do some sort of key.contains() (or `where key like ''` in a database query. You're not doing a look up. you're filtering, right? – Praba Jun 08 '15 at 06:37
But I think your idea of using separate HashMaps that point to the same Person object is the best idea so far. When I want to look up a person, I could just have a function that takes in an ID (sorry, lookup key), extracts the name and number from a lookup key, and performs a separate lookup in both HashMaps. – Jun 08 '15 at 06:41
The thing is, I want O(1) time and I can't get that from iterating through an ArrayList or a LinkedList. The number of people objects in the list is potentially very large so O(n) traversal would be bad. – Jun 08 '15 at 06:43
Anyway, the trick with using two hashmaps would be updating. The way I have it set up, a person can hold up to two names (a previous and a current) and up to two numbers (a previous and a current). If you change your name and I still have your old name, I can use your old name to find you, and then when I find you, I will update your name in my friends list to your new name. – Jun 08 '15 at 06:48
But yeah, given that I can just make the old name, the current name, the old number, and the current number all point to the same person, the double hashmap method should work. I don't think that I need a full blown relational database for this because it is just a contacts list for networking operations (send message, initiate upload, etc). – Jun 08 '15 at 06:50
@SachaTRed, as suggested by Jon, you could create two hashMap. I would say you could create a wrapper class that holds those two hashmap and then expose some methods like getPersonByName, getPersonByNumber, putPersonById and getPersonById which internally call getPersonByName and getPersonByNumber. – Naman Gala Jun 08 '15 at 06:55

Java HashMap, hashCode() equals() - how to be consistent with multiple keys?

1 Answers1