Nested static class name starting with $
I have seen some codebases where people have wrote nested static classes with names starting with «$» ? What is the significance of that ?
There’s another possible explanation. The code author is obsessed with money. Maybe we should give this convention a name. How about trumping? 🙂
3 Answers 3
There is no significance. $ is a valid character for a java name; there’s nothing special about it.
JLS Chapter 3.8, which defines valid class name characters (more-or-less most «non syntax» characters, first char not a digit) even specifically cautions against this very situation:
The $ sign should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems
This is just a local naming convention, perhaps to remind/indicate to developers that the class is an inner class.
Although it’s a style thing, AFAICT the general consensus of the dev community is to not encode meta data into a name. Other examples I have seen are leading underscores for member variables/parameters, and the awful Hungarian notation.
Try to give things good undecorated names.
People generally haven’t written them themselves; those are usually autogenerated somewhere. From JLS 3.8:
The «Java letters» include uppercase and lowercase ASCII Latin letters A-Z (\u0041-\u005a), and a-z (\u0061-\u007a), and, for historical reasons, the ASCII underscore (_, or \u005f) and dollar sign ($, or \u0024). The $ sign should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems.
The dollar sign is a legitimate character, but it is a very strong convention, on par with using capital letters for class names, not to use it in ordinary code.
A handful of people use it to indicate an inner class, but I personally have never once seen the $ character used for anything that did not also carry the synthetic flag, and I would consider it on par with using Hungarian notation in Java.
Nested Classes
The Java programming language allows you to define a class within another class. Such a class is called a nested class and is illustrated here:
Terminology: Nested classes are divided into two categories: non-static and static. Non-static nested classes are called inner classes. Nested classes that are declared static are called static nested classes.
class OuterClass < . class InnerClass < . >static class StaticNestedClass < . >>
A nested class is a member of its enclosing class. Non-static nested classes (inner classes) have access to other members of the enclosing class, even if they are declared private. Static nested classes do not have access to other members of the enclosing class. As a member of the OuterClass , a nested class can be declared private , public , protected , or package private. (Recall that outer classes can only be declared public or package private.)
Why Use Nested Classes?
Compelling reasons for using nested classes include the following:
- It is a way of logically grouping classes that are only used in one place: If a class is useful to only one other class, then it is logical to embed it in that class and keep the two together. Nesting such «helper classes» makes their package more streamlined.
- It increases encapsulation: Consider two top-level classes, A and B, where B needs access to members of A that would otherwise be declared private . By hiding class B within class A, A’s members can be declared private and B can access them. In addition, B itself can be hidden from the outside world.
- It can lead to more readable and maintainable code: Nesting small classes within top-level classes places the code closer to where it is used.
Inner Classes
As with instance methods and variables, an inner class is associated with an instance of its enclosing class and has direct access to that object’s methods and fields. Also, because an inner class is associated with an instance, it cannot define any static members itself.
Objects that are instances of an inner class exist within an instance of the outer class. Consider the following classes:
An instance of InnerClass can exist only within an instance of OuterClass and has direct access to the methods and fields of its enclosing instance.
To instantiate an inner class, you must first instantiate the outer class. Then, create the inner object within the outer object with this syntax:
OuterClass outerObject = new OuterClass(); OuterClass.InnerClass innerObject = outerObject.new InnerClass();
There are two special kinds of inner classes: local classes and anonymous classes.
Static Nested Classes
As with class methods and variables, a static nested class is associated with its outer class. And like static class methods, a static nested class cannot refer directly to instance variables or methods defined in its enclosing class: it can use them only through an object reference. Inner Class and Nested Static Class Example demonstrates this.
Note: A static nested class interacts with the instance members of its outer class (and other classes) just like any other top-level class. In effect, a static nested class is behaviorally a top-level class that has been nested in another top-level class for packaging convenience. Inner Class and Nested Static Class Example also demonstrates this.
You instantiate a static nested class the same way as a top-level class:
StaticNestedClass staticNestedObject = new StaticNestedClass();
Inner Class and Nested Static Class Example
The following example, OuterClass , along with TopLevelClass , demonstrates which class members of OuterClass an inner class ( InnerClass ), a nested static class ( StaticNestedClass ), and a top-level class ( TopLevelClass ) can access:
OuterClass.java
public class OuterClass < String outerField = "Outer field"; static String staticOuterField = "Static outer field"; class InnerClass < void accessMembers() < System.out.println(outerField); System.out.println(staticOuterField); >> static class StaticNestedClass < void accessMembers(OuterClass outer) < // Compiler error: Cannot make a static reference to the non-static // field outerField // System.out.println(outerField); System.out.println(outer.outerField); System.out.println(staticOuterField); >> public static void main(String[] args) < System.out.println("Inner class:"); System.out.println("------------"); OuterClass outerObject = new OuterClass(); OuterClass.InnerClass innerObject = outerObject.new InnerClass(); innerObject.accessMembers(); System.out.println("\nStatic nested class:"); System.out.println("--------------------"); StaticNestedClass staticNestedObject = new StaticNestedClass(); staticNestedObject.accessMembers(outerObject); System.out.println("\nTop-level class:"); System.out.println("--------------------"); TopLevelClass topLevelObject = new TopLevelClass(); topLevelObject.accessMembers(outerObject); >> TopLevelClass.java
public class TopLevelClass < void accessMembers(OuterClass outer) < // Compiler error: Cannot make a static reference to the non-static // field OuterClass.outerField // System.out.println(OuterClass.outerField); System.out.println(outer.outerField); System.out.println(OuterClass.staticOuterField); >>
This example prints the following output:
Inner class: ------------ Outer field Static outer field Static nested class: -------------------- Outer field Static outer field Top-level class: -------------------- Outer field Static outer field
Note that a static nested class interacts with the instance members of its outer class just like any other top-level class. The static nested class StaticNestedClass can’t directly access outerField because it’s an instance variable of the enclosing class, OuterClass . The Java compiler generates an error at the highlighted statement:
static class StaticNestedClass < void accessMembers(OuterClass outer) < // Compiler error: Cannot make a static reference to the non-static // field outerField System.out.println(outerField); > >
To fix this error, access outerField through an object reference:
System.out.println(outer.outerField);
Similarly, the top-level class TopLevelClass can’t directly access outerField either.
Note: For more information about the taxonomy of the different kinds of classes in the Java programming language (which can be tricky to describe concisely, clearly, and correctly), see Joseph Darcy’s blog: Nested, Inner, Member, and Top-Level Classes.
Shadowing
If a declaration of a type (such as a member variable or a parameter name) in a particular scope (such as an inner class or a method definition) has the same name as another declaration in the enclosing scope, then the declaration shadows the declaration of the enclosing scope. You cannot refer to a shadowed declaration by its name alone. The following example, ShadowTest , demonstrates this:
public class ShadowTest < public int x = 0; class FirstLevel < public int x = 1; void methodInFirstLevel(int x) < System.out.println("x = " + x); System.out.println("this.x = " + this.x); System.out.println("ShadowTest.this.x = " + ShadowTest.this.x); >> public static void main(String. args) < ShadowTest st = new ShadowTest(); ShadowTest.FirstLevel fl = st.new FirstLevel(); fl.methodInFirstLevel(23); >> The following is the output of this example:
x = 23 this.x = 1 ShadowTest.this.x = 0
This example defines three variables named x : the member variable of the class ShadowTest , the member variable of the inner class FirstLevel , and the parameter in the method methodInFirstLevel . The variable x defined as a parameter of the method methodInFirstLevel shadows the variable of the inner class FirstLevel . Consequently, when you use the variable x in the method methodInFirstLevel , it refers to the method parameter. To refer to the member variable of the inner class FirstLevel , use the keyword this to represent the enclosing scope:
Serialization of inner classes, including local and anonymous classes, is strongly discouraged. When the Java compiler compiles certain constructs, such as inner classes, it creates synthetic constructs; these are classes, methods, fields, and other constructs that do not have a corresponding construct in the source code. Synthetic constructs enable Java compilers to implement new Java language features without changes to the JVM. However, synthetic constructs can vary among different Java compiler implementations, which means that .class files can vary among different implementations as well. Consequently, you may have compatibility issues if you serialize an inner class and then deserialize it with a different JRE implementation. See the section Implicit and Synthetic Parameters in the section Obtaining Names of Method Parameters for more information about the synthetic constructs generated when an inner class is compiled.
Mangled nested class namein the Java Language Specification
Obviously, due to inner/nested class name mangling, a$.b and a.$b will both be compiled to a class file named a$$b.class. When the command javac a.java a$.java is executed, the Oracle Java compiler (javac 1.7.0_45) produces the following output:
a$.java:3: error: duplicate class: a.$b public static class b ^ 1 error Where does it say in the Java Language Specification that these class names ( a$.b and a.$b ) clash, or is this just an established convention due to the output files having the same name?
I would presume it says this in whatever section of the JLS deals with name mangling of inner classes and thus defines that behavior. Not having a copy of the JLS, that’s just a guess.
@BrianRoach Not everyone should be reading it, for legal reasons. I need to be a bit more careful than some.
1 Answer 1
6.1 which points to 3.8 which says:
An identifier is an unlimited-length sequence of Java letters and Java digits, the first of which must be a Java letter.
.
The «Java letters» include uppercase and lowercase ASCII Latin letters A-Z (\u0041-\u005a), and a-z (\u0061-\u007a), and, for historical reasons, the ASCII underscore (_, or \u005f) and dollar sign ($, or \u0024). The $ character should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems.
Though really, it’s just a matter of you having a duplicate class name after bytecode generation. The same error would occur with two colliding class names that didn’t involve $ in the source.
Edit to add: The binary format is specified in 13.1