array clone() vs Arrays.copyOf()

Ulf Zibis Ulf.Zibis at
Wed Apr 27 09:41:22 UTC 2011

Am 27.04.2011 11:19, schrieb David Holmes:
> Ulf Zibis said the following on 04/27/11 19:09:
>> Am 27.04.2011 02:34, schrieb David Holmes:
>>> Actually my comments more a response to Remi's assertion that clone should have been used 
>>> instead, without giving any technical rationale as to why clone would be better, and so much 
>>> better that it warranted Lance changing the code.
>>> Personally I think we should be steering people to Arrays.copyOf for all their array copying needs.
>> Hm, why?
> One API to learn that covers all the array-copying needs.
Ok, but from the point of *object-copying* needs, why should one care about sophisticated array stuff?

>>> clone() is effectively legacy code.
>> What does that mean?
> Just that it is an old mechanism that has been around for a long time, is limited to one specific 
> use-case and has been made somewhat redundant by the newer APIs.
Ok, you mean Array.copyOf() is clone() XL.
There are many places, where legacy code became redundant because of some extensions. Should we 
always avoid them? E.g.:
- StringBuilder.apend(...) instead '+'
- Objects.hashcode(obj) instead obj.hashcode()
- etc...

>> I prefer clone():
>> - less to type
>> - better to read, especially in looong code lines, e.g. as method call argument
> True. Would be nice if defender methods were expanded to allow you to do anArray.copyOf()
Can you explain that in other words. Sorry, I'm no english native ;-)


More information about the core-libs-dev mailing list