for In . Instead, they contain a variable In that contains the name Out$In of a file
drawer. This name is chosen to indicate where the file drawer for class In really
belongs —inside objects of class Out . As can be seen, drawer Out$In contains
the contents of all of In 's drawers in the inner-class view. Note that the name of
the class in each instance is given as the name of the file drawer.
In the flattened view, we have lost the information that instance a1 occurs
not only within In 's file drawer but also within instance a0 . To recover this infor-
mation, each instance of In has a “scope box”, which contains this information.
The two objects of class In , a1 and a3 , both contain a scope box.
Finally, the flattened view does not contain the information that each draw-
er of In is contained in Out 's file drawer. To recover this information, we place
a scope box in the upper right corner of In 's file drawer.
The question may arise whether the flattened view is really a suitable model
of memory for inner classes. To convince yourself that it is, simply convince
yourself that you can unambiguously create the flattened view from the original
view and the original view from the flattened view. If this is the case, they have
the same information, and either view can be used.
Java uses essentially the flattened view for inner classes. You can see this for
yourself. Start your IDE and set it to create a folder of the compiled classes
instead of a jar file. In the folder of compiled classes you will see a file
Out$1.class , which contains the information about inner class In . We have
chosen the name Out$In instead of Out$1 to make it more understandable.
Out 's file drawer
In 's drawer, named Out$In
The flattened view of an inner class