String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.
The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.
append
public StringBuffer append(StringBuffer sb)
Appends the specified StringBuffer to this sequence.
The characters of the StringBuffer argument are appended, in order, to the contents of this StringBuffer, increasing the length of this StringBuffer by the length of the argument. If sb is null, then the four characters "null" are appended to this StringBuffer.
Let n be the length of the old character sequence, the one contained in the StringBuffer just prior to execution of the append method. Then the character at index k in the new character sequence is equal to the character at index k in the old character sequence, if k is less than n; otherwise, it is equal to the character at index k-n in the argument sb.
This method synchronizes on this (the destination) object but does not synchronize on the source (sb).
Parameters:
sb - the StringBuffer to append.
Returns:
a reference to this object.
Since:
1.4
Thanks & Regards, Sumeet
SCJP 1.4, SCWCD 5, LinkedIn Profile
Krishna Chhabra wrote:Thanks for the clarification but i was looking at the below link and found none of the method as synchronized....am i missing something...
String Buffer
Krishna Chhabra wrote:Thanks for the clarification but i was looking at the below link and found none of the method as synchronized....am i missing something...
String Buffer
Krishna Chhabra wrote:Actually i was in the assumption that whole method should be synchronized and it should be in method declaration
Junilu Lacar wrote:
I may be wrong but I don't think that the JavaDoc tool even bothers to pick up on the synchronized keyword in a method declaration. Besides, synchronization can also be achieved from inside a method so even if JavaDoc did in fact pick up the synchronized in the method declaration, the absence of the keyword from the method JavaDoc would not necessarily mean that it's not thread-safe. It's really the responsibility of the author of a class to properly document thread-safety in JavaDocs. I like to call out things like that by putting "IMPLEMENTATION NOTE:" in front of the text that talks about thread-safety or lack thereof.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Jelle Klap wrote:
I'd like to see the JCIP annotations become a standard part of the Java API, maybe in the java.util.concurrent namespace, and have the JavaDoc tool be able to process them.
E Armitage wrote:
Jelle Klap wrote:
I'd like to see the JCIP annotations become a standard part of the Java API, maybe in the java.util.concurrent namespace, and have the JavaDoc tool be able to process them.
I don't think that implementation details should be in the spec. I also don't agree that those annotations should be part of the standard API unless if the compiler or JVM can process them to confirm their intentions.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Jelle Klap wrote:
A class' thread-safety guarantees are absolutely not a mere implementation detail.
E Armitage wrote:
Jelle Klap wrote:
A class' thread-safety guarantees are absolutely not a mere implementation detail.
Why? It's not what the class is/does (specs) it's how (implementation) it does what it does.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Don't get me started about those stupid light bulbs. |