.class file contains no variable names although setting to create those is activated

Question

I try to find the reason for a strange effect with .class files. It seems like for interfaces the names of variables passed into a function are not listed, but in implementation classes they are. I stumbled across this effect while de-compiling some of my own class files with JD-Gui.

I checked this with these two files:

Person.java

public interface Person {
    public abstract void setName( String name );
    public void setAge( int age );
}

PersonImpl.java

public class PersonImpl implements Person {
    @Override
    public void setName(String name) {
        System.out.println("This is my name: " + name);
    }
    @Override
    public void setAge(int age) {
        System.out.println("This is my age: " + age);
    }
}

JD-Gui returns this when decompiling:

Using javap -verbose x.class I get similar results: the printed method signatures differ from interface to implementing class. One misses variable names like I specified them in my source, the other has them.

I tried to answer my question studying the Java Virtual Machine Specification but have to admit I failed finding my way through this document.

Is there a reason why this was designed that way ?

Edit:

Because of all the good answers I received I added some lines to my interface and implementation class in order to back the statements from the answer:s

Person.java

default public void yawn(int count) {
        for (int i = 1; i <= count; i++)
            System.out.println("uaaaaah ....");
    }

JD-Gui is able to determine the name of the parameter:

JavaP is able to list it in the LocalVariableTable:

When I add an abstract method to the implementing class and make the whole class abstract (which I need to because it contains one abstract method) ...

PersonImpl.java

public abstract void setPlanet( String planet );

... then JD-Gui fails to decompile this class file. But fortunately javap still is able to dump the file. All methods that are not abstract keep their LocalVariableTable. And the abstract method has a signature but neither Code, nor Lines or even a LocalVariableTable (this was expected)

Answer 1

There is actually nothing within the class file itself that stores the name of the method parameter. If you look at section 4.3.3, you'll see the following definitions for MethodDescriptor:

A method descriptor represents the parameters that the method takes and the value that it returns:

MethodDescriptor:
    ( ParameterDescriptor* ) ReturnDescriptor
A parameter descriptor represents a parameter passed to a method:

ParameterDescriptor:
    FieldType

A return descriptor represents the type of the value returned from a method. It is a series of characters generated by the grammar:

ReturnDescriptor:
    FieldType
    VoidDescriptor

VoidDescriptor:
    V

The character V indicates that the method returns no value (its return type is void).

You can see this if you print out the bytecode for Person.class and PersonImpl.class using javap -c:

Compiled from "Person.java"
public interface Person {
  public abstract void setName(java.lang.String);

  public abstract void setAge(int);
}

Compiled from "PersonImpl.java"
public class PersonImpl implements Person {
  public PersonImpl();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public void setName(java.lang.String);
    Code:
       0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: new           #3                  // class java/lang/StringBuilder
       6: dup
       7: invokespecial #4                  // Method java/lang/StringBuilder."<init>":()V
      10: ldc           #5                  // String This is my name:
      12: invokevirtual #6                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      15: aload_1
      16: invokevirtual #6                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      19: invokevirtual #7                  // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
      22: invokevirtual #8                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      25: return

  public void setAge(int);
    Code:
       0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: new           #3                  // class java/lang/StringBuilder
       6: dup
       7: invokespecial #4                  // Method java/lang/StringBuilder."<init>":()V
      10: ldc           #9                  // String This is my age:
      12: invokevirtual #6                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      15: iload_1
      16: invokevirtual #10                 // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
      19: invokevirtual #7                  // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
      22: invokevirtual #8                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      25: return
}

You can see that the signature for the method says nothing about the name of the parameter; only its type.

What I suspect is happening is that JD-Gui is probably using some sort of heuristic based on JavaBeans conventions to derive the name of the parameter. Since the name of the method is setName, it assumes that the name of the parameter is name. Try changing the name of the parameter to something other than name and see what JD-Gui prints out.

Debug information, like local variables, will show up if you compile using -g or -g:vars; it does not show up by default. These show up in the LocalVariableTable attribute. From section 4.7.13:

The LocalVariableTable attribute is an optional variable-length attribute in the attributes table of a Code attribute (§4.7.3). It may be used by debuggers to determine the value of a given local variable during the execution of a method.

