Hi Joe,
I've been thinking of this example:
83 final class Ser implements Externalizable {
84
...
99 /** The object being serialized. */
100 @SuppressWarnings("serial") // Not statically typed as
Serializable
101 private Object object;
Externalizable does extend Serializable, but the serialization
infrastructure delegates all work to writeExternal/readExternal methods
which implement the (de)serialization logic. They may deconstruct
otherwise non-Serializable objects into Serializable parts before
handing them to ObjectOutputStream / construct otherwise
non-Serializable objects from Serializable parts read from
ObjectInputStream. @SuppressWarnings in such cases is maybe not
suitable. Perhaps the intent would be better expressed by marking the
field as transient. What do you think?
Regards, Peter
On 9/18/19 11:38 PM, Joe Darcy wrote:
Hello,
As background, I'm working on a number of serialization-related
compile-time checks with the goal of enabling stricter javac lint
checking in the JDK build (and elsewhere).
One check is tracked by
JDK-8160675: Issue lint warning for non-serializable non-transient
instance fields in serializable type
As summarized in the bug description, it may be concerning if a
serializable class has non-transient instance fields whose types are
not Serializable. This can cause a serialization failure at runtime.
(Classes using the serialPersistentFields mechanism are excluded from
this check.)
A common example is an exception type -- all Throwable's are
Serializable -- which has a non-serializable field. If the fields
cannot be marked as transient, one approach to handle this robustly is
to have a writeObject method which null outs the field in question
when serializing and make the other methods in the exception
null-tolerant.
In other cases, the object pointed to by the non-serializable field
are conditionally serializable at runtime. This is the case for many
collection types. For example, a class may have a field of type
List<Foo> with the field set to an ArrayList<Foo> at runtime. While
the List interface does not extent Serializable, the ArrayList class
does implement Serializable and the class would serialize fine in
practice, assuming the Foo's were serialazable.
As a precursor to the adding a compile-time check to the build, please
review adding @SuppressWarnings("serial") to document the
non-serializable fields in the core libraries:
JDK-8231202: Suppress warnings on non-serializable non-transient
instance fields in serializable classes
http://cr.openjdk.java.net/~darcy/8231202.0/
Bugs for similar changes to client libs and security libs will be
filed and reviewed separately.
A more complete fix would add readObject/writeObject null handling to
AnnotationTypeMismatchExceptionProxy, but since this hasn't seemed to
be an issue since the type was introduced back in JDK 5.0, I just
added the annotation, as done elsewhere.
Thanks,
-Joe
