Basically, it’s a broken interface. Ken Arnold and Bill Venners discussed it in Java Design Issues. Arnold: If I were to be God at this point, and many people are probably glad I am not, I would say deprecate Cloneable and have a Copyable, because Cloneable has problems. Besides the fact that it’s misspelled, Cloneable … Read more
A related issue that I have come across recently (and which led me to this page, before I figured out what was going on) is that the Eclipse environment can report “Incompatible conditional operand types” in an ‘instanceof’ expression erroneously due to a missing ‘import’ statement for the type on the right of the ‘instanceof’. … Read more
You shouldn’t. Microsoft recommends against implementing ICloneable because there’s no clear indication from the interface whether your Clone method performs a “deep” or “shallow” clone. See this blog post from Brad Abrams back in 2003(!) for more information.
There are a few problems. The first is that there’s nothing to require that an Animal also implements Clone. You could fix this by changing the trait definition: trait Animal: Clone { /* … */ } This would cause Animal to no longer be object safe, meaning that Box<dyn Animal> will become invalid, so that’s … Read more
The first thing you should know about Cloneable is – don’t use it. It is very hard to implement cloning with Cloneable right, and the effort is not worth it. Instead of that use some other options, like apache-commons SerializationUtils (deep-clone) or BeanUtils (shallow-clone), or simply use a copy-constructor. See here for the views of … Read more
Do you absolutely have to use clone? Most people agree that Java’s clone is broken. Josh Bloch on Design – Copy Constructor versus Cloning If you’ve read the item about cloning in my book, especially if you read between the lines, you will know that I think clone is deeply broken. […] It’s a shame … Read more