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

[Roger Riggs]

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
>>
>