JDK 14 RFR of JDK-8232230: Suppress warnings on non-serializable non-transient instance fields in java.util.concurrent

[Joe Darcy]

Hi Martin,

On 10/15/2019 8:02 AM, Martin Buchholz wrote:
>
>
> On Mon, Oct 14, 2019 at 10:48 PM Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Hi Martin,
>
>     On 10/14/2019 10:28 PM, Martin Buchholz wrote:
>>     Hi Joe,
>>
>>     I'm surprised there were so few changes.
>
>
>     The changes in question allow the java.util.concurrent package to
>     pass cleanly through the current version of my checks. Perhaps a
>     strong version of the checks in the future will flag more issues
>     of possible concern ;-)
>
>
>>
>>     Why are some of the Condition's marked // Conditionally serializable
>
>     Summarizing the discussion leading up to the changes for
>     JDK-8231913, "Conditionally serializable" describes collections
>     that are serializable iff their contents are serializable. The
>     changes made for
>
>     8231202: Suppress warnings on non-serializable non-transient
>     instance fields in serializable classes
>     http://hg.openjdk.java.net/jdk/jdk/rev/e036ee8bae56
>
>     use this terminology in the comments added for many collection
>     types, including Vector, TreeMap, and multiple implementation
>     classes in java.util.Collections. I tried to follow the same
>     pattern in java.util.concurrent where appropriate.
>
> The Condition field in ArrayBlockingQueue plays exactly the same role 
> as in e.g. LinkedBlockingQueue, so should have exactly the same treatment.


Changed the comments on the Condition-typed fields to

     // Classes implementing Condition may be serializable.

Revised webrev at:

     http://cr.openjdk.java.net/~darcy/8232230.1/

> ---
> All Condition implementations in OpenJDK are Serializable.
> In fact, we could promote all of those private Condition fields to 
> ConditionObject, making their Serializability clear, and then elide 
> the need for suppression.
>
> private final ConditionObject notEmpty = (ConditionObject) 
> takeLock.newCondition();
>
> (Why won't Java let me declare those fields private final Condition & 
> Serializable ?)
>
> but now we're drifting into actual user-meaningful development...  We 
> promise that ReentrantLock is serializable, but we don't seem to have 
> any such promise for Conditions returned 
> from ReentrantLock.newCondition(), and we probably should.  Users are 
> implicitly relying on the Serializability of Condition in the same way 
> we are.


I've filed JDK-8232359: "Review type of fields in Serializable classes 
of java.util.concurrent" to track this potential future cleanup.


>
> ---
>
> Joe, go ahead and commit this to openjdk head when review is done.  
> We'll incorporate.


Acknowledged; thanks,

-Joe