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
