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

Martin Buchholz martinrb at google.com
Mon Sep 6 18:19:25 UTC 2010


On Sat, Sep 4, 2010 at 02:02, Jeroen Frijters <jeroen at sumatra.nl> wrote:

> Sorry to be late with my comment, but as a VM implementer I can't really
> agree with this modification. The return type of X[].clone() is clearly
> Object, not X{]. That illusion is a javac compiler trick. IMHO it belongs in
> the JLS not in the Object.clone() documentation.
>
>
I agree there is a little bit of cheating going on, but I don't agree that
the return type of X[].clone() is a "javac compiler trick".  In some sense
all compile-time types are javac-created illusions.  I do think a pointer to
the JLS may be worthwhile - the big downside with that is that such links to
the JLS are external, and as such become a maintenance problem - one needs
to "fix" all the JLS links in the API reference once every 5 years or so
when a new JLS comes out.

Martin


> Regards,
> Jeroen
>
> > -----Original Message-----
> > From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-
> > bounces at openjdk.java.net] On Behalf Of Joe Darcy
> > Sent: Saturday, September 04, 2010 12:01 AM
> > To: Martin Buchholz
> > Cc: core-libs-dev
> > Subject: Re: Code review request for 4881419 The type of X[].clone()
> > should be X[]
> >
> > Martin Buchholz wrote:
> > >
> > >
> > > On Thu, Sep 2, 2010 at 17:50, Joe Darcy <joe.darcy at oracle.com
> > > <mailto:joe.darcy at oracle.com>> wrote:
> > >
> > >     Martin Buchholz wrote:
> > >
> > >         The usage T[] suggests that T is a reference type, as with
> > >         generics, which is not the case here.
> > >
> > >         More precisely, both the runtime types and compiletime types
> > >         of the object returned from clone of any array is identical to
> > >         its input.
> > >         Is there a non-confusing way of saying that?
> > >
> > >
> > >     How about
> > >
> > >     "...and that the return type of the {@code clone} method of an
> > >     array type {@code T[]} is {@code T[]} where T is either a
> > >     reference or a primitive type."?
> > >
> > >
> > > So I went and actually read the Object.clone spec, and it does indeed
> > > guarantee that the (runtime) class of the returned value is the same
> > > as the class of the argument, for arrays.  As for the compile-time
> > > type, an experiment demonstrates that the return type is indeed
> > > exactly the same, including for non-reifiable array element types,
> > > e.g. this compiles:
> > >
> > >         Class<? extends Number>[] a
> > >             = (Class<? extends Number>[]) (new Class<?>[42]);
> > >         Class<? extends Number>[] clone = a.clone();
> > >
> > >
> > > So Ulf's restriction to non-reifiable T seems not to be correct.
> > >
> > > My suggested wording is:
> > >
> > > "...and that the return type of the {@code clone} method of an array
> > > type {@code T[]} is {@code T[]} where T is any reference or primitive
> > > type."
> > >
> > > Martin "Objects have class; Variables have type"
> >
> > Sounds good to me; change pushed!
> >
> > Thanks,
> >
> > -Joe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100906/6e5529e3/attachment.html>


More information about the core-libs-dev mailing list