This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I have this guess, that it is because sun wants to discourage usage of StringBuffer as an entry to HashThings, because hashing function of big strings will cost alot of processor cycles; It will contain alot of multiplications and exponentials.
Is that correct ? , and Is there another reasons ?
My guess is because StringBuffer is one of the very oldest classes, and they made lots of little mistakes like this back then. It's true that StringBuffers wouldn't good hash keys, not for the reasons you gave, but simply because their hashCode() would necessarily change when the contents change, and objects whose hashCodes change a lot make lousy keys. But I don't think that much thought went into this design; I think somebody just forgot.
Originally posted by Ernest Friedman-Hill: ... and objects whose hashCodes change a lot make lousy keys. But I don't think that much thought went into this design; I think somebody just forgot.
Yes, But I would say that hashCodes that depend on data which is "changeble" through the class API , will make corrupted hashThings, ie you will not find your stuff, if you change the object content after it has added to the HashThing.
Originally posted by Jim Yingst: Yes - had they thought about it more, it would've been more appropriate to just throw an UnsupportedOperationException the moment anyone called either hashCode() or equals() on a StringBuffer.
and that is better than having very nasty bugs, due to you, programmer will think that he is using appropriate equals and hashCode, while he is using the Object version.
or may be they should use mark interface sounds like Hashable, just like clone method !!