Getting Method Parameter Names using Reflection

I was wondering how I could find the method parameter names (not just types) for the various methods of a class using reflection or some other technique if I have the Java Class.
It would be great if you could provide me some insight into it.

Not possible. This info isn't even present in the .class files that are generated by the compiler, so there is no way for the JVM to know what the name in the original source file was. Which is fine, usually, as the JVM has no reason to care what the name was. Other classes using the API don't need to know the name of a parameter - they just need to know the name of the method, and the types and order of the parameters. Make up any names you like.

If you really, really want these names, I believe you can achieve it by modifying .class files and including attribute_info. You wil also need to write a custom class loader and extensions to Reflection API to get your information, because standard Java system, as Jim said, doesn't provide any support for this task. An example of how this can be implemented is here.
Of course, you need *serious* reasons to go into all this trouble. :roll:

Good lord, if you write code that depends on all these extra hoops you better have total and permanent control of your deployment platform.

There isn't probably any sensible reason to actually do it, I just wanted to give trouble to Jim.

Cannot see when he is saying "not possible"...

Well, that's as good a reason as any for me to say it.

But in this case, I was mistaken - the parameter names are present in the class files. Of course, we know that there is absolutely no way™ that this info can be obtained through any of the classes in the JDK.
...
[waiting patiently...]

Sorry, Jim.

It was my way of saying that I am reading Stuart Halloway's "Component Development for the Java™ Platform" and it's really

book. It is published in the same DevelopMentor series as "Java Rules" and is almost as good as "Java Rules". Not quite as thorough (for example, they have a chapter on Reflection, but didn't say how to instantiate an inner class via Reflection!

Well, I guess it's kinda tangenial to their subject matter), but more practical, so maybe some readers will like it even more.
Just wanted to make sure you read the book.

I would prefer Jim's first answer to be correct, even though Map's citation proves her point (and that Jim's software is rapidly exceeding the boundaries of its programmer). The last thing a programmer wants, I would think, is knowledge that every little thing he puts in his code gets exposed in compiled form (or bytecode, in this case). I can't even think of a good (i.e., productive or useful) reason for it, other than proving it's possible.
So Andy, why do you want this ability? Whatcha goona use it for?

Originally posted by Michael Ernest:
I would prefer Jim's first answer to be correct

But it *is* correct!
-------------------------
Mapraputa Is
Sun Certified Programmer for the Java™2 Platform.
IBM Certified Developer - XML and Related Technologies.
Co-author of Java 2 Certification Passport