Java Enterprise Best Practices

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 ...