<Swing Dev> JDK 9 RFR of JDK-8034169: Fix serial lint warnings in javax.swing

[Joseph Darcy]

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