StringBuffer sb = new StringBuffer("Manvir"); StringBuffer sb1 = new StringBuffer("Manvir"); System.out.println( (sb.toString()).equals( (sb1.toString() )) //True System.out.println(sb.equals(sb1));//False. In the preceding code, the comments indicate the output. Can someone please enlighten me as why SUn chose to over-ride the String' equals method and not StringBuffer's?
Can someone please enlighten me as why SUn chose to over-ride ...
1. Maybe, it has something to do with the imutability/ mutability of String/ StringBuffer. 2. Why SUN choose to override String's equals and not StringBuffer's? Why not Both? Well, examine the available constructors for these classes: String() String(byte bytes) String(byte bytes, int offset, int length) String(byte bytes, int offset, int length, String charsetName) String(byte bytes, String charsetName) String(char value) String(char value, int offset, int count) String(String original) String(StringBuffer buffer) StringBuffer() StringBuffer(int length) StringBuffer(String str) Which one you would choose?
hi there, My Humble opinion is that java.lang.StringBuffer class don't have a equals() method in it. Only in String, Wrappers and Object there are equals(). Here in you are invoking the equals() method in java.lang.Object which is looking for the reference, which is different. Hence returning false. thanks Vivek Nidhi
Welcome to the Ranch Manvir and Vivek. Maybe the reason is that they did not care about the fact that the class has no logical equality test. The StringBuffer is normally used to manipulate a string object. The string class represents the actual data. When a stringbuffer will be equal to another? are they equal if their string objects and their capacities are equal? This point seems not to be very useful for the programmer.
Hi, As per the Java Language Specification, the equals method returns true in two cases. Case 1: If both the references are pointing to the same object Case 2: If the hashCode value of the objects are same. Well, now let us see what is the issue here. Since the StringBuffer objects are mutable, they are not created as like String Objects. So each object has different hashCode value. that is the reason it returns false. Please refer the below example. StringBuffer strb1 = new StringBuffer("ArulkumarG"); StringBuffer strb2 = new StringBuffer("ArulkumarG"); System.out.println(strb1==strb2); //false System.out.println(strb1.equals(strb2)); //false System.out.println(strb1.toString().equals(strb2.toString())); //true //strb1 = strb2; //System.out.println(strb1.equals(strb2)); //true System.out.println(strb1.hashCode()+" "+strb2.hashCode()); //7474923 3242435
------------------------------------------------ Can someone please enlighten me as why SUn chose to over-ride the String' equals method and not StringBuffer's? ------------------------------------------------ So, to answer to your question, I think it is not related to overridding. It's all about how equals method works. Please correct me if I am wrong. Thanks, ~AK -- No power in the world can withhold from anyone anything he really deserves.
Anbudan & Mahalo,<br />Arul<br /> <br />-Not a sun certified Java professional :-)
java.lang.String does override the "equals()" method, while java.lang.StringBuffer does not. As has been mentioned by prior posts, String instances are immutable, so two Strings that are holding onto the same set of characters should be considered as equal. [Note that is different from "=="]. If you look at the JavaDoc for the ".equals()" method in Object it gives a good description of when two objects should be considered equal. One of the conditions stated is "that equal objects must have equal hash codes". Which means they can be used interchangeably in any collection that uses the HashCode as a key. If SUN had chosen to implement ".equals()" for a StringBuffer based solely on the current contents of the underlying String value, then the following would cause problems.
The first key/value pair would go in fine, but the second one would over-ride the first since the Hashtable class would interpret the two keys (sb1 and sb2) to be the same object. So SUN made the correct decision in this case in my opinion. [ October 20, 2003: Message edited by: Wayne L Johnson ]