Is clone a member function for array types?

[tam]

According to the JLS clone is a public method for all array types:

6.4.5 Members of an Array Type

....
The public method clone, which overrides the method of the same name
in class Object and throws no checked exceptions. The return type of
the clone method of an array type T[] is T[].
....

However if I run the following program (JDK 1.5.0_04-b05 on Linux):

import java.lang.reflect.*;
public class Test {

public static void main(String[] args) {
int[] x = {1,2,3};

System.out.println("Class:"+x.getClass());
Class cls = x.getClass();
Method[] methods= cls.getMethods();
for(Method meth: methods) {
System.out.println("Method:"+meth);
}
}
}


I get the output

Class:class [I
Methodublic native int java.lang.Object.hashCode()
Methodublic final native java.lang.Class
java.lang.Object.getClass()
Methodublic final native void java.lang.Object.wait(long) throws
java.lang.InterruptedException
Methodublic final void java.lang.Object.wait(long,int) throws
java.lang.InterruptedException
Methodublic fina lean java.lang.Object.equals(java.lang.Object)
Methodublic final native void java.lang.Object.notify()
Methodublic final native void java.lang.Object.notifyAll()
Methodublic java.lang.String java.lang.Object.toString()

The clone method is missing.

The JavaDocs for the Class.getMethods is:

Returns an array containing Method objects reflecting all the public
member methods of the class or interface represented by this Class
object, including those declared by the class or interface and those
inherited from superclasses and superinterfaces.

So I should have gotten all the public methods, and clone is supposed
to be public, but it's
not showing up.... Does anyone have any idea what I'm missing?

Regards,
Tom McGlynn

 

[Daniel Pitts]

According to the JLS clone is a public method for all array types:

6.4.5 Members of an Array Type

....
The public method clone, which overrides the method of the same name
in class Object and throws no checked exceptions. The return type of
the clone method of an array type T[] is T[].
....

However if I run the following program (JDK 1.5.0_04-b05 on Linux):

import java.lang.reflect.*;
public class Test {

public static void main(String[] args) {
int[] x = {1,2,3};

System.out.println("Class:"+x.getClass());
Class cls = x.getClass();
Method[] methods= cls.getMethods();
for(Method meth: methods) {
System.out.println("Method:"+meth);
}
}
}


I get the output

Class:class [I
Methodublic native int java.lang.Object.hashCode()
Methodublic final native java.lang.Class
java.lang.Object.getClass()
Methodublic final native void java.lang.Object.wait(long) throws
java.lang.InterruptedException
Methodublic final void java.lang.Object.wait(long,int) throws
java.lang.InterruptedException
Methodublic fina lean java.lang.Object.equals(java.lang.Object)
Methodublic final native void java.lang.Object.notify()
Methodublic final native void java.lang.Object.notifyAll()
Methodublic java.lang.String java.lang.Object.toString()

The clone method is missing.

The JavaDocs for the Class.getMethods is:

Returns an array containing Method objects reflecting all the public
member methods of the class or interface represented by this Class
object, including those declared by the class or interface and those
inherited from superclasses and superinterfaces.

So I should have gotten all the public methods, and clone is supposed
to be public, but it's
not showing up.... Does anyone have any idea what I'm missing?

Regards,
Tom McGlynn

hmm... Try using getDeclaredMembers to see. It could be that array
cloning is a special case, look at the VM spec to see if there are any
hints there. Array types *are* a special case in the JVM.

 

[Roedy Green]

Does anyone have any idea what I'm missing?

My guess is arrays are handled as a special case. For example you can
iterate over them with for:each even though they don't implement
Iterable.

 

[tam]

According to the JLS clone is a public method for all array types:

6.4.5 Members of an Array Type

....
The public method clone, which overrides the method of the same name
in class Object and throws no checked exceptions. The return type of
the clone method of an array type T[] is T[].
....

However if I run the following program (JDK 1.5.0_04-b05 on Linux):

import java.lang.reflect.*;
public class Test {

public static void main(String[] args) {
int[] x = {1,2,3};

System.out.println("Class:"+x.getClass());
Class cls = x.getClass();
Method[] methods= cls.getMethods();
for(Method meth: methods) {
System.out.println("Method:"+meth);
}
}
}

I get the output

Class:class [I
Methodublic native int java.lang.Object.hashCode()
Methodublic final native java.lang.Class
java.lang.Object.getClass()
Methodublic final native void java.lang.Object.wait(long) throws
java.lang.InterruptedException
Methodublic final void java.lang.Object.wait(long,int) throws
java.lang.InterruptedException
Methodublic fina lean java.lang.Object.equals(java.lang.Object)

Seem to have accidentally done some editing here.
This should be 'public boolean"...

hmm... Try using getDeclaredMembers to see. It could be that array
cloning is a special case, look at the VM spec to see if there are any
hints there. Array types *are* a special case in the JVM.

Do you mean getDeclaredMethods? I tried that but it returns an empty
array. That's OK in principle since the method might be declared in
some superclass of [I but getMethods should find it regardless of
where it's declared.

Although arrays are special, it seems very peculiar for there to be
objects of any type with methods not visible by reflection that may
still be invoked non-reflectively.

Regards,
Tom McGlynn

 

[tam]

According to the JLS clone is a public method for all array types:

6.4.5 Members of an Array Type

....
The public method clone, which overrides the method of the same name
in class Object and throws no checked exceptions. The return type of
the clone method of an array type T[] is T[].
....

However if I run the following program (JDK 1.5.0_04-b05 on Linux):

import java.lang.reflect.*;
public class Test {

public static void main(String[] args) {
int[] x = {1,2,3};

System.out.println("Class:"+x.getClass());
Class cls = x.getClass();
Method[] methods= cls.getMethods();
for(Method meth: methods) {
System.out.println("Method:"+meth);
}
}
}

I get the output

Class:class [I
Methodublic native int java.lang.Object.hashCode()
Methodublic final native java.lang.Class
java.lang.Object.getClass()
Methodublic final native void java.lang.Object.wait(long) throws
java.lang.InterruptedException
Methodublic final void java.lang.Object.wait(long,int) throws
java.lang.InterruptedException
Methodublic fina lean java.lang.Object.equals(java.lang.Object)

Seem to have accidentally done some editing here.
This should be 'public boolean"...

hmm... Try using getDeclaredMembers to see. It could be that array
cloning is a special case, look at the VM spec to see if there are any
hints there. Array types *are* a special case in the JVM.

Do you mean getDeclaredMethods? I tried that but it returns an empty
array. That's OK in principle since the method might be declared in
some superclass of [I but getMethods should find it regardless of
where it's declared.

Although arrays are special, it seems very peculiar for there to be
objects of any type with methods not visible by reflection that may
still be invoked non-reflectively.

Regards,
Tom McGlynn

 

[tam]

My guess is arrays are handled as a special case. For example you can
iterate over them with for:each even though they don't implement
Iterable.

The JLS explicitly mentions that arrays can be iterated over in the
enhanced for loop. Unless there is something I'm missing here [which
is quite likely but I'd like to know what it is], there seems to be a
clear incompatibility between the JLS specification of array members
and Class.getMethods results for arrays. There's nothing I've found
in the documentation that suggests arrays should be handled specially
here.

Regards,
Tom McGlynn

 

[Mike Schilling]

The JLS explicitly mentions that arrays can be iterated over in the
enhanced for loop. Unless there is something I'm missing here [which
is quite likely but I'd like to know what it is], there seems to be a
clear incompatibility between the JLS specification of array members
and Class.getMethods results for arrays. There's nothing I've found
in the documentation that suggests arrays should be handled specially
here.

Of course arrays can be used in enhanced for loops; that doesn't imply that
they implement Iterable. The compiler knows that it's an array, and can
emit code accordingly. E.g.

for (int entry : i)
{
System.out.println(entry);
}

generates

int arr$[] = i;
int len$ = arr$.length;
for(int i$ = 0; i$ < len$; i$++)
{
int entry = arr$[i$];
System.out.println(entry);
}

 

[Daniel Pitts]

My guess is arrays are handled as a special case. For example you can
iterate over them with for:each even though they don't implement
Iterable.

The JLS explicitly mentions that arrays can be iterated over in the
enhanced for loop. Unless there is something I'm missing here [which
is quite likely but I'd like to know what it is], there seems to be a
clear incompatibility between the JLS specification of array members
and Class.getMethods results for arrays. There's nothing I've found
in the documentation that suggests arrays should be handled specially
here.

Regards,
Tom McGlynn

array.length is actually a special JVM instruction, not a field access.

 

[Patricia Shanahan]

Does anyone have any idea what I'm missing?
My guess is arrays are handled as a special case. For example you can
iterate over them with for:each even though they don't implement
Iterable.

The JLS explicitly mentions that arrays can be iterated over in the
enhanced for loop. Unless there is something I'm missing here [which
is quite likely but I'd like to know what it is], there seems to be a
clear incompatibility between the JLS specification of array members
and Class.getMethods results for arrays. There's nothing I've found
in the documentation that suggests arrays should be handled specially
here.

Regards,
Tom McGlynn

array.length is actually a special JVM instruction, not a field access.

At the Java source language level, according to the JLS, length is a
public final field member of an array type, so it *should* show up in
reflection. However, according to the API documentation for
java.lang.Class, "Every array also belongs to a class that is reflected
as a Class object that is shared by all arrays with the same element
type and number of dimensions."

Patricia

 

[Stefan Ram]

However, according to the API documentation for
java.lang.Class, "Every array also belongs to a class that is
reflected as a Class object that is shared by all arrays with
the same element type and number of dimensions."

It is always on my mind, whether an array is an instance
of a class. What you quote sounds as if this is so.

On the other hand, the JLS3 says:

»An object (§4.3.1) is a dynamically created instance
of a class type or a dynamically created array.«

JLS3, 4

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html

»An object is a class instance or an array.«

JLS3, 4.3.1

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3.1

If an array is an instance of a class, then why does the JLS
adds »... or an array« in the quotations? It would be
sufficient to state »An object is a class instance.«, because
this would include arrays.

 

[tam]

My guess is arrays are handled as a special case. For example you can
iterate over them with for:each even though they don't implement
Iterable.

You're right! I've looked more carefully at the JavaDocs and I see
that you're right and the description for getMethods explicitly
mentions that only the
methods inherited from Object are returned:
"Array classes return all the (public) member methods inherited from
the Object class."

Not sure how I missed that in my first read through, but I should have
been more careful when posting. It's still a bit of a gotcha, but my
apologies for misleading anyone that it is not consistent with the
documentation.

I see that the discussion of getFields similarly talks in detail about
not handling the length attribute that Patricia talks about elsewhere
in this thread.

This came up in a routine that was trying to do a generic clone. I
was checking that an object implemented Cloneable and had a public
clone method reflectively, It looks like I need to check for arrays
explicitly also.

Regards,
Tom McGlynn

 

[Daniel Pitts]

You're right! I've looked more carefully at the JavaDocs and I see
that you're right and the description for getMethods explicitly
mentions that only the
methods inherited from Object are returned:
"Array classes return all the (public) member methods inherited from
the Object class."

Not sure how I missed that in my first read through, but I should have
been more careful when posting. It's still a bit of a gotcha, but my
apologies for misleading anyone that it is not consistent with the
documentation.

I see that the discussion of getFields similarly talks in detail about
not handling the length attribute that Patricia talks about elsewhere
in this thread.

This came up in a routine that was trying to do a generic clone. I
was checking that an object implemented Cloneable and had a public
clone method reflectively, It looks like I need to check for arrays
explicitly also.

Regards,
Tom McGlynn

Not to mention Arrays are a special case anyway.
I believe that if you clone a multi-dimensional array, you in fact only
clone the left-most dimension, and therefor have shared elements.

Not to mention that performance wise, .clone on arrays(in currently
implementations) tends to be slower than creating a new array and using
System.arrayCopy. Also, in Java 6 java.util.Arrays has some very nice
methods for copying and resizing arrays. No deep copy though :-(

Why, may I ask, are you trying to create a generic clone? What problem
will be solved by it? Its been my experience that using reflection
should be a last resort, or used only in framework libraries/APIs.

 

[tam]

(e-mail address removed) wrote: ....
Not to mention Arrays are a special case anyway.
I believe that if you clone a multi-dimensional array, you in fact only
clone the left-most dimension, and therefor have shared elements.

Actually I think that a deep clone of arrays would have been the
special case, were that to have been Java's behavior. Java does not
have multidimensional arrays. It only has arrays of arrays. The
default behavior of shallow cloning seems perfectly in keeping with
the shallow cloning of objects generally.

Not to mention that performance wise, .clone on arrays(in currently
implementations) tends to be slower than creating a new array and using
System.arrayCopy. Also, in Java 6 java.util.Arrays has some very nice
methods for copying and resizing arrays. No deep copy though :-(

The library that this came up in dates back all of the way to Java 1.0
in its origins, though clearly it's been updated a bit since I don't
think getMethods was available till at least 1.1 (Maybe 1.2?). A deep
copy of arrays is another of the functions it provides.

Why, may I ask, are you trying to create a generic clone? What problem
will be solved by it? Its been my experience that using reflection
should be a last resort, or used only in framework libraries/APIs.

The method is used in a library which reads a data format (FITS) which
can
contain a variety of objects including arrays of any primitive type,
and tables
with columns of heterogeneous data. It's often necessary to make
duplicates
of a structure and having a single method to do so is very
convenient. At one
time using clone seemed simplest since it allows me to use a common
method for both my custom classes, primitive arrays and the a few
standard Java classes that may be included in the structures
conveniently. In fact this method is not used much -- the deep array
copy I mentioned above is used in most of the cases where I
anticipated this method might be used. That uses reflection too but
not the classes of java.lang.reflect. It's not liable to the bug that
lay hidden in the generic clone for so long.

When one is dynamically constructing objects using reflection can be
the natural approach and that's one of the things that the library is
supporting -- that might be what you have in mind as a 'framework/
API'.

Regards,
Tom McGlynn