views:

1017

answers:

5

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.

+6  A: 

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

Jon
Is the HashCodeBuilder source code online? ... .I'll look at it.
OscarRyz
it says: string.hashCode * 37 + intValue!! enough for me !! Thank you
OscarRyz
+2  A: 

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
Doh!.. sometimes I miss this kinds of solutions !! Yeah I don't want to add another library. Thanks for the advice
OscarRyz
@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
@perkins: another thing, if you are really concerned about speed, then this approach is significantly slower than calculating and combining component hashcodes.
Stephen C
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
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
+2  A: 

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
A: 

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
+1  A: 

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