Don’t Marshal Inner Classes
Inner classes
aren’t as simple as they appear. When an inner class
is compiled it gains at least one new variable, which is a reference
to the outer class, and it can potentially gain many more, depending
on which local variables are accessed and whether
they’re declared as final. For example, consider the
following class definition which declares an inner class inside the
test
method:
public class InnerClasses {
public static void main(String[] args) {
new InnerClasses( ).test("hello");
}
public void test(final String string) {
class StringPrinter {
public void print( ) {
System.out.println(string);
System.exit(0);
}
}
new StringPrinter().print( );
}
}When you compile this, and then decompile the resulting inner class,[14] you find the following:
class InnerClasses$1$StringPrinter {
private final String val$string;
private final InnerClasses this$0;
InnerClasses$1$StringPrinter(InnerClasses p0, String p1) { }
public void print( ) { }
}The inner class has two “additional” fields. Having automatically generated fields (with automatically generated names) in a class you will marshal is a recipe for disaster—if you don’t know the variable names or types in advance, all you can do is rely on default serialization and hope everything works out. What makes it even worse in this case is that the names of the fields aren’t part of the Java specification (the names of the fields depend on the compiler).
[14] The full name of the resulting inner class isn’t specified ...