Campbell Ritchie wrote:For the same reason you don't need a copy constructor for the String class.
The String class does have a copy constructor right?
Yes it does. There is the String(String) constructor.
Frankly I still don't get the reason why the String class should not have been cloneable?
Because you will never need to clone strings. They are immutable, so their contents can never change. If String would have been Cloneable, you could clone an immutable String, and you would get another object that will forever be exactly equal to its source. Cloneable only makes sense for objects that can change, and you want to "fork" the object at a specific state.
Now logically, the copy constructor wouldn't be necessary either, but I think they let it exist for reflection issues. It surely isn't needed.
Rob beat me to it with his answer. Agree that it is because of immutability that there is no need for String to implement Cloneable. I suspect the real reason for the String(String) copy constructor is because in the early days of Java somebody thought it was a good idea, and it is now impossible to remove so as to maintain backward compatibility. When you create "real" classes, you want to keep their public interface as small as possible.
But String is a "library" class; they would give it a large public interface, including things like the copy constructor, even though 99.9% of users can see no point in using it, just in case somebody wants it.
And while we're on about copy constructors, did you work out why you weren't getting == to return true on Strings on your other thread?