Code review request for 4881419 The type of X[].clone() should be X[]

Ulf Zibis Ulf.Zibis at gmx.de
Fri Sep 3 23:13:07 UTC 2010



  188      * The method {@code clone} for*class*  {@code Object} performs a
  189      * specific cloning operation. First, if the*class*  of this*object*does
  190      * not implement the interface {@code Cloneable}, then a
  191      * {@code CloneNotSupportedException} is thrown. Note that all arrays
  192      * are considered to implement the interface {@code Cloneable} and that
  193      * the return*type*of the {@code clone} method of an array*type*
  194      * {@code T[]} is {@code T[]}.
  195      * Otherwise, this method creates a new*instance*of the*class*  of this
  196      **object*and initializes all its fields with exactly the contents of
  197      * the corresponding fields of this*object*, as if by assignment; the
  198      * contents of the fields are not themselves cloned. Thus, this method
  199      * performs a "shallow copy" of this*object*, not a "deep copy" operation.

Hm,
the whole enclosing paragraph talks about class, object and instance, so why talk about type for the 
array case?

-Ulf


Am 04.09.2010 00:53, schrieb Martin Buchholz:
> Ulf,
>
> The spec needs to talk about *both* class (runtime) and type (compile-time).
> And now it does.
>
> Martin
>
> On Fri, Sep 3, 2010 at 15:31, Ulf Zibis <Ulf.Zibis at gmx.de <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>      Am 04.09.2010 00:05, schrieb Joe Darcy:
>
>         Ulf Zibis wrote:
>
>             Am 03.09.2010 12:31, schrieb Ulf Zibis:
>
>
>                 I think the question of variable types belongs to the spec, but here in Object
>                 class's javadoc we should speak about objects. So I now suggest:
>                 "...and that the returned object of the {@code clone} method of an array object of
>                 class {@code T[]} is of class {@code T[]} where T is any [raw]? reference or
>                 primitive class. See java language specification version 3, section 6.4.5"
>
>
>             And additionally 2 cents: As T is often used for parameter type in context with
>             generics, I think, X would leed to less misinterpretation and would match better to
>             the according spec.
>
>
>         I think the text as suggested by Martin with the explicit definition of T is sufficiently
>         clear as-is.
>
>         -Joe
>
>
>     I still think, it would be more clear to speak about classes here rather then about types.
>     See:
>            Number[] na = new Integer[123];
>            na[0] = new Integer(456);
>            Integer[] ia = (Integer[])na.clone();
>
>     na is of type Number[]
>     ia is of type Integer[] and too of type Number[]
>     but ia contains object of class Integer[]
>
>     -Ulf
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100904/c28362a1/attachment.html>


More information about the core-libs-dev mailing list