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 to 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. -Doug
Thanks, Jim 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
