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

[Phil Race]

PS I just looked and RowSorterEvent is from 1.6 so is also after the 
warnings were
added. 99% certain its an oversight to be missing ..

Adds more weight to the notion that every last one of these should have
1) The warning text - if its public API
2) The annotation

-phil.

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.
>
>
> -phil.
>
> On 2/18/2014 6:36 PM, Joe Darcy wrote:
>> I've applied the patch the current contents of the client repo:
>>
>>     http://cr.openjdk.java.net/~darcy/8034169.1/
>>
>> The patch applied unchanged except for in file MetalFileChooserUI.java.
>>
>> -Joe
>>
>> On 02/13/2014 10:31 AM, Phil Race wrote:
>>> Hello. I think I must reject this change until it is re-submitted 
>>> against the client repo.
>>> It is NOT approved by the client team for pushing to dev.
>>>
>>> -phil.
>>>
>>> On 2/13/2014 12:00 AM, Joe Darcy wrote:
>>>> Hello,
>>>>
>>>> Please review the largely tedious but straightforward fix for
>>>>
>>>>     JDK-8034169: Fix serial lint warnings in javax.swing
>>>>     http://cr.openjdk.java.net/~darcy/8034169.0/
>>>>
>>>> With the change, all of java.swing and it subclasses compile 
>>>> cleanly with the lint warning enabled.
>>>>
>>>> Generally the serial warnings were address by an 
>>>> @SuppressWarnings("serial") annotation; the annotation included a 
>>>> comment about the justification for the suppressions.
>>>>
>>>> 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.
>>>>
>>>> (Note that the javax.swing.text.html.parser.Element type has 
>>>> actually different serialVersionUIDs on JDK 6 and 8.)
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>
>>
>