java internal method signature doesn't match constructor parameters (javap)

Question

I have the following class containing local inner class:

class Outer {
    private boolean beep;
    private int foo;

    public Outer(boolean beep) {
        this.beep = beep;
    }

    public void start(boolean beep) {
        class LocalInner {
            private LocalInner() {

            }
            public void method() {
                System.out.println("Test.");
                if (beep) {
                    System.out.println("beeping.");
                }
            }
        }

        LocalInner li = new LocalInner();
        li.method();
    }
}

When I compile the class javac Outer.class, and then check compiled members of Outer$1LocalInner with javap -private Outer\$1LocalClass.class, I get this:

class Outer$1LocalInner {
  final boolean val$beep;
  final Outer this$0;
  Outer$1LocalInner();
  public void method();
}

I was expecting that the constructor will be compiled to: Outer$1LocalInner(Outer, boolean). When I tried to have a look at the byte code javap -c -s -private Outer$1LocalInner.class I got this:

class Outer$1LocalInner {
  final boolean val$beep;
    descriptor: Z
                                                                                                         
  final Outer this$0;
    descriptor: LOuter;
                                                                                                         
  Outer$1LocalInner();
    descriptor: (LOuter;Z)V
    Code:                    
       0: aload_0   
       1: aload_1
       2: putfield      #1                  // Field this$0:LOuter;   
       5: aload_0
       6: iload_2
       7: putfield      #2                  // Field val$beep:Z
      10: aload_0                                                                                        
      11: invokespecial #3                  // Method java/lang/Object."<init>":()V
      14: return 
                                                                                                         
...
}

Now this is rather interesting! Let's have a closer look at these two lines:

  Outer$1LocalInner();
    descriptor: (LOuter;Z)V

1. Why is there no parameters to Outer$1LocalInner() constructor, yet I can see in the method descriptor that it does accept two parameters as I'm expecting Outer and boolean?

2. Why does the compiler ignores the access modifier of the local inner class? I'm declaring it as private, yet the disassembled version is package modifier.

Answer 1

It’s seems, javac generates a Signature Attribute:

A Signature attribute stores a signature (§4.7.9.1) for a class, interface, constructor, method, field, or record component whose declaration in the Java programming language uses type variables or parameterized types.

This purpose doesn’t match the scenario, as this local class does use type variables or parameterized types, but we can show that the behavior of javap matches.

E.g., when we run javap -s java.util.function.Supplier, we get

Compiled from "Supplier.java"
public interface java.util.function.Supplier<T> {
  public abstract T get();
    descriptor: ()Ljava/lang/Object;
}

showing that javap prints the method declaration as seen by the generic type system while printing the descriptor as used by the JVM is the second line. Which implies that is uses the information from the Signature attribute when printing the method declaration.

We can even force javap to print the Signature attribute.
Using javap -v java.util.function.Supplier:

[class declaration and constant pool omitted]
  public abstract T get();
    descriptor: ()Ljava/lang/Object;
    flags: (0x0401) ACC_PUBLIC, ACC_ABSTRACT
    Signature: #8                           // ()TT;
}
Signature: #9                           // <T:Ljava/lang/Object;>Ljava/lang/Object;
SourceFile: "Supplier.java"
RuntimeVisibleAnnotations:
  0: #13()
    java.lang.FunctionalInterface

Note the line Signature: #8 // ()TT;

When I run javap -p -v my.test.Outer$1LocalInner with your example, I get

…
  private my.test.Outer$1LocalInner();
    descriptor: (Lmy/test/Outer;Z)V
    flags: (0x0002) ACC_PRIVATE
    Code:
      stack=2, locals=3, args_size=3
         0: aload_0
         1: aload_1
         2: putfield      #1                  // Field this$0:Lmy/test/Outer;
         5: aload_0
         6: iload_2
         7: putfield      #7                  // Field val$beep:Z
        10: aload_0
        11: invokespecial #11                 // Method java/lang/Object."<init>":()V
        14: return
      LineNumberTable:
        line 31: 0
        line 33: 14
    Signature: #16                          // ()V
…

which is consistent with the theory that the method has a Signature attribute reporting ()V which leads to javap printing a declaration with no parameters.

Using this attribute for encoding the constructor’s source code appearance, even when it is not using type variables or generic types, has not been mentioned as a purpose of this attribute and Eclipse’s compiler does not generate such an attribute.

Note that the documentation also says:

Oracle's Java Virtual Machine implementation does not check the well-formedness of Signature attributes during class loading or linking. Instead, Signature attributes are checked by methods of the Java SE Platform class libraries which expose generic signatures of classes, interfaces, constructors, methods, and fields.

So the presence or absence of this attribute has no direct impact on the execution of the code. But when I append the following code to the end of your start method

try {
    Constructor<?> c = li.getClass().getDeclaredConstructor(Outer.class, boolean.class);
    System.out.println(Arrays.asList(c.getParameterTypes()));
    System.out.println(Arrays.asList(c.getGenericParameterTypes()));
} catch(ReflectiveOperationException ex) {}

it prints

[class my.test.Outer, boolean]
[class my.test.Outer, boolean]

when compiled with Eclipse and

[class my.test.Outer, boolean]
[]

when compiled with javac, showing that getGenericParameterTypes() interprets this Signature attribute.

---

All tests above where made with JDK 17. Since JDK 11, the outer class can access the private constructor directly and therefore, the constructor declared as private is compiled as private.

Prior to JDK 11, the private modifier gets removed for a local class. This is different from nonlocal nested classes, where javac keeps the private modifier and generates another non-private delegating constructor.

Answer 2

1. Trust the descriptor. It's possible that javap isn't expanding the ctor parameters in the line above because it understands that this is an inner class and that the source code had no such special parameters declared.
2. This might depend on the Java version that you compiled against. Java 11 supports nestmates, and so it doesn't need to downgrade to package-private modifiers.