<Swing Dev> JDK 9 RFR of JDK-8033221: Fix serial lint warnings in sun.swing.*

[Joe Darcy]

Hello,

On 01/30/2014 11:36 AM, Tom Hawtin wrote:
> On 30/01/2014 13:05, Sergey Bylokhov wrote:
>> It seems to me that in this fix we actually suppress a bugs. These
>> classes can be extended from the public classes, and can be assigned to
>> the parent.
>> If serialization of these classes are not supported, we should block it
>> via readObject+writeObject with assertion error, if it is supported it
>> should be implemented.
>
> + readObjectNoData. Correctly spelt serialPersistenFields as an array 
> containing null appeared to be most effective, though implementation 
> dependent.
>
> Really the legacy serialisation mechanism should be extended with a 
> @NotActuallySerializable annotation. Apply that to sun.swing.-, 
> com.sun.swing.-, javax.swing.- and others.
>
> Tom
>

Especially for the JDK, javac should be a first-line static analysis 
tool to help find and prevent problems. Since the JDK can use a version 
of the Java language not supported anywhere else (while a feature 
release is in development), javac may be the only such static tool 
available.

In my estimation, we are being hampered by not being able to use javac 
in this capacity to a greater degree in the JDK build.

For example, during JDK 8 I pushed a fix for

     JDK-8021109 Add serialVersionUID to LambdaConversionException.java

Another engineer had added an exception type and forgot to add a 
serialVersionUID (since all exception types are serializable, thanks 
RMI!). I've made this sort of omission myself and had to correct it 
later; this sort of omission would be kicked out immediately if the 
serial javac lint warning was enabled during the build.

I am not a client engineer by training or inclination, but in JDK 9, 
I've been working on clearing the client libraries of lint and doclint 
warnings [1] to help complete the larger effort of clearing the jdk 
repository of such warnings, a stated goal for JDK 9 [2]. As a result, 
hundreds of lint warnings have been removed and three additional lint 
warning categories have been enabled in the build of the jdk repo so far 
in JDK 9 [3]. The serial warning is the lint category I'm currently 
working on.

Many of the files I've been modifying haven't been updated for a decade 
or more and didn't seem likely to be updated absent a cleanup effort. I 
would welcome (and actually prefer!) more direct involvement from 
engineers with experience in the client code in the effort of clearing 
warnings in that code.

If a more comprehensive update to the serialization status of the sun.* 
libraries is in order, I in no way oppose that. But, the better is the 
enemy of the good, and in the mean time I think we need a JDK build that 
is clean on javac lint warnings.

Cheers,

-Joe

[1]
JDK-8033221     Fix serial lint warnings in sun.swing.*
JDK-8032733     Fix cast lint warnings in client libraries
JDK-8032627     Add @SuppressWarnings("serial") to appropriate 
javax.swing classes
JDK-8032616     Fix non-deprecation warnings in com.sun.beans.*
JDK-8032047     Fix static lint warnings in client libraries
JDK-8031736     Fix doclint issue in javax.print
JDK-8031589     Fix doclint issues in java.beans.beancontext
JDK-8031550     Fix overloads lint warnings in client code
JDK-8031467     Fix doclint missing issues in java.awt.{dnd[.peer], 
datatransfer}
JDK-8031082     Fix non-missing doclint problems in client libraries
JDK-8030845     Fix doclint missing issues in java.awt.event

[2] 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000141.html

[3]
JDK-8032734: Add cast lint warning to build of jdk repository
JDK-8032048: Add static lint warning to build of jdk repository
JDK-8031747: Add overloads lint warning to build of jdk repository