On 02/16/2014 11:12 AM, Alan Bateman wrote:
On 14/02/2014 04:00, Joe Darcy wrote:
If a superclass had the standard swing serialization disclaimer, I
put @SuppressWarning("serial") on its subclasses. This covered most
of the cases. If one of the non-transient fields had teh swing
disclaimer, I added a note that that effect, and if the class was
neither public nor protected, I generally added a "JDK-implementation
class" disclaimer.
For exception types, types not meeting the criteria above (especially
if they haven't been modified in many years), I added a SUID, but
those cases were relatively few.
Hope this explanation helps; thanks for the review,
Yes, this explains it but I just wonder about two cases.
javax.swing.event.RowSorterEvent. You've added a SUID and that looks
right but I see that all the other events in this package have the
disclaimer and so I wonder if maybe this class should have a
disclaimer and @SW.
In that case, both the Event classes extend a class in java.util which
has a SUID. However, TreeSelectionEvent.java has fields with type
TreePath and TreePath has the swing same-version-only serialization
contract so I added @SuppressWarnings("serial") to that class. In
RowSorterEvent, the two fields are an int and an enum, both of which are
serializable so I added a SUID instead.
The other one is javax.swing.plaf.metal.MetalComboBoxIcon as most of
the other types in this package have the disclaimer + @SW.
MetalComboBoxIcon hasn't changed in a long time, doesn't actually
declare any fields, and doesn't extend any problematic classes, so I
thought it was reasonable to add a SUID.
The other updated types in this package generally extend a class that
has the swing serialization policy so on that basis they get a
@SuppressWarnings("serial").
Thanks for the careful review,
-Joe
