Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads

Doug Lea dl at
Thu Jun 21 16:15:37 UTC 2012

On 06/21/12 11:59, Jim Gish wrote:
> Please review the proposed spec change to StringBuffer below, which informs the
> user about additional thread safety issues as described in the bug. (Thanks to
> Brian for the language).

Brian: Nice wording! It misses mentioning the constructor
StringBuffer(CharSequence seq) case though.

Perhaps change:
   multiple threads, the source data passed to append/insert, if shared
   multiple threads, the source data passed to create/append/insert, if shared

With this change, the paragraph could also be readily adapted to
also be placed in class java.util.Vector, that infamously has
similar issues. (For which I suspect there is some CR).

... and possibly further adapted  in some other Collection methods
when they are next updated for other reasons.


> Thanks,
> Jim
> diff -r 46ff1b63b0c3 src/share/classes/java/lang/
> --- a/src/share/classes/java/lang/ Mon Jun 11 07:10:48 2012 -0400
> +++ b/src/share/classes/java/lang/ Thu Jun 21 11:45:51 2012 -0400
> @@ -63,6 +63,14 @@
> * appending or inserting from a source sequence) this class synchronizes
> * only on the string buffer performing the operation, not on the source.
> * <p>
> + * While StringBuffer is designed to be safe to use concurrently from
> + * multiple threads, the source data passed to append/insert, if shared
> + * across threads, must ensure that StringBuffer.add/insert has a
> + * consistent and unchanging view of the source data for the duration of
> + * the operation. This could be done by the caller holding a lock during
> + * the add/insert call, or because the source data is immutable, or because
> + * the source data is not shared across threads.
> + * <p>
> * Every string buffer has a capacity. As long as the length of the
> * character sequence contained in the string buffer does not exceed
> * the capacity, it is not necessary to allocate a new internal

More information about the core-libs-dev mailing list