Inner Classes and Nests

The Actual Detail

One source declaration, six files, and every InnerClasses record decoded from the raw bytes of Inner.class:

  0053: 00 06
        |  +-- SIX records
        +----- SIX nested classes, 8 bytes each

  [0] inner=#7   outer=#0   name=#0   flags=0x0000
      class = Inner$1              <- the ANONYMOUS Runnable
      outer = (none)                name   = (none)
  [1] inner=#18  outer=#0   name=#36  flags=0x0000
      class = Inner$1Local         <- declared INSIDE A METHOD
      outer = (none)                name   = "Local"
  [2] inner=#27  outer=#13  name=#37  flags=0x4018
      class = Inner$E              enum E
      flags = ACC_FINAL ACC_ENUM 0x0008
  [3] inner=#29  outer=#13  name=#38  flags=0x0608
      class = Inner$Iface         interface Iface
      flags = ACC_INTERFACE ACC_ABSTRACT 0x0008
  [4] inner=#31  outer=#13  name=#39  flags=0x0000
      class = Inner$Member         class Member, a non-static inner class
      flags = (none)
  [5] inner=#33  outer=#13  name=#40  flags=0x0008
      class = Inner$Nested         static class Nested
      flags = 0x0008

Five things in that table are each a finding, and two of them contradict what a reader would guess.

The 0x0008 bit, and the third flag table

Records [2], [3] and [5] all carry 0x0008, and 0x0008 is ACC_STATIC. A class cannot be static — top-level classes have no static, and ACC_STATIC in the class flag table means nothing at all.

But these are not classes in the top-level sense. inner_class_access_flags describes a member of a class, so it uses the field/method flag table, not the class one. And a nested enum and a nested interface are both implicitly static, which is a language rule: a nested interface is static because an interface cannot hold instance state, and a nested enum is static because an enum's instances are supposed to be singletons. Record [5] is the explicit case — the source said static class Nested and the bit records exactly that.

Why $1 exists and $1Local is a different thing

Record [0] is the anonymous Runnable, and it is the reason the file is called Inner$1.class. The compiler had to invent a name and recorded nothing:outer_class_info_index = 0 and inner_name_index = 0. A class with no name and no recorded outer class is the file's entire justification for the $1 convention — the number is the only identity an anonymous class has, and it is a counter of anonymous classes within the outer class, starting at 1.

Record [1] is the class declared inside a method, and it is the interesting one: it has a name ("Local") but no outer class recorded. The source was void use() that declares class Local, then news one, so Local is scoped to one method and the compiler emitted Inner$1Local.class — a $1and a name, which is not what either convention predicts on its own.

The numbering scheme behind that name is worth stating because it is entirely implementation-defined and the format does not care:

  Inner$1         the first ANONYMOUS class in Inner
  Inner$1Local    a LOCAL class: $1 because the anonymous Runnable was
                  compiled first, then the simple name
  Inner$Nested    a named nested class: just Outer$SimpleName
  Inner$E         a nested enum: Outer$SimpleName
  Inner$Iface     a nested interface: Outer$SimpleName
  Inner$Member    a non-static inner class: Outer$SimpleName

  the rule javac actually uses: an ANONYMOUS class gets Outer$N where N
  counts anonymous classes; a LOCAL class gets Outer$NLocal where N is
  the counter at the time it was compiled; a NAMED nested class gets
  Outer$SimpleName. All three are conventions, not rules -- nothing in
  the format requires any of them, and every JVM accepts any name.

Which brings up the question the descriptor grammar only hinted at: the $ in LDesc$Nested; is not a nesting marker. It is a legal character in a Utf8 entry, the compiler happens to use it to join an outer and inner name, and a class genuinely named A$B in Java is indistinguishable in the file from a nested class B of A. The method reference in Module 1 makes it concrete — this::id compiles to a synthetic method named lambda$new$0, a $ in the middle of a method name that has nothing to do with nesting. The attribute is the only place the relationship is recorded, which is exactly why it exists.

The nest, and that it is a different set

Now the other two attributes, from the same file, and this is where the sets diverge:

  NestMembers on Inner.class -- 6 entries:
      #27 Inner$E        #29 Inner$Iface     #31 Inner$Member
      #33 Inner$Nested   #18 Inner$1Local    #7  Inner$1

  NestHost on Inner$Nested.class -- ONE u2, no count:
      0010    ->  #16 = Inner

NestMembers lists all six, which is exactly the InnerClasses set. So for this class the two agree — and that is a coincidence of a small example, not a rule. The distinction is what each one is for: InnerClasses says how the compiler named things, NestMembers says who may read whose private fields. A class can be in a nest without being a nested class in the source sense, and the format has no requirement that the lists match.

And note the shape difference once more, because it is the previous concept's point made concrete: NestHost is a bare index with no count, while NestMembers is a counted list. A reader that assumed a common body shape would read NestHost's index as a count and walk into the following attribute. The raw bytes 00 10 are two bytes of body; there is no count anywhere in them.