Imagine that you have a class A which implements
Cloneable with a custom function. Now you have class B inherit from class A without overriding the clone method. If you now try to clone object B you will not get a clone as only the members defined in A get cloned. The documentation states that:
The general intent is that, for any object x, the expression:
x.clone() != x
will be true, and that the expression:
x.clone().getClass() == x.getClass()
will be true, but these are not absolute requirements. While it is typically the case that:
will be true, this is not an absolute requirement.
So the above problem would not violate this in the way I described. It would however return an object of the wrong type thereby not following rule number 2.
The way around this problem is to have class B also implement the
Cloneable interface and override the
clone method. (Also the documentation states, that clone should always call its super implementation)
As you and @vbezhenar said, not very well designed. Object copying/cloning is a complex subject. I have not yet seen any good implementation of it, which generalizes well to any type. That’s why
Cloneable is so unintuitive IMO. Kotlin data classes can have a
copy as they are much more heavily restricted and therefore copying is “simple”.