Comment Custom bug detector I wrote for FindBugs last week (Score 2, Interesting) 157
As an example of turning bug instances into bug patterns, I always read through the list of bugs fixed in each version of the jdk1.6.0 builds. In build 89, a bug was fixed in the serialization of ArrayBlockingQueue.
I wrote a FindBugs bug detector to look for similar cases: a class with transient fields, but no readObject or readResolve method to restore the field. I had to tune the detector a bit (for example, raise the priority if it is set to a non-default value in the constructor). I'm still doing some tuning, but at the moment the new detector reports warnings in 47 jdk 1.6 b89 classes, 18 of which are confirmed to be bugs. This took me a total of 5 hours of work.
Bugs listed below (these have been reported to Sun); this detector isn't in the current 1.0 release of FindBugs, but is available is the latest CVS snapshot, and will be in the next release.
Bill Pugh
-----
java.security.Timestamp and java.security.CodeSigner:
they have a transient myhash field used to cache the hashCode that is
initialized to -1. If you serialize/deserialize one of these
and invoke hashCode on the result, you'll get an incorrect hashCode of 0.
javax.management.AttributeList
has a transient boolean field tainted. If you add something other than an Attribute
to an AttributeList, serialize/deserialize it, and then invoke asList(), you get back
a List that contains something that isn't an Attribute. If you call asList() on
the original AttributeList, you get an exception.
javax.management.relation.RoleList
javax.management.relation.RoleUnresolvedList
problems isomorphic to the above problem
sun.util.BuddhistCalendar
has a transient field yearOffset that is initialized in the constructor. If you
serialize/deserialize a BuddhistCalendar, you get back a broken BuddhistCalendar
that computes dates incorrectly (off by 543 years)
javax.swing.DefaultDesktopManager
has a transient field floatingItems that is initialized to an empty array of Rectangles, and
it sure looks like the code is assuming that floatingItems is assumed to be nonnull, so
if you serialize/deserialize it, it will be broken (of course, I can never be sure if
anybody seriously intends for awt/swing objects to be serialized.
com.sun.rowset.CachedRowSetImpl
com.sun.rowset.FilteredRowSetImpl
com.sun.rowset.JdbcRowSetImpl
com.sun.rowset.JoinRowSetImpl
com.sun.rowset.WebRowSetImpl
com.sun.rowset.internal.CachedRowSetReader
com.sun.rowset.internal.CachedRowSetWriter
com.sun.rowset.internal.InsertRow
com.sun.rowset.internal.SyncResolverImpl
com.sun.rowset.internal.WebRowSetXmlReader
com.sun.rowset.internal.WebRowSetXmlWriter
com.sun.rowset.providers.RIOptimisticProvider
all initialize in their constructors transient fields pointing to resource bundles
for providing localized error messages, and the resource bundle will be null if the
an object is deserialized and serialized.
javax.smartcardio.CommandAPDU
has 3 transient fields (nc, ne and dataOffset) that are computed by the call to parse in the constructor
from the apdu array. However, if the object is serialized/deserialized, the fields will have their
default values.
I wrote a FindBugs bug detector to look for similar cases: a class with transient fields, but no readObject or readResolve method to restore the field. I had to tune the detector a bit (for example, raise the priority if it is set to a non-default value in the constructor). I'm still doing some tuning, but at the moment the new detector reports warnings in 47 jdk 1.6 b89 classes, 18 of which are confirmed to be bugs. This took me a total of 5 hours of work.
Bugs listed below (these have been reported to Sun); this detector isn't in the current 1.0 release of FindBugs, but is available is the latest CVS snapshot, and will be in the next release.
Bill Pugh
-----
java.security.Timestamp and java.security.CodeSigner:
they have a transient myhash field used to cache the hashCode that is
initialized to -1. If you serialize/deserialize one of these
and invoke hashCode on the result, you'll get an incorrect hashCode of 0.
javax.management.AttributeList
has a transient boolean field tainted. If you add something other than an Attribute
to an AttributeList, serialize/deserialize it, and then invoke asList(), you get back
a List that contains something that isn't an Attribute. If you call asList() on
the original AttributeList, you get an exception.
javax.management.relation.RoleList
javax.management.relation.RoleUnresolvedList
problems isomorphic to the above problem
sun.util.BuddhistCalendar
has a transient field yearOffset that is initialized in the constructor. If you
serialize/deserialize a BuddhistCalendar, you get back a broken BuddhistCalendar
that computes dates incorrectly (off by 543 years)
javax.swing.DefaultDesktopManager
has a transient field floatingItems that is initialized to an empty array of Rectangles, and
it sure looks like the code is assuming that floatingItems is assumed to be nonnull, so
if you serialize/deserialize it, it will be broken (of course, I can never be sure if
anybody seriously intends for awt/swing objects to be serialized.
com.sun.rowset.CachedRowSetImpl
com.sun.rowset.FilteredRowSetImpl
com.sun.rowset.JdbcRowSetImpl
com.sun.rowset.JoinRowSetImpl
com.sun.rowset.WebRowSetImpl
com.sun.rowset.internal.CachedRowSetReader
com.sun.rowset.internal.CachedRowSetWriter
com.sun.rowset.internal.InsertRow
com.sun.rowset.internal.SyncResolverImpl
com.sun.rowset.internal.WebRowSetXmlReader
com.sun.rowset.internal.WebRowSetXmlWriter
com.sun.rowset.providers.RIOptimisticProvider
all initialize in their constructors transient fields pointing to resource bundles
for providing localized error messages, and the resource bundle will be null if the
an object is deserialized and serialized.
javax.smartcardio.CommandAPDU
has 3 transient fields (nc, ne and dataOffset) that are computed by the call to parse in the constructor
from the apdu array. However, if the object is serialized/deserialized, the fields will have their
default values.
