array clone() vs Arrays.copyOf()

[Stuart Marks]

On 4/27/11 2:19 AM, David Holmes wrote:
> Ulf Zibis said the following on 04/27/11 19:09:
>> BTW: Did you answer to the wrong thread (see attached screen shot) ? That was
>> the reason why I came aware about this post ;-)
>
> That's weird. No I only answered direct to Stuarts email.

I had replied on the same thread, but I changed the subject line in an attempt 
to make clear that I didn't intend to extend the review of Lance's change. The 
openjdk mail blockage intervened, and so David's reply appeared before my query.

* * *

As for Arrays.copyOf(), it's unfortunate that the overloads provided all 
require a length. It would be nice if you could just say

newArray = Arrays.copyOf(oldArray);

Then Arrays.copyOf() really would be one-stop shopping. I couldn't find any 
discussion about this, but I wouldn't be surprised if one-arg overloads of 
Arrays.copyOf() were ruled out with the reasoning that one could always use 
array.clone()! Of course, this is indeed redundant with array.clone(), but 
clone() is pretty obscure. I'll admit that I hadn't known about it until Rémi 
pointed it out in his review of Lance's changes.

> Would be nice if defender methods were expanded to allow you to do anArray.copyOf()

I'm not even sure defender methods are necessary here, since arrays don't 
implement any interface that, if extended, would cause binary compatibility. 
But I'm sure there are other language issues with extending arrays this way. 
This would also suffer from the same problem as clone(), in that it's pretty 
obscure. It's not in the javadoc, and you have to dive into the language spec 
in order to find it.

This is a minor point, but is it worth an RFE?

s'marks