RFR: 6206780 (str) Forwarding append methods in String{Buffer, Builder} are inconsistent

[Vitaly Davidovich]

Jim, how about an assert with Thread.holdsLock() work for tests?

Sent from my phone
On Oct 2, 2012 9:34 AM, "Jim Gish" <jim.gish at oracle.com> wrote:

> Ok -- I have some comments prepared, so I'll wrap it up with that.
> However, I am curious about suggested approaches for tests to ensure that
> methods are synchronizing properly ( as I mentioned in my message below ).
>
> Thanks,
>    Jim
>
> On 10/02/2012 05:07 AM, Alan Bateman wrote:
>
>> On 01/10/2012 22:22, Jim Gish wrote:
>>
>>> Alan & Chris,
>>>
>>> I agree with you that the new approach is less clear than the previous
>>> approach, but the original approach suffered from code duplication which
>>> was the motivation for the change.  However, let me propose something else.
>>>  How about /all /the methods in StringBuffer be synchronized?  Although
>>> this is not strictly necessary, it works because reentrant synchronization
>>> is allowed.  This eliminates the original problem with code duplication
>>> with the dispatch during the narrowing of types being done in both
>>> StringBuilder and StringBuffer, and also eliminates the confusion about
>>> where synchronization is being done and having to test for it.
>>>
>>> I can still add a test to ensure that all methods of StringBuffer are
>>> synchronized, but that now becomes far easier - I simply can use reflection
>>> on each method and test for isSynchronized().  Having to do invocation
>>> tests to check for blocking or not seems much harder (unless you have a
>>> trick in your bag that I don't yet know).
>>>
>>> Sound reasonable?
>>>
>> As Martin said, it's not free.
>>
>> I think a comment (along the lines of the comments that you removed)
>> would be sufficient to make it clear where the synchronization is done.
>> Alternatively we just close this issue as it's not worth spending a lot of
>> time on it.
>>
>> -Alan.
>>
>>
>>
> --
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.gish at oracle.com
>
>