Java Forum / General / March 2006
Anyone know how to get parameter name?
JessyCute - 22 Mar 2006 11:10 GMT I want to get parameter name from specify method. Example:
Code:
public class AClass {
public AClass() {} public int checkReturn(String input_check, int index){ return 0; } }
I want to get "input_check" string and "index" string that are the parameter name of checkReturn. Currently, I tried to use reflection java.lang.reflect.
Code:
String className = "AClass"; Class c = Class.forName(className); Method[] m = c.getMethods(); Constructor[] ctor = c.getConstructors();
System.out.println("\nConstructors list:"); for(int i = 0; i < ctor.length; i ++){ System.out.println(ctor[i].toString()); }
System.out.println("\nMethod list:"); for(int i = 0; i < m.length; i ++){ System.out.println("method-" + i + ">" + m[i].getName() );
System.out.println(m[i].toString()); }
But it doesn't know what is the parameter name, any one know. Thank you in advance. ^^
Bart Cremers - 22 Mar 2006 11:28 GMT As far as I know the compiler throws away parameter names. So I guess there is no way to get the names of parameters at runtime.
Regards,
Bart
Roedy Green - 22 Mar 2006 22:41 GMT > So I guess >there is no way to get the names of parameters at runtime. > >Regards, > >Bart If you examine a class file with a hex viewer, you will see the method names and the method signatures, but not the parameter names.
To get that information you would have to parse the original Java source or do something clever with a Doclet.
See http://mindprod.com/jgloss/doclet.html
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Timbo - 22 Mar 2006 11:35 GMT > But it doesn't know what is the parameter name, any one know. Thank you > in advance. ^^ That can't be done unfortunately. Parameter names are not recorded in the bytecode. If you have access to the source code itself, there are plenty of parsers that can you can use to help get that type of info.
Chris Uppal - 22 Mar 2006 12:22 GMT > I want to get parameter name from specify method. You can't. That information (the names of parameters and other local variables) is discarded by the compiler and is not available at runtime.
-- chris
Mike Schilling - 22 Mar 2006 23:46 GMT >> I want to get parameter name from specify method. > > You can't. That information (the names of parameters and other local > variables) is discarded by the compiler and is not available at runtime. Quibble: debuggers know them, so the parameter names must be stored when compiling for debug. It's presumably possible to open up the classfile and read them.
Of course, there's no guarenteed way to open the classfile...
Chris Uppal - 23 Mar 2006 11:56 GMT [me:]
> > You can't. That information (the names of parameters and other local > > variables) is discarded by the compiler and is not available at runtime. [quoted text clipped - 4 lines] > > Of course, there's no guarenteed way to open the classfile... <grin>
Or any guarantee that the debugging info (local variable tables) will be present (and correct) if you do manage to open it...
-- chris
Mike Schilling - 23 Mar 2006 17:05 GMT > [me:] >> > You can't. That information (the names of parameters and other local [quoted text clipped - 11 lines] > Or any guarantee that the debugging info (local variable tables) will be > present (and correct) if you do manage to open it... Well, that too.
Piotr Kobzda - 22 Mar 2006 13:13 GMT > I want to get parameter name from specify method. It's not easy, but you CAN do that.
Specifying -g:vars as a compiler option will result in saving the names of method parameters in LocalVariableTable_attribute structure of the generated class file.
Refer to the Java Class File Format specification for info on how to access this information. Or use one of the available class file manipulation libraries (e.g. ObjectWeb ASM).
Regards, piotr
Timbo - 22 Mar 2006 13:53 GMT >> I want to get parameter name from specify method. > [quoted text clipped - 3 lines] > of method parameters in LocalVariableTable_attribute structure of the > generated class file. Well, bugger me. I never knew that!
Ben_ - 22 Mar 2006 22:17 GMT I didn't know what particular settings caused it, but it's obvious to me that the information can be kept. Otherwise, how would a decompiler produce code so close to the original ?
Oliver Wong - 22 Mar 2006 22:15 GMT >I didn't know what particular settings caused it, but it's obvious to me > that the information can be kept. Otherwise, how would a decompiler > produce > code so close to the original ? Which decompilers are you using? I've tried decompiler Java code before, and the results weren't as pleasant as I was led to expect.
- Oliver
JessyCute - 23 Mar 2006 02:46 GMT Thank you, everyone. I think I should parse them from the java source file directly. ^^
Ben_ - 23 Mar 2006 07:35 GMT I've been using DJ Java Decompiler.
Oliver Wong - 23 Mar 2006 17:16 GMT > I've been using DJ Java Decompiler. I think that's one of the decompilers I've tried, but I'll take another look at it. Thanks.
- Oliver
Mike Schilling - 22 Mar 2006 23:47 GMT >I didn't know what particular settings caused it, but it's obvious to me > that the information can be kept. Otherwise, how would a decompiler > produce > code so close to the original ? Also, debuggers know them.
Roedy Green - 23 Mar 2006 02:02 GMT >I didn't know what particular settings caused it, but it's obvious to me >that the information can be kept. Otherwise, how would a decompiler produce >code so close to the original ? It is an illusion. They can of course get the method names and field names bang on because they are embedded in the class file. However, the local variables and parameters are not unless ... (see http://mindprod.com/jgloss/javaclassformat.html)
But if you call the first JButton local in a method jButton it will look very much like the original code, or the original code as it could have been written. I recall reading somebody even used a decompiler to clean up code that had inconsistent local variable names.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Piotr Kobzda - 23 Mar 2006 10:32 GMT >>I didn't know what particular settings caused it, but it's obvious to me >>that the information can be kept. Otherwise, how would a decompiler produce [quoted text clipped - 4 lines] > the local variables and parameters are not unless ... (see > http://mindprod.com/jgloss/javaclassformat.html) No Roedy, it's a reality (the optional reality, that's all...). :)
My simple example (see source code below) produce the following output:
method name=<init>, desc=()V local name=this, desc=Lpiotrk/example/asm/ShowLVT;, index=0 method name=main, desc=([Ljava/lang/String;)V local name=args, desc=[Ljava/lang/String;, index=0 local name=className, desc=Ljava/lang/String;, index=1
It is trivial to guess now what is the parameter name of my main() method, isn't it?
Regards, piotr
 Signature package piotrk.example.asm;
import java.io.IOException;
import org.objectweb.asm.ClassReader; import org.objectweb.asm.Label; import org.objectweb.asm.MethodVisitor; import org.objectweb.asm.commons.EmptyVisitor;
/** * This is a simple example showing how to retrieve Local Variable Table (LVT) * information (including method parameter names) from a class file using * <em>ObjectWeb ASM 2.1</em>. * <p> * <b>Important:</b> To see expected results this should be compiled with * <em>-g:vars</em> option. * * @author piotrk */ public class ShowLVT {
public static void main(String[] args) throws IOException {
String className = ShowLVT.class.getName();
new ClassReader(className) .accept(new EmptyVisitor() {
@Override public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) { System.out.println("method name=" + name + ", desc=" + desc); return this; }
@Override public void visitLocalVariable(String name, String desc, String signature, Label start, Label end, int index) { System.out.println("local name=" + name + ", desc=" + desc + ", index=" + index); }
}, false);
} }
Roedy Green - 23 Mar 2006 17:50 GMT >> It is an illusion. They can of course get the method names and field >> names bang on because they are embedded in the class file. However, >> the local variables and parameters are not unless ... (see >> http://mindprod.com/jgloss/javaclassformat.html) > >No Roedy, it's a reality (the optional reality, that's all...). :) Most of the time if you are decompiling code it won't be your own and at won't have the -g switch to compile it. So most of the time the illusion holds.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Piotr Kobzda - 23 Mar 2006 18:31 GMT >>>It is an illusion. They can of course get the method names and field >>>names bang on because they are embedded in the class file. However, [quoted text clipped - 6 lines] > at won't have the -g switch to compile it. So most of the time the > illusion holds. In other words, it is illusion with exceptions, right? Can not call these exceptions an optional reality?
Regards, piotr
Roedy Green - 23 Mar 2006 22:02 GMT >In other words, it is illusion with exceptions, right? >Can not call these exceptions an optional reality? I don't see any disagreement in what we each have said.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Piotr Kobzda - 24 Mar 2006 00:04 GMT > I don't see any disagreement in what we each have said. Yes, you are right. I missed your advice treating as opponent's comment. Sorry for that.
Regards, piotr
Timbo - 23 Mar 2006 09:48 GMT > I didn't know what particular settings caused it, but it's obvious to me > that the information can be kept. Otherwise, how would a decompiler produce > code so close to the original ? The decompilers I've used didn't produce correct parameter names. They used names like string1, string2 etc, for Strings. I suspect the authors didn't use the same names though because generally their methods were named descriptively.
Piotr Kobzda - 23 Mar 2006 10:46 GMT >> I didn't know what particular settings caused it, but it's obvious to me >> that the information can be kept. Otherwise, how would a decompiler [quoted text clipped - 5 lines] > didn't use the same names though because generally their methods were > named descriptively. It depends on the way you compile your sources. If LVT information (optional) is not included in a class file, it's of course impossible to retrieve it. In the case of its presence decompiler can use it (see example I've just posted to the discussion).
Regards, piotr
Chris Uppal - 23 Mar 2006 12:09 GMT > I didn't know what particular settings caused it, but it's obvious to me > that the information can be kept. Otherwise, how would a decompiler > produce code so close to the original ? Some (all ?) decompilers do use the local variable table if it's present. If not then they fall back to heuristic strategies to try to give moderately sensible names to variables. The DJ decompiler (which you mention down-thread) is actually a graphical front-end to JAD. And JAD does work that way.
BTW: javac has variants of the -g option to include (or not) in the classfile: local variable tables for each method. line number tables for each method. the name of the source file. By default (since 1.4, I think) it includes the last two (to improve exception reporting).
-- chris
Ben_ - 23 Mar 2006 16:50 GMT Thanks for the clarification. :-)
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|