JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes

[Peter Levart]

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
>