Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Following on from this question - how do you explain to someone that this is just crazy!:

boolean someMethod(Map<String, Object> context) {
    Object object = context.get("someProperty") 
    Object another = context.get("anotherProperty") 

    return object.toString().equals(another.toString());
}

Apparently the reason for why Object.equals(...) is not used is that "what's contained in the Map is not concretely known, but is definitely known to be one of the primitive wrappers i.e. String, Double, Boolean, etc... and that Boolean.TRUE is required to be equal(...) to the String "TRUE"".

share|improve this question

3 Answers 3

up vote 7 down vote accepted

It's wrong because there is no contract (not even an informal expectation!) for toString() that guarantees that any subclass of Object will define it in a way compatible with an equivalence relationship (read the javadoc for Object.equals() to see what I mean).

It may work for a class where you know that toString() is compatible with equals, but this is not the case for the values in Map<String, Object>!

For an obvious example where almost certainly the method doesn't do what you would expect, imagine a subclass of Object that does not override toString(). In that case, the String representation of your instance is a function of the class name and the object's hashCode. Almost certainly not what you want to use to test for equality.

share|improve this answer
    
Any comments on this part of the question? >> "what's contained in the Map is not concretely known, but is definitely known to be one of the intrinsic wrappers i.e. String, Double, Boolean, etc... and that Boolean.TRUE is required to be equal(...) to the String "TRUE"" –  auser May 17 '12 at 19:24
    
When in Rome, do as the Romans do: Java is a strong, static-typed language. Boolean.TRUE may be equal (IDK) to String "TRUE", but this is duck typing at hand and considered bad practice in Java. Also, what's guaranteed is that what's contained in the map is Object. Assuming otherwise is a bad idea, again because of the Java paradigms. Reminds me of "You can write Fortran in any language". –  K.Steff May 17 '12 at 20:37
    
@loudsight What do you mean, "intrinsic wrappers"? In any case, String, Boolean and Double all have well-defined equal methods, which you might as well use (though I'm not sure it's numerically safe to use Double.equals(), but that's another issue). In the general case, toString() is not meant for equality tests, so don't use it for that. –  Andres F. May 17 '12 at 22:32
    
Actually, I meant to say primitive rather than instrinsic. en.wikipedia.org/wiki/Primitive_wrapper_class –  auser May 18 '12 at 17:13
    
@loudsight Java primitive wrappers all have well-defined equals methods. You absolutely do NOT need to convert to String. –  Andres F. May 18 '12 at 17:21

It's just crazy, because it can go wrong, because string representations are not canonical:

Double zeroDouble = new Double(0);
Integer zeroInteger = new Integer(0);
zeroDouble.doubleValue() == zeroInteger.doubleValue(); // true
zeroDouble.toString().equals(zeroInteger.toString());  // false ("0.0" vs "0")

File file1 = new File("file.txt");
File file2 = new File("FILE.TXT");
file1.equals(file2);            // true in windows, false in unix
file1.toString().equals(file2); // false ("file.txt" vs. "FILE.TXT")
share|improve this answer
1  
Actually, zeroDouble.equals(zeroInteger) is false. –  waxwing May 17 '12 at 10:36
    
Oops, I stand corrected. Numerical comparisons are almost never trivial :) –  Joonas Pulakka May 17 '12 at 12:41

If you are keenly interested to know about Object Equality then use can use the method of class Object.

int hashCode() gives the integer value called hashCode which pertain to an object.

definitely the hashcode differs object to object.
     it's a easiest way to identify object equality.
share|improve this answer
    
There is no guarantee that equal objects have the same hashcode, and similarly there is no guarantee that non-equal objects have differing hashcodes. –  RonU May 17 '12 at 16:28
2  
This is a serious misunderstanding of what hashCode does. –  Andres F. May 17 '12 at 21:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.