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.
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.
> diff -r 46ff1b63b0c3 src/share/classes/java/lang/StringBuffer.java
> --- a/src/share/classes/java/lang/StringBuffer.java Mon Jun 11 07:10:48 2012 -0400
> +++ b/src/share/classes/java/lang/StringBuffer.java 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