• Post Reply Bookmark Topic Watch Topic
  • New Topic

Where is the inner class naming scheme defined?  RSS feed

 
Josh Rehman
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was wondering where the inner class naming scheme for generated class files is defined (you know, the Outer$Inner.class naming convention - the thing with the dollar sign). I checked both the JLS and the JVMS but couldn't find anything.
Thanks.
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Josh,
I'm pretty sure that that is implementation specific, which means you should not write applications that depend on a particular naming convention for inner classes.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are some specs for this, but Sun has done their best to hide them. :roll: Section 7.15 of the JVM Specification has some info; if you follow the link you learn that the old Inner Classes Specification has been archived, and you can only get it by downloading the complete JDK 1.1.8 docs. If you do that though, you can find the following section from the Inner Classes Spec:
Bytecode names of classes and interfaces
Instances of the Java Virtual Machines, and Java bytecodes, refer to reference types by means of bytecode names which differ in detail from the names used in Java source code. The bytecode name of a package member T is defined as the name of the package, with every `.' replaced by `/', followed (if the package name is not null) by another `/', and then by the simple name of T. The bytecode name of T also serves as a prefix for the bytecode name of every class defined within the body of T.
The bytecode name of a class C which is a non-private member of another class, and which is not contained (directly or indirectly) in any block or private class, is defined as the bytecode name of the immediately-enclosing class, followed by `$', followed by the simple name of C.
All other classes are called inaccessible. No inaccessible class N can ever be referenced by the code of any other compilation unit. Thus, as long as the name of N is chosen by the compiler in such as way as not to conflict with any other class in the same compilation unit, the name will be globally unique, because (as required previously) its prefix is unique to the package member in which it occurs.
For the sake of tools, there are some additional requirements on the naming of an inaccessible class N. Its bytecode name must consist of the bytecode name of an enclosing class (the immediately enclosing class, if it is a member), followed either by `$' and a positive decimal numeral chosen by the compiler, or by `$' and the simple name of N, or else by both (in that order). Moreover, the bytecode name of a block-local N must consist of its enclosing package member T, the characters `$1$', and N, if the resulting name would be unique.
The string produced by the getName method of Class is derived, in all of these cases, from the bytecode name, by replacing `/' by `.'. There is no attempt to "clean up" the name to make it resemble Java source code.

I added bold to the key section. There's no requirement as to how N is chosen; if there's just one inaccessible class, N will probably be 1. Once there's more than one inaccessible class, N will probably be assigned from the sequence 1, 2, 3, ... - but there's no guarantee as to what order the names will be assigned in.
 
Josh Rehman
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jim,
Thanks so much! I had read that section but didn't think it worthwhile to actually download the 1.1.8 spec. Foolish me. You rock.
Josh
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!