On 2/19/2014 12:37 PM, Phil Race wrote:
>In a small percentage of cases, a serialVersionUID field was added.
> When such a field was added, the serialver computation was checked
for consistency on JDK6 and JDK 8.
I'm rather unsure about adding a serialVersionUID to some of these, eg
RowSorterEvent.
Looks like all the other javax.swing.event Event types have the usual
Swing warning that :-
*Warning:* Serialized objects of this class will not be compatible
with future Swing releases. The current serialization support is
appropriate for short term storage or RMI between applications running
the same version of Swing
I think where ever in Swing you did not see that warning it was
probably an oversight rather
than implying long-term persistence is supported
In other words where ever I see the annotation added I think there's
no harm. I'm more worried
about where I see serialVersionUID added.
So in these cases would be good to have a Swing engineer confirm that
it is so, for example
for the Layout classes which also have a serialVersionUID added. I
don't see how these
on their own are useful.
LayerUI was added recently (JDK 1.7) and I suspect that it was simply
over-looked to
add the warning. So it should also have the annotation rather than the
ID.
But you can ask Alex directly about that (I've cc'ed him)
BTW I just want to note for the record why I presume this is all needed.
@SuppressWarnings("serial") suppresses warnings on Serializable
classes that do not specify a serialVersionUID
However Swing has that note above on almost all of its classes.
So we do not want a serialVersionUID. Instead the serialisable hash
has to be derived from the class
rather than artificially suggesting the serialisable forms will be
compatible across releases.
So this all seems fine, so long as @SuppressWarnings("serial") isn't
suppressing other
warnings that might in fact apply to Swing classes, and so long as
semantics isn't extended in
the future.
In terms of the "serial" lint warning category from javac, either a
serializable class can have a serialVersionUID defined or have an
@SuppressWarnings("serial") annotation. Since javac doesn't understand
the swing serialization disclaimer in the javadoc, I recently added
@SuppressWarnings("serial") to those types:
8032627: Add @SuppressWarnings("serial") to appropriate javax.swing
classes
The work under review now in JDK-8034169: "Fix serial lint warnings in
javax.swing" is a follow-up to that earlier fix.
Note that in general if you want to intentionally break serial
compatibility, you can just change the value of the serialVersionUID. If
a serialVersionUID is defined, the cost of the computing the hash over
the class's information is avoided when an instance of the class is
serialized. In other words, including a serialVersionUID doesn't
necessarily mean long-term serial compatibility. (However, if a
serialVersionUID is omitted, innocuous changes to the class can alter
the hash computation and cause an unnecessary and unwanted break in
serial compatibility.)
A @SuppressWarnings("serial") on a top-level class will also suppress
serial warning on any lexically nested classes declared within the
top-level class, but when that occurred I added a separate
serialVersionUID or @SuppressWarnings("serial") annotation on any
affected nested classes.
Cheers,
-Joe
