Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / March 2006

Tip: Looking for answers? Try searching our database.

Anyone know how to get parameter name?

Thread view: 
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 Magazines

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

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.