12

I remember eclipse and idea have this template to automatically create an object's hashCode based on its attributes.

One of the strategies if a number and a string is used is something like this.

  return stringValue.hashCode() + intValue * 32;

Ooor something like that.

I don't have nor eclipse or idea at hand and I would like to create such function.

EDIT

Based on the answers I create this mini-class

    class StringInt {
        private final String s;
        private final int i;

        static StringInt valueOf( String string , int value ) {
            return new StringInt( string, value );
        }
        private StringInt( String string, int value ) {
            this.s = string;
            this.i = value;
        }
        public boolean equals( Object o ) {
            if( o != null && o instanceof StringInt ){
                StringInt other = ( StringInt ) o;
                return this.s == other.s && this.i == other.i;
            }

            return false;
        }
        public int hashCode() {
            return s != null ? s.hashCode() * 37 + i : i;
        }
    }

This class is to be used as key for a large memory map ( > 10k elements ) I don't want to iterate them each time to find if the String and the int are the same.

Thank you.

ps.. mmh probably it should be names StringIntKey.

OscarRyz
  • 196,001
  • 113
  • 385
  • 569
  • Oscar, I think that's a good class. The hashCode method is clear, reliable, and performant. What about preventing string from being null? In your constructor, throw a NPE if it is null. Then you could remove those null guards in equals and hashCode. Finally, keep a copy of "Effective Java" handy for questions like these. The hashCode methods created by Eclipse and IDEA are based on that book. – Steve McLeod Jul 31 '09 at 07:23
  • In your equals method should be comparing the string use equals instead of ==. – Steve Kuo Jul 31 '09 at 15:09

6 Answers6

8

Use the Apache Commons HashcodeBuilder:

public int hashCode() {
    new HashCodeBuilder(17, 37).
           append(myString).
           append(myInt);
}

Link here: http://commons.apache.org/lang/api-2.3/org/apache/commons/lang/builder/HashCodeBuilder.html

And here:

http://www.koders.com/java/fidCE4E86F23847AE93909CE105394B668DDB0F491A.aspx

OscarRyz
  • 196,001
  • 113
  • 385
  • 569
Jonathan Holloway
  • 62,090
  • 32
  • 125
  • 150
3

Eclipse always does roughly the same hashing function, here's an example for a class with an in and String as fields

    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + this.interger;
        result = prime * result + ((this.string == null) ? 0 : this.string.hashCode());
        return result;
    }

They always pick 31 as the prime, and then multiple by build in hash functions or the value if its a primitive. Something like this wouldn't be hard to create as a method.

     public int hashCode(Object ... things) {
         final int prime = 31;
         int result = 1;
         for(Object thing : things) {
             result = prime * result + thing.hashCode();
         }
         return result;
     }
Patrick Auld
  • 1,407
  • 3
  • 15
  • 25
3

You can also use Objects class from java.util.Objects package to quickly get hash code.

@Override
public int hashCode() {
    return Objects.hash(this.string, this.integerValue, this.otherDataTypes);
}
Puneeth Reddy V
  • 1,538
  • 13
  • 28
2

Or, if you don't want to add another library, do something like the following:

public int hashCode() {
    StringBuilder builder = new StringBuilder();
    builder.append(myString);
    builder.append(myInteger);
    return builder.toString().hashCode();
}
aperkins
  • 12,914
  • 4
  • 29
  • 34
  • Doh!.. sometimes I miss this kinds of solutions !! Yeah I don't want to add another library. Thanks for the advice – OscarRyz Jul 30 '09 at 22:06
  • 2
    @aperkins: it is simpler to just write "return (myString + myInteger).hashCode()". The Java compiler will compile this to the equivalent sequence of StringBuilder.append calls. – Stephen C Jul 31 '09 at 04:11
  • 2
    @perkins: another thing, if you are really concerned about speed, then this approach is significantly slower than calculating and combining component hashcodes. – Stephen C Jul 31 '09 at 04:15
  • 2
    hashCode should be fast, it would be far better to take the string's hashCode and do a simple integer math operation with the integer. – Steve Kuo Jul 31 '09 at 15:03
  • Speed concerns are probably true, however I have never noticed a significant slowdown using this method in the code we write. Usually our performance concerns are more related to wire-transfer or algorithm changes. – aperkins Jul 31 '09 at 15:14
1

A hashcode method is something that potentially be called many times, and is therefore worth optimizing. If the calculation is complicated, consider memoizing the hash value. Also, avoid doing things that entail more calculation than is necessary. (For example, the StringBuilder solution spends most of its time creating the temporary String.)

The other thing I want to point out is that the quality of the hash is important. You want to avoid any hashcode algorithm that maps lots of common keys. If that happens, hash table lookup may no longer be O(1). (In the worst case it will be O(N) ... i.e. equivalent to a linear search!). Here's an example of a bad hash function:

int hashcode() {
    int hash = 1;
    for (int val : this.values) {
        hash = hash * value;
    }
    return hash;
}

Consider what happens if an element of this.values is zero ...

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

Further to your most recent edit, if retrieval speed is more important than storage concerns you could pre-compute and store the hash code when constructing your StringInt class. This is safe as you've marked the String and int fields as final, and also given that String is immutable.

Also, you could optimise your equals method by checking that the object being compared == this before doing a full comparison. I would also recommend doing the cheaper int-based comparison first before comparing the string fields.

Another final suggestion: You could change your valueOf(String, int) method to either construct a StringInt or return a previously created instance if one already exists with the same String and int values. This makes construction more expensive but comparisons very cheap as you can compare StringInts using "==" in the knowledge that no two StringInts will ever be created with the same String and int value.

Adamski
  • 54,009
  • 15
  • 113
  • 152