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.
The other one is javax.swing.plaf.metal.MetalComboBoxIcon as most of the
other types in this package have the disclaimer + @SW.
-Alan
