Regarding HashSet Impl - i have other thoughts - maybe for another time.

I assume storing the hashcode rather than calculating it at request time was based on performance. Not sure.

I also looked at the HasSet implementation, and they store the hashcode of the object as you add it to the collection in a map of hashcodes -> Objects.

The only way to gurantee that your object is found is to provide a immutable hashcode to your objects upon creation. Jason gives more info on that.

Also that original hashcode() is poop. Looks like some autogen code that will f-up in a HashSet. I tired that out in 1.4 and created a set of objects. I then looped through the list, modifiying one field and then did a check if the set contained the modified object. In all cases the modified object was not found.

public static boolean produceEquals(final Object... itemsToCompare) {
       boolean value = true;
        if (isNonEmpty(itemsToCompare)) {
            if (0 == itemsToCompare.length % 2) {
                for (...) {
                    final Object itemA = itemsToCompare[index];
                    final Object itemB = itemsToCompare[index + 1];
                    if (null == itemA ? null != itemB : !itemA.equals(itemB)) {
		value =  false;
		break:
	        }
                }
            } else {
                throw new IllegalArgumentException("produceEquals() expects an itemsToCompare array of even length.");
            }
        }
        return value;
    }

I like the code to only have one exit in it because it makes the code easier to test and debug. When you have multiple exit points you are adding complexity and can find youself getting a result you may not have expected. Above is how I would refactor your produceEquals method.