Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is StringBuffer methods synchronized

 
Krishna Chhabra
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

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

Regards,
Gaurav
 
Matthew Brown
Bartender
Posts: 4567
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 296
Eclipse IDE Firefox Browser Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 7483
50
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Krishna Chhabra
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually i was in the assumption that whole method should be synchronized and it should be in method declaration like:
 
Matthew Brown
Bartender
Posts: 4567
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1952
7
Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic