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