Notice the optional part; this is why you don't see it by default. Now if you look at section 4.7.3 for the Code attribute:

The Code attribute is a variable-length attribute in the attributes table of a method_info structure (§4.6). A Code attribute contains the Java Virtual Machine instructions and auxiliary information for a method, including an instance initialization method or a class or interface initialization method (§2.9).

If the method is either native or abstract, its method_info structure must not have a Code attribute in its attributes table. Otherwise, its method_info structure must have exactly one Code attribute in its attributes table.

Since interface method-definitions are effectively abstract (unless you use default methods), you won't see a LocalVariableTable entry for them. I used the latest version of JD-Gui against PersonImpl.class that was not compiled with -g, and found that it did not display name and age. Instead it displayed paramString and paramInt just like you saw for Person.class. However, if you do compile it with the -g flag, you will see name and age.

Answer 2

It is due to the method being abstract in an interface. The information about names of method parameters is contained the LocalVariableTable attribute in the bytecode which is present in the Code attribute:

The LocalVariableTable attribute is an optional variable-length attribute in the attributes table of a Code (§4.7.3) attribute.

The Code attribute is defined as follows:

The Code attribute is a variable-length attribute in the attributes table of a method_info (§4.6) structure. A Code attribute contains the Java Virtual Machine instructions and auxiliary information for a single method, instance initialization method (§2.9), or class or interface initialization method (§2.9). Every Java Virtual Machine implementation must recognize Code attributes. If the method is either native or abstract, its method_info structure must not have a Code attribute. Otherwise, its method_info structure must have exactly one Code attribute.

Answer 3

As explained by the other answers, the presence of a LocalVariableTable relies on the presence of a Code attribute and hence isn’t available for abstract methods. Note that Java 8 introduced an attribute for conserving parameter names which works independently to the debugging information. The creation of this attribute must be opted via compile-time flag:

Given your interface:

public interface Person {
    void setName(String name);
    void setAge(int age);
}

> javac Person.java

> javap -v Person
Classfile /C:/Users/pietsch/AppData/Local/Temp/Person.class
  Last modified 11.06.2015; size 159 bytes
  MD5 checksum 2fc084aa2f41b0b98e1417be7faeff8b
  Compiled from "Person.java"
public interface Person
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_INTERFACE, ACC_ABSTRACT
Constant pool:
   #1 = Class              #9             // Person
   #2 = Class              #10            // java/lang/Object
   #3 = Utf8               setName
   #4 = Utf8               (Ljava/lang/String;)V
   #5 = Utf8               setAge
   #6 = Utf8               (I)V
   #7 = Utf8               SourceFile
   #8 = Utf8               Person.java
   #9 = Utf8               Person
  #10 = Utf8               java/lang/Object
{
  public abstract void setName(java.lang.String);
    descriptor: (Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_ABSTRACT

  public abstract void setAge(int);
    descriptor: (I)V
    flags: ACC_PUBLIC, ACC_ABSTRACT
}
SourceFile: "Person.java"

> javac -parameters Person.java

> javap -v Person
Classfile /C:/Users/pietsch/AppData/Local/Temp/Person.class
  Last modified 11.06.2015; size 213 bytes
  MD5 checksum 63dfd86ff035e339baf7b9e9ae65020f
  Compiled from "Person.java"
public interface Person
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_INTERFACE, ACC_ABSTRACT
Constant pool:
   #1 = Class              #12            // Person
   #2 = Class              #13            // java/lang/Object
   #3 = Utf8               setName
   #4 = Utf8               (Ljava/lang/String;)V
   #5 = Utf8               MethodParameters
   #6 = Utf8               name
   #7 = Utf8               setAge
   #8 = Utf8               (I)V
   #9 = Utf8               age
  #10 = Utf8               SourceFile
  #11 = Utf8               Person.java
  #12 = Utf8               Person
  #13 = Utf8               java/lang/Object
{
  public abstract void setName(java.lang.String);
    descriptor: (Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_ABSTRACT
    MethodParameters:
      Name                           Flags
      name

  public abstract void setAge(int);
    descriptor: (I)V
    flags: ACC_PUBLIC, ACC_ABSTRACT
    MethodParameters:
      Name                           Flags
      age
}
SourceFile: "Person.java"

I don’t know whether JD-Gui is capable of using this information.