>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
