the following email excerpt documents the problem:

...
A number of inner (nonstatic nested) classes in JDK are documented as
serializable. All of them use the default serialized form. That is,
they do not provide both readObject and writeObject methods.
Consequently, their documented serialized form depends on details of
the compiler implementation. Specifically, they depend on and document
the presence and position of the field this$0 (or, in one case,
this$1).

There are a number of problems with this. First, the serialization
implementation is not portable among different java compilers, because
different java compilers are free to implement inner classes using
different techniques. (The implementation of inner classes is a
contract between the compiler and itself, and doesn't have any fixed
specification) Second, and more serious, the implementation for inner
classes will almost certainly not be portable to our own implementation
in the next (that is, Tiger) release as we are planning to add support
in the VM for inner classes. Third, and more immediate, the new
implementation of javadoc (which has not yet been integrated) does not
document this$0 or any other compiler-generated fields.

A number of solutions to this dilemma are possible. First, javadoc
should produce a warning when it produces the serialized form page for
an inner class if the class does not provide both readObject and
writeObject methods. That is only a half-measure, because most javadoc
warnings are apparently ignored. Perhaps a fatal error would be
better? Second, all affected classes should be rewritten so that
their serialized form is not compiler-specific. The simplest way to
do that is to make them static nested classes instead of inner classes
and make an explicit field (perhaps called this$0) for the enclosing
class.
...