New protocol for disabling exception suppression

[Joe Darcy]

The suppressedExceptions field is initialized to a nonnull value.  The 
new constructor can set the field to null.  The readObject method 
accesses the field on the reconstituted object; readObject does not need 
to be synchronized.  Both the addSuppressed and getSuppressed methods 
are synchronized (as well as final).

There are no other access to this private field in Throwable.

Therefore, I see no thread-safety issues around the suppressedExceptions 
field in the current implementation.

-Joe

Neal Gafter wrote:
> Good point.  I missed that.
>
> -Neal
>
> On Sun, Apr 3, 2011 at 1:21 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
>
>   
>> On 04/03/2011 10:11 PM, Neal Gafter wrote:
>>
>>     
>>> ArrayList.add is used to add suppressed exceptions but that is not
>>> thread-safe.
>>>
>>>       
>> but ArrayList.add() is done under a monitor on this or in readResolve ??
>>
>> Rémi
>>
>>
>>  On Sunday, April 3, 2011, Rémi Forax<forax at univ-mlv.fr>  wrote:
>>     
>>>> On 04/03/2011 05:43 PM, Neal Gafter wrote:
>>>>
>>>>         
>>>>> The mechanism for adding suppressed exceptions does not appear to be
>>>>> thread-safe.
>>>>>
>>>>>           
>>>> Why do you claim that ?
>>>> It's thread-safe like initCause is thread-safe.
>>>>
>>>>  Since this introduces a way in which exceptions used to
>>>>         
>>>>> be thread-safe but no longer are thread-safe, this might require
>>>>> significant nonlocal refactoring of existing code in order to use the
>>>>> new try-with-resources statement.
>>>>>
>>>>>           
>>>> Exceptions are still thread-safe.
>>>>
>>>> Rémi
>>>>
>>>>
>>>>
>>>>
>>>>         
>
>