3

It is a bad idea to make an immutable object Cloneable. This is why String is not Cloneable. Immutable BigInteger and BigDecimal are also not Cloneable.

But mutable StringBuilder and StringBuffer cannot be cloned!

What is the reason behind that desicion?

Yes, I can use "copy constructor" new StringBuilder(CharSequence seq) but what is the design principle/reasoning to supply a copy constructor and prohibit cloning?

Code Complete
  • 3,146
  • 1
  • 15
  • 38
  • 1
    Whilst the question isn't a direct dupe, the quotes in [this answer](https://stackoverflow.com/a/34123774/3788176) is relevant: TL;DR: the design of `Cloneable` is pretty flawed. – Andy Turner Jan 03 '19 at 09:31
  • @AndyTurner I remembered I answered something like this some time ago :) – user1803551 Jan 03 '19 at 09:42

1 Answers1

9

Because Cloneable was mistake from beginning.

  • It have difficult to use interface (you have to cast result back)
  • Unclean semantic (will it be deep clone or shallow clone?)
  • It is difficult to customize

All of these made this interface unpopular.

So answer is: no one wants it.

EDIT

If you want to know why it will be bad idea to implement Cloneable in StringBuilder: Cloneable have shallow-copy semantic and this make difficult to maintain invariants (this is generic problem with shallow copy of mutable objects). For example there is optimizations in toString which will be broken in case we clone it.

talex
  • 17,973
  • 3
  • 29
  • 66