[SalesForce] Apex Class as Map Keys and Sets

Summer'13 Update:

According to the Summer'13 release notes String now provides a hashCode method! Here is the sample code included in the release notes here.

public class MyCustomClass {
    String x,y;
    public MyCustomClass(String a, String b) {
        x=a;
        y=b;
    }
    public Integer hashCode() {
        return (31 * x.hashCode()) ^ y.hashCode();
    }
    public Boolean equals(Object obj) {
        if (obj instanceof MyCustomClass) {
            MyCustomClass p = (MyCustomClass)obj;
            return (x.equals(p.x)) && (y.equals(p.y));
        }
        return false;
    }
}

Original Answer:

Converted comment to an answer after a bit of digging around.

Initial thoughts...

Yes most interesting, I did wonder why the only sample was using numbers. It also looks like there is a bug in this area at large anyway, http://success.salesforce.com/issues_view?id=a1p30000000SV0XAAW.

Current conclusion...

I had a look at the Java implementations and a few other general postings on the net. My conclusion is that given the statement governor, at least for strings, it is going to quite expensive to implement a String.hashCode. We really need a native implementation of this to avoid hitting the statement governor very quickly with large maps.

Some interesting links

• http://java-bytes.blogspot.co.uk/2009/10/hashcode-of-string-in-java.html
• http://www.tgerm.com/2011/07/xcollections-using-udt-with-map-set-in.html
• http://en.wikipedia.org/wiki/Java_hashCode()
• http://www.javapractices.com/topic/TopicAction.do?Id=28
• https://stackoverflow.com/questions/113511/hash-code-implementation

It took 2 months, but this is the "final" answer we got from Support on this topic. Note that the investigation by Tier 3 resulted in this Known Issue being filed which was ultimately the cause for our documented behavior (i.e. by setting a log filter override on a class with a hashCode()/equals() implementation, it effectively disabled hashCode() from being called)

Here's the Known Issue:

https://success.salesforce.com/issues_view?id=a1p30000000eMoeAAE

And here's the explanation on why FINEST vs. DEBUG makes a difference

Here is a recap of the current issue:

with log level = debug

DEBUG|Final HashableClass.hashCodeCount=10 DEBUG|Final HashableClass.equalsCount=0

with log level = finest

DEBUG|Final HashableClass.hashCodeCount=0 DEBUG|Final HashableClass.equalsCount=45

In this testcase, adding 10 HashableClass objects to a Set causes 10 hasCode() method calls because there are not any hash conflicts.

However, if the log level is set to FINEST, a Set Interpreter Instance is converted to a Set Wrapper Instance in order to log an event of a static field's assignment at line#6 (hashables = new Set(); ) in the HashableClassDemo class.

When an object is added to a Set Wrapper Instance, we traverse the entire list in it and compare objects for equality. That's why the number of the equals() calls becomes 45 (1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9).

========================

The difference comes from underlying Map representations.

Internally, we have 2 representations for Map.

1) One keeps the objects in a Map in the interpreter (apex) native representation.And in this case, if the put() method is called to it, uniqueness of keys are determined by using both of hashCode() and equals(). (A value returned by the hashCode() method is used to determine a bucket, and the equals() method is used to identify objects in the same bucket.)

2) Once a Map is marshaled, the other representation is used.In this representation, in the put() method call, we traverse all objects in a Map and linearly check uniqueness of keys using the equals() method if a user defined key is used.That's why you don't see the hashCode() method calls but see the equals() method calls in your testcase. (In your org, the Map object is marshaled when trying to generate a debug message for local variable assignments.)

However, the latter representation does not violate the Map contract. Any method call defined in the Map class works as per doc.

This is the repro case that goes along with the investigation above:

public with sharing class HashableClass {
    public static Integer hashCodeCount = 0;
    public static Integer equalsCount = 0;

    private Integer simpleMember;

    public HashableClass(Integer val) {
        this.simpleMember = val;
    }

    public Integer hashCode(){
        hashCodeCount++;
        System.debug('entering HashableClass.hashCode hashCodeCount=' + hashCodeCount);
        return simpleMember;
    }

    public Boolean equals(Object other){
        equalsCount++;
        System.debug('entering HashableClass.equals equalsCount=' + equalsCount);
        if(other == null){
            return false;
        }
        if(!(other instanceof HashableClass)){
            return false;
        }
        return ((HashableClass)other).simpleMember == this.simpleMember;
    }
}

public with sharing class HashableClassDemo {
    private static Set<HashableClass> hashables;
    private static Set<HashableClass.InnerHashableClass> innerHashables;

    public static void demo() {
        hashables = new Set<HashableClass>();

        for(Integer i=0; i<10; i++){
            HashableClass h = new HashableClass(i);
            hashables.add(h);
        }

        System.debug('Final HashableClass.hashCodeCount=' + HashableClass.hashCodeCount);
        System.debug('Final HashableClass.equalsCount=' + HashableClass.equalsCount);
    }
}