If a nested class contains a reference to a class literal, then the
compiler generates a reference in the nested class to a synthetic
variable in the outermost containing class. The JDK 1.3 compiler put
the synthetic variable in the class containing the reference.

Here's a test case:

public class ClassLiteralInInnerClass {
    static class InnerClass {
Class c = Integer.class;
    }
}

Although the JDK 1.4 behavior makes sense for inner classes, because
inner classes already refer to their enclosing class via this pointers,
the current behavior means that static member classes refer to their
outermost containing class. If a static member class is serializable,
the reference to the synthetic variable means the codebase for the
nested class must include the outermost containing class, a class it
would not otherwise need to provide.

For example:

public interface WhatClass {
    Class whatClass();
}

public class Wrapper {
    static class SendToClient implements Serializable, WhatClass {
        public Class whatClass {
return Integer.class;
        }
    }
    static class UseOnServer { /* ... */ }
}

A programmer might make the SendToClient and UseOnServer classes nested
classes to underline the relationships between them and the Wrapper
class, without intending the nested classes to have runtime dependencies
on the containing class.

If an application serialized an instance of Wrapper.SendToClient, it
would need to make the Wrapper class available in the codebase for the
serialized instance even though the source code for the SendToClient
class does not appear to depend on the Wrapper class.