Hi Martin,
On 10/15/2019 8:02 AM, Martin Buchholz wrote:
On Mon, Oct 14, 2019 at 10:48 PM Joe Darcy <joe.da...@oracle.com
<mailto:joe.da...@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
