-
Bug
-
Resolution: Fixed
-
P3
-
5.0
-
b42
-
generic
-
generic
ReentrantReadWriteLock defines two serializable inner classes, ReadLock and
WriteLock. Because these classes are non-static, their serialized forms
include fields named "this$0" that reference the enclosing
ReentrantReadWriteLock instance. The choice of name is an implementation
detail of Sun's javac, and hence presents an obstacle to serialization
compatibility with classes compiled using a different java compiler, or even a
future release of Sun's javac. (Defining serializable inner classes is
generally discouraged for other reasons as well, as noted in section 1.10 of
the object serialization specification.)
This problem could be resolved by changing ReadLock and WriteLock to be static
nested classes instead. Note that the only opportunity for fixing this problem
is in the tiger timeframe, since these classes are newly introduced--after
tiger, "this$0" will be baked into the serialized form specification for
ReadLock and WriteLock.
WriteLock. Because these classes are non-static, their serialized forms
include fields named "this$0" that reference the enclosing
ReentrantReadWriteLock instance. The choice of name is an implementation
detail of Sun's javac, and hence presents an obstacle to serialization
compatibility with classes compiled using a different java compiler, or even a
future release of Sun's javac. (Defining serializable inner classes is
generally discouraged for other reasons as well, as noted in section 1.10 of
the object serialization specification.)
This problem could be resolved by changing ReadLock and WriteLock to be static
nested classes instead. Note that the only opportunity for fixing this problem
is in the tiger timeframe, since these classes are newly introduced--after
tiger, "this$0" will be baked into the serialized form specification for
ReadLock and WriteLock.