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
