Anyone know how to get parameter name?

[JessyCute]

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.toString());
}

System.out.println("\nMethod list:");
for(int i = 0; i < m.length; i ++){
System.out.println("method-" + i + ">" + m.getName() );

System.out.println(m.toString());
}




But it doesn't know what is the parameter name, any one know. Thank you
in advance. ^^

 

[Bart Cremers]

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

 

[Timbo]

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]

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

 

[Piotr Kobzda]

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]

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.

Well, bugger me. I never knew that!

 

[Oliver Wong]

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

 

[Ben_]

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 ?

 

[Roedy Green]

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

 

[Mike Schilling]

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...

 

[Mike Schilling]

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]

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.

 

[JessyCute]

Thank you, everyone.
I think I should parse them from the java source file directly. ^^

 

[Ben_]

I've been using DJ Java Decompiler.

 

[Timbo]

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]

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...).

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/StringV
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

--
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);

}
}

 

[Piotr Kobzda]

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.

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]

Mike Schilling wrote:

[me:]

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...

<grin>

Or any guarantee that the debugging info (local variable tables) will be
present (and correct) if you do manage to open it...

-- chris

 

[Chris Uppal]

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_]

Thanks for the clarification.