aspose file tools*
The moose likes Java in General and the fly likes Is StringBuffer methods synchronized Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Is StringBuffer methods synchronized" Watch "Is StringBuffer methods synchronized" New topic
Author

Is StringBuffer methods synchronized

Krishna Chhabra
Greenhorn

Joined: May 15, 2007
Posts: 9
Hi,

Can anyone please explain that how we can say that StringBuffer is thread safe ....

Regards,
Gaurav
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4363
    
    8

Have you read the documentation for that class? (Click on the link in your post). This is from the second paragraph:
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.
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
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.
Krishna Chhabra
Greenhorn

Joined: May 15, 2007
Posts: 9
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
Sumit Patil
Ranch Hand

Joined: May 25, 2009
Posts: 296

Javadocs for rescue.
Edit : I am too late to reply

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
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
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

Javadocs are specs and synchronizing is an implementation issue so synchronize should not be in the specs/javadocs. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4214145
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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


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.



Junilu - [How to Ask Questions] [How to Answer Questions]
Krishna Chhabra
Greenhorn

Joined: May 15, 2007
Posts: 9
Actually i was in the assumption that whole method should be synchronized and it should be in method declaration like:
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4363
    
    8

Krishna Chhabra wrote:Actually i was in the assumption that whole method should be synchronized and it should be in method declaration

It can be, and if you look at the source code for StringBuffer you'll find it is. But, as already mentioned, that isn't included in the Javadocs because it's an implementation detail.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1760
    
    7

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.


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.


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.
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
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.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1760
    
    7

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.


A class' thread-safety guarantees are absolutely not a mere implementation detail.
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
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.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1760
    
    7

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.


Implementation details usually don't break client code when they're changed; in order to be used safely in a multi-threaded context, client code must know about a class' thread-safety guarentees, or lack thereof.
Unfortunately, there's no way to infer these guarentees by looking at a class' public API, so they must be documented explicitly, the JCIP-style annotations could help to do just that.

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Is StringBuffer methods synchronized