Getting the class object for an array?
Lars Clausen
Hi!
I need to do method lookup using the reflection API for methods with
arbitrary types. I can get class types for object type and primitive types
easily, but I don't have a good way to get class types for array types.
Bad ways include creating an instance and using .class or looking around
for a method that happens to have such a type.
Basically, I need to know: If I have the Class object C for a type T,
how do I get the Class object for T[]?
Perusing the java docs and various faqs has not given me any clues.
Thanks in advance,
-Lars
--
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
"I do not agree with a word that you say, but I |----------------------------
will defend to the death your right to say it." | Where are we going, and
--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket?
Chris Uppal
>
> Basically, I need to know: If I have the Class object C for a type T,
> how do I get the Class object for T[]?
I'd love to be proved wrong, but I don't think there is any straightforward
way.
One approach (that does involve creating an instance, although you said you
don't want to do it) that is *ugly* but not too *messy* is to use:
java.lang.reflect.Array.newInstance(someClass, 0).getClass();
Otherwise you have to go though java.lang.Class.forName() with a messy bit of
logic like (untested):
Class someClass = ...whatever..;
String arrayClassName;
if (myClass.isPrimitive())
{
arrayClassName = "[x" // where 'x' is one of ZCBSILJFD
// according to which primitive
// type myClass is
}
else if (someClass.isArray())
{
arrayClassName = "[" + someClass.getName();
}
else // normal object class
{
arrayClassName = "[L" + someClass.getName() + ";";
}
Class arrayClass = Class.forName(
arrayClassName,
false,
someClass.getClassLoader());
Lovely eh?
-- chris
Tom McGlynn
c = ... some scalar class ...
arrayClass = Class.forName("[L" + c + ";");
However this will break if c is a primitive or array class.
You might try a small method like
Class arrayClass(Class inp) {
if (inp.isArray()) {
return Class.forName("[" + inp);
} else if (inp.isPrimitive) {
if (inp == double.class()) {
return double[].class;
}
... (seven other special cases ...
} else {
return Class.forName("[L" + inp + ";");
}
}
Might be a method tucked away in the reflection or util packages that
does this, but I'm not aware of it.
Good luck,
Tom McGlynn
Lars Clausen
> Lars Clausen wrote:
>>
>> Basically, I need to know: If I have the Class object C for a type T,
>> how do I get the Class object for T[]?
>
> I'd love to be proved wrong, but I don't think there is any
> straightforward way.
>
> One approach (that does involve creating an instance, although you said
> you don't want to do it) that is *ugly* but not too *messy* is to use:
>
> java.lang.reflect.Array.newInstance(someClass, 0).getClass();
Can't do that. Some of the classes might not even be instantiable using
newInstance(), and this is all taking place at compile time, where I
definitely don't want instances.
> Otherwise you have to go though java.lang.Class.forName() with a messy
> bit of logic like (untested):
>
> Class someClass = ...whatever..;
> String arrayClassName;
> if (myClass.isPrimitive())
> {
> arrayClassName = "[x" // where 'x' is one of ZCBSILJFD
> // according to which primitive
> // type myClass is
> }
> else if (someClass.isArray())
> {
> arrayClassName = "[" + someClass.getName();
> }
> else // normal object class
> {
> arrayClassName = "[L" + someClass.getName() + ";";
> }
> Class arrayClass = Class.forName(
> arrayClassName,
> false,
> someClass.getClassLoader());
>
> Lovely eh?
A work of art:) But it's what I'll have to do. Thank you!
I hope they'll add a method on Class that creates the arrayed Class.
Jon Skeet
> > One approach (that does involve creating an instance, although you said
> > you don't want to do it) that is *ugly* but not too *messy* is to use:
> >
> > java.lang.reflect.Array.newInstance(someClass, 0).getClass();
>
> Can't do that. Some of the classes might not even be instantiable using
> newInstance(), and this is all taking place at compile time, where I
> definitely don't want instances.
Creating an array *doesn't* create any instances of the class. For
example:
Integer[] x = new Integer[5];
doesn't create any Integer objects at all.
It creates an instance of the *array*, but I don't see why that would be
a problem.
--
Jon Skeet
sk...@pobox.com - http://www.pobox.com/~skeet
If replying to the group, please do not mail me at the same time
Tom Jones
Integer[] x = new Integer[5];
doesn't cause space for 5 ints to be allocated? Are you daft!?
How the heck can I do this then:
Integer[] x = new Integer[5];
x[3] = 6;
If he is working with arrays that contain a huge number of elements, he
might very well run out of memory before the allocation request is
satisfied.
People should really understand the language constructs before they start
'helping' people by answering questions...
Chris Uppal
ignorant usenet can be. I don't think that Tom Jones is really the killfiile
candidate that he(?) makes himself appear here, but, by God, he could hardly
show himself in a worse light...
-- chris
"Tom Jones" <tomjo...@hotmail.com> wrote in message
news:uu00vc3...@corp.supernews.com...
Jon Skeet
newsgroup at the same time.]
tomjo...@hotmail.com wrote:
> Are you saying that
> Integer[] x = new Integer[5];
>
> doesn't cause space for 5 ints to be allocated? Are you daft!?
I absolutely say that that doesn't cause space for 5 ints to be
allocated. It causes space for 5 references to be allocated, all of which
have the null value to start with. To test this, do:
Integer[] x = new Integer[5];
System.out.println (x[0].intValue());
and watch a NullPointerException be thrown...
int[] x = new int[5];
*does* cause space for 5 ints to be allocated - and one array object to
actually hold those ints.
> How the heck can I do this then:
> Integer[] x = new Integer[5];
> x[3] = 6;
You can't. That won't compile. Integer and int aren't the same thing at
all.
> If he is working with arrays that contain a huge number of elements, he
> might very well run out of memory before the allocation request is
> satisfied.
Yes, and that has nothing to do with instances being created - you can
run out of memory if there isn't room for all the *references* which are
needed, but doing
MyClass[] x = new MyClass[n];
doesn't cause any instances of MyClass to be created. This program
demonstrates this:
public class Test
{
public Test()
{
System.out.println ("In the constructor!");
}
public static void main (String[] args)
{
Test[] x = new Test[5];
}
}
If you were correct, that would print out "In the constructor!" 5 times.
As you're wrong, it doesn't print out anything.
> People should really understand the language constructs before they start
> 'helping' people by answering questions...
I agree. Hopefully this post has helped you understand the language
constructs in question...
Chris Uppal
> Yes, and that has nothing to do with instances being created - you can
> run out of memory if there isn't room for all the *references* which are
> needed, but doing
And, of course, the original context was of creating a zero-sized array. It
doesn't take a *great* deal of space to hold no references...
-- chris
Chris Uppal
> Creating an array *doesn't* create any instances of the class. For
> example:
Just to add to what Jon said, creating an array to hold elements of aClass
won't cause aClass to be initialised if it isn't already. So creating the
array won't make your code "touch" the class any more than you already have by
getting the class object in the first place. The array is just an unrelated
object and -- since you are obviously going to be creating lots of objects in
you compile-time processing, I don't see that creating one more small object
will do any harm.
I agree that it feels unsanitary, though.
-- chris
Carlton S. Anderson
news:MPG.184a3a949...@10.1.1.14...
<snipped>
You are _so_patient_. I don't think I could be so level-headed.
While Tom Jones' post will serve as an example of what _not_ to
do, yours would serve as an example of how to be a true mentor.
--
------------------------------------------------------------------karlik
Kenny MacLeod
> "Jon Skeet" <sk...@pobox.com> wrote in message
> news:MPG.184a3a949...@10.1.1.14...
> <snipped>
>
> You are _so_patient_. I don't think I could be so level-headed.
> While Tom Jones' post will serve as an example of what _not_ to
> do, yours would serve as an example of how to be a true mentor.
I think Mr Jones is at this very moment cringing under the table in
embarrassment :-)
Nice one, Jon.
Jon Skeet
> > You are _so_patient_. I don't think I could be so level-headed.
> > While Tom Jones' post will serve as an example of what _not_ to
> > do, yours would serve as an example of how to be a true mentor.
>
> I think Mr Jones is at this very moment cringing under the table in
> embarrassment :-)
>
> Nice one, Jon.
I confess at this stage that my private response to his email (which I
received prior to seeing the post - that's why I don't like getting both)
was somewhat less patient. I wish I could claim to be high minded enough
never to get personal myself, but I can't :(
Tom Jones
that my response was terse and uncalled for. I apologize.
I have been developing commercial software in C++ for 11 years. If you have
done any software development in C++ on the Windows platform you can be sure
that you have used at least one of my tools.
I apologize for not making my response clearer from a technical point of
view. When I think of Java (or C#, etc.) I don't think about the language
specific constructs (Jon Skeet: "It causes space for 5 references to be
allocated"), I think about the actual implementation details. You say space
for references, when in fact, at the VM level what you are allocating is
space for sizeof(int)*5 bytes or more correctly on the windows platform:
sizeof(DWORD_PTR)*5.
When I started learning Java, the FIRST thing I did was practically memorize
the VM Spec. I believe that to truly understand a language environment, you
should have a very good understanding of how it is put together. Again,
anyone who has done any significant amount of development on Windows will
know that there are times when you truly need to disassemble pieces of
kernel32/ntdll to accomplish what needs to be accomplished - it is
distasteful, but that is the nature of commercial software at times. Take
it from someone who has viewed much of the actual source code for ntdll -
even MS has to do some very nasty things to make stuff work.
I realize that I am most likely in most of your killfiles by now, but I at
least wanted to explain myself from a technical standpoint. I can't defend
myself regarding any personal attacks - I am not a nice person - I am ok
with that. As long as companies continue to utilize me to solve problems I
don't really worry about being nice.
Tom
PS: I am sending a copy of this email directly to Jon Skeet, to whom I
apologize for being a down right buffoon.
"Jon Skeet" <sk...@pobox.com> wrote in message
news:MPG.184a3a949...@10.1.1.14...
Tom Jones
My latest response was written before I read the personal email that you
sent me (snippet below). Please find a technical explanation of what truly
happens when the Java VM (on the Windows platform) executes:
int x = new int[5];
> I'm ready to accept your apology as soon as you're ready to give it. I'm
> actually pretty knowledgeable about the language constructs, though I say it
> myself. I think you'll find that if you ask others on the group about their
> opinion of me, they'd agree.
>
> Now, are you ready to take your foot out of your mouth?
>
> Jon
>
I am sure you *are* knowledgeable regarding Java. But I have verified my
beliefs by using a kernel debugger (NuMega SoftICE) to step through the VM
when the code for:
Int[] x = new int[5];
is executed. Actually, I have stepped through the Java source, into the
JIT'ed Java Byte Code, then into Intel Assembly (I am running on a Pentium
4). The VM allocates space from a global heap (allocated via the
kernel32.dll function HeapAlloc()) for sizeof(int)*10 (I don't know what the
extra space is for - most likely for internal housekeeping.
Once again, while I agree that you are much more knowledgeable about how the
VM implementers tell you how something works, I would challenge you any day
to determine what is actually happening under the hood in a manner that is
more correct/provable then the techniques that I have been using for years
to reverse engineer the Windows operating system.
Don't always believe the documentation Jon - it is best to prove how things
work instead (and before anyone flames me for performing very platform
specific tests, I do not argue that another VM (or the same VM on another
platform) may act differently). All testing was done on the 1.4 JRE running
under Windows XP Professional SP1 (checked build).
As a very wise developer once said to me, "There is nothing complicated
about it, it is *just* software". ;-)
Tom
Jon Skeet
> My latest response was written before I read the personal
> email that you
> sent me (snippet below). Please find a technical explanation
> of what truly
> happens when the Java VM (on the Windows platform) executes:
>
> int x = new int[5];
Comments below, but why bother in the first place? This is now very
separate from the important point in the thread, which was that no
instances of the array element type objects are created when an
array of references is created. That was the only point that was
relevant to the discussion, so I'm not sure why you've brought this
example up at all.
> I am sure you *are* knowledgeable regarding Java. But I have
> verified my beliefs
Which particular beliefs? You were wrong on various things, and
right on a couple. Are you still suggesting I'm incorrect in
something I posted? If so, I'd be grateful if you'd point out
*exactly* what you disagree with.
> by using a kernel debugger (NuMega SoftICE) to step
> through the VM when the code for:
>
> Int[] x = new int[5];
>
> is executed. Actually, I have stepped through the Java
> source, into the JIT'ed Java Byte Code, then into Intel assembly
> (I am running on a Pentium 4).
The Intel assembly *is* the result of the JITted byte code. Do you
mean you stepped through the byte code which was then JITted?
> The VM allocates space from a global heap (allocated via the
> kernel32.dll function HeapAlloc()) for sizeof(int)*10 (I
> don't know what the extra space is for - most likely for internal
> housekeeping.
I suspect that sizeof(int)*10 is a very misleading way of putting
it. Where did the sizeof(int) bit come from? Is that part of the
machine code generated? I doubt it.
I rather suspect that it was just allocating 40 bytes, which
would actually be 4*5+20, where the 4*5 is as defined in the VM
spec, as Java ints are always 4 bytes long, and the 20 is the extra
stuff in the array object itself, notably the length of the array (4
bytes) and other standard object overhead (such as classloader, type
etc). If I wanted to know any more precisely, I'd look at the VM
source code, assuming it was available (which it is for the VMs I
tend to use).
> Once again, while I agree that you are much more
> knowledgeable about how the
> VM implementers tell you how something works, I would
> challenge you any day to determine what is actually happening under
> the hood in a manner that is
> more correct/provable then the techniques that I have been
> using for years to reverse engineer the Windows operating system.
It's very easy - you look at the source code for HotSpot, which is
publicly available if you don't mind the fact that you'll then never
be able to write your own clean-room JVM.
Alternatively (and this is the route I favour) you just avoid
talking in terms of implementation details. You stick to *only* what
the spec guarantees, until you need to know anything about any one
particular implementation. Only *then* do you investigate that
implementation.
In particular, when talking about Java the language, you should talk
in *language* terms rather than implementation terms. For instance,
when I wrote:
<quote>
Creating an array *doesn't* create any instances of the class. For
example:
Integer[] x = new Integer[5];
doesn't create any Integer objects at all.
</quote>
I was entirely correct, whatever may happen underneath. And the
important thing there is that it means that Lars has a solution to
his problem. That's something that your implementation testing
didn't give, isn't it?
> Don't always believe the documentation Jon - it is best to
> prove how things work instead (and before anyone flames me for
> performing very platform specific tests, I do not argue that another
> VM (or the same VM on another platform) may act differently).
What benefit have you actually found for doing that in the case of
Java though? Until the documentation proves to be wrong, it provides
a *much* better model than basing assumptions of how to write Java
based on painstaking tests of implementation details for one rev of
one VM on one OS on one processor type.
In particular, the implementation details are entirely irrelevant to
this thread.
If you really have so much faith in your "get right down to the
metal" approach, why haven't you got something set up to find out
what microcode is being executed in the processor? Why are you
unwilling to treat the JVM in the same way that you're treating your
P4?
A couple of hints about netiquette while I remember. Firstly, it's bad
form to quote personal emails on public newsgroups. Secondly, good
apologies usually *don't* start with "Lord you guys are touchy." I think
it's pretty understandable that people get a bit upset when someone
starts throwing insults around and being patronising when in fact he
doesn't understand what he's criticising.
rupton
it's kind of funny though that you originally chastise Jon for not knowing
the ``language constructs" and then turn around and castigate him for
knowing them so well by patronizingly tell him not to rely on the language
and VM specification.
"Tom Jones" <tomjo...@hotmail.com> wrote in message
news:BA069F32.971%tomjo...@hotmail.com...
Tom Jones
discovered the true point of the argument/misunderstanding. Jon was wrong
unfortunately - and here is why:
[This is from Jon]
> Here was what I posted which got you up in arms:
>
> <quote>
> Creating an array *doesn't* create any instances of the class. For
> example:
>
> Integer[] x = new Integer[5];
>
> doesn't create any Integer objects at all.
>
> It creates an instance of the *array*, but I don't see why that would be
> a problem.
> </quote>
[This summarizes my reply]
I recall that you are correct in that the above was what "set me off".
I absolutely agree that in the above line of code, no Integer objects are
created. What I, very lamely it seems, was arguing was that while 0
Integers were allocated, the array itself [after this above statement
completes] consists of (at a minimum) of 5 references to null. A reference
(pointer) on any given platform is sizeof(int) bytes, so on Windows the
above statement caused [at least] sizeof(int)*5 bytes to be allocated.
So, if I do this:
Integer[] x = new Integer[5000000];
I have just sucked up sizeof(int)*5000000 (~20 Meg) bytes of memory.
That is all I was trying to say - sorry for the confusion. My entire point
was that you were trying to tell someone that creating a large array of
Integer objects wouldn't have a negative impact - that is incorrect - and
which is why I espouse understanding what is really going on down in the VM.
You can see this behavior for yourself:
class MemTest
{
public static void main(String args[])
{
// pause a bit to take a peek at java.exe's memory usage
Thread.sleep(10000);
Integer[] x = new Integer[5000000];
// pause a bit to take a peek at java.exe's memory usage
// At this point the memory usage just jumped about 20 megs
Thread.sleep(10000);
}
}
Again, I apologize to everyone for being belligerent - I just didn't
understand why no one was getting my point - going back through the thread I
can see how I was unclear.
And to respond to rupton who felt I was being patronizing to Jon Skeet when
I complimented him on his Java knowledge, you are incorrect. After my
original post (which was my first post to this group - I think), I found
Jon's amazing contributions to this group, and his personal website that
shows his dedication to this area of computer science. He seems like a
downright all-around good guy - I simply didn't agree with what he was
saying - to which I was correct.
Good day.
Tom
On 11/24/02 11:21 PM, in article
NyhE9.1778$kO5.1...@news1.news.adelphia.net, "rupton"
Jon Skeet
> After having a very pleasant conversion with Jon Skeet offline, we
> discovered the true point of the argument/misunderstanding.
> Jon was wrong unfortunately - and here is why:
No I wasn't - and here's why:
<snip stuff about the size of references, which is also incorrect by the
way - I've replied about that in email>
> My entire point was that you were trying to tell someone that creating a
> large array of Integer objects wouldn't have a negative impact - that is
> incorrect - and which is why I espouse understanding what is really going
> on down in the VM.
a) You don't create an array of objects, you create an array of
*references*, and that distinction is vitally important to the original
discussion
b) I didn't say anything about creating a large array. I talked about
creating a small array of Integer references, and how it didn't involve
creating any Integer *instances*.
I never *once* claimed that constructing an array such as
Integer[] x = new Integer[5];
wouldn't take up any memory.
Please read the thread from the *start* rather than just from your first
post, and you'll see the problem that was being solved.
Then, if you can find where I was supposedly trying to tell someone that
"creating a large array of Integer objects wouldn't have a negative
impact" you should quote that. I'm certain you won't find any such thing
to quote, however.
> Again, I apologize to everyone for being belligerent - I just didn't
> understand why no one was getting my point - going back through the thread I
> can see how I was unclear.
I suggest you go back and read it *again* then and find out that I never
made the point you were disagreeing with.
> And to respond to rupton who felt I was being patronizing to Jon Skeet when
> I complimented him on his Java knowledge, you are incorrect. After my
> original post (which was my first post to this group - I think), I found
> Jon's amazing contributions to this group, and his personal website that
> shows his dedication to this area of computer science. He seems like a
> downright all-around good guy - I simply didn't agree with what he was
> saying - to which I was correct.
Except you weren't. You didn't agree with what you *thought* I was
saying, which is an entirely different matter.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Thomas Hawtin
>
> [...] A reference
> (pointer) on any given platform is sizeof(int) bytes, [...]
News to me. Back when I was for a short time a Windows C++ programmer
one of the builds was for a 286 memory model (large?) that used 32-bit
pointers whilst retaining the 16-bit ints. I believe 64-bit systems
often use 64-bit pointers, but leave int and indeed long as 32-bits,
requiring long long for 64-bit integers.
I must say that for, IIRC, 11 years of C++ Windows experience and low
down and dirty approach you seem to have made a number of disturbing
errors in this thread. I don't know whether C++ or Windows causes more
brain rot. :)
Tackline
--
http://www.tackline.demon.co.uk/
Unemployed Java Developer of Central London.
Jon Skeet
specification guarantees that sizeof(int) == void*.
While I openly admit that I am a Java newbie, I would love it if you would
point out the errors I have made regarding ANYTHING related to C, C++,
Win32, .NET, etc.
On 11/25/02 12:39 PM, in article 3DE26047...@tackline.demon.co.uk,
Thomas Hawtin
Don't you think that's a really dumb game to play?
[Not] Jon Skeet wrote:
>
> Actually, I was speaking from a C background. The ANSI C language
> specification guarantees that sizeof(int) == void*.
Does it? I don't have a copy. Clearly common implementations disagree.
Blair Wyman
>
> Actually, I was speaking from a C background. The ANSI C language
> specification guarantees that sizeof(int) == void*.
Oops. With all due respect, this isn't so. Conversions between ints and
pointers are implementation-dependent.
As a counterexample: In ANSI-compliant OS/400 ILE C, pointers are either
8 or 16 bytes long, depending on the storage model.
--
___ _ Blair Wyman IBM Rochester
( /_) / _ ' _ (507)253-2891 bla...@us.ibm.com
__/__)_/_<_/_/_/_' Opinions expressed may not be those of IBM
Blair Wyman
So, while "with all due respect" still applies, it now evaluates to null. :-/
Tom West
<bla...@us.ibm.com> wrote:
> Jon Skeet wrote:
>>
>> Actually, I was speaking from a C background. The ANSI C language
>> specification guarantees that sizeof(int) == void*.
>
> Oops. With all due respect, this isn't so. Conversions between ints and
> pointers are implementation-dependent.
>
> As a counterexample: In ANSI-compliant OS/400 ILE C, pointers are either
> 8 or 16 bytes long, depending on the storage model.
Hi Blair, I must have missed the impersonator thingy, but what I think the
person was trying to state [hopefully anyway] is that the standard requires
an implementation to guarantee that sizeof(int) is equivalent to the size of
an int* on a given platform.
HTH
Blair Wyman
Now, despite the claim, ANSI C does NOT require sizeof(int)==sizeof(void*).
IIRC, it *does* require certain conversions from integer zero to/from null
pointer, but the actual size of a pointer in memory is
implementation-dependent.
Since I didn't have the spec handy, I cited a counterexample. Anyone care to
cite chapter and verse?
Thanks again.
-blair
--
Frank Breuer
> Since I didn't have the spec handy, I cited a counterexample.
> Anyone care to cite chapter and verse?
6.1.2.5 Types
6.2.2.2 void
6.2.2.3 Pointers
6.3.3.4 The sizeof operator
Non of this requires sizeof(int) = sizeof(int*) or sizeof(int) =
sizeof(void*) or any such nonsens. All that is required is that a void*
is identical in representation and storrage (allignment) to a char*.