Hi Peter,
Good observation. Adding transient would negate on of the conditions for
warning, so no warning.
And there would be no need to look at the static types more closely.
If the Ser proxy were for a non-serializable type that would be a good
option.
I think there's a different problem with the chrono/Ser type that
complicates that case.
More about that on the thread... 8231314: java.time serialization
warning cleanup
Thanks, Roger
On 9/23/19 3:23 AM, Peter Levart wrote:
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
