Unfortunately, I had to regenerate the corrected form of the changes:
http://cr.openjdk.java.net/~darcy/8034169.2/
http://cr.openjdk.java.net/~darcy/8034169.2/jdk.patch
With this patch, javax.swing.* compiles without serial lint warnings.
This should be the last large patch needed to get the build of the jdk
repo completely free of serial warnings :-)
Thanks,
-Joe
On 03/13/2014 12:01 PM, Joseph Darcy wrote:
Phil,
Hmmm. I must have mis-generated the webrev. Let me give it another try.
Sorry for the mix-up,
-Joe
On 3/13/2014 11:52 AM, Phil Race wrote:
Joe,
When I open up the patch
http://cr.openjdk.java.net/~darcy/8034169.1/jdk.patch
and search I see multiple new serialVersionUIDs.
Did you miss updating these or do I misunderstand you ?
-phil.
On 3/10/14 9:42 PM, Joe Darcy wrote:
Hello,
I've generated a new version of the webrev:
http://cr.openjdk.java.net/~darcy/8034169.1
Compared to the earlier version, this one exclusively uses
@SuppressWarnings("serial") rather than adding serialVersionUID
fields and it has been updated to account for changes made in the
client libraries since the earlier version was sent for review.
Thanks,
-Joe
On 02/19/2014 04:31 PM, Joseph Darcy wrote:
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.
There are about 23 cases in this patch where a serialVersionUID was
added in lieu of a @SuppressWarnings("serial") annotation.
If the swing team can provide a definitive ruling, I'm happy to
swap these out to be annotations instead.
Thanks,
-Joe
