Ya got String, got StringBuffer - and now ya got StringBuilder!

Welcome Herb.

What's the rationale for this new StringBuilder thing? Is StringBuffer that inefficient?

StringBuffer is synchronized; StringBuilder is not.

-j-

Being non-synchronized make StringBuilder be more efficient than StringBuffer. StringBuilder is a replacement for the thread-safe StringBuffer class. It works much faster as it has no synchronized methods. So, if we are doing lots of String operations in a single thread, we will surely gain a lot of performance when using StringBuilder class...

Just my $0.02...

StingBuffer is like Vector. Most of the time the synchronization is unnecessary; when it is necessary, it's probably at the wrong level. (I.e. you probably need synchronization in a higher-level sync block, if you need it at all.) In most code the difference in performance is probably negligible. However since standard libraries sometimes need to be called many times in a tight loop, it behooves Sun to remover unncessary overhead where possible. Frequently-used library code is often an exception to Hoare's rule about premature optimization. If you've got a library being used by many, many people in many, many different ways, then someone, somewhere, is depending on it to be as fast as possible. So opitimizing it is not premature; it's good practice.

StringBuilder

A mutable sequence of characters. This class provides an API compatible with StringBuffer, but with no guarantee of synchronization. This class is designed for use as a drop-in replacement for StringBuffer in places where the string buffer was being used by a single thread (as is generally the case). Where possible, it is recommended that this class be used in preference to StringBuffer as it will be faster under most implementations.

The principal operations on a StringBuilder are the append and insert methods, which are overloaded so as to accept data of any type. Each effectively converts a given datum to a string and then appends or inserts the characters of that string to the string builder. The append method always adds these characters at the end of the builder; the insert method adds the characters at a specified point.

For example, if z refers to a string builder object whose current contents are "start", then the method call z.append("le") would cause the string builder to contain "startle", whereas z.insert(4, "le") would alter the string builder to contain "starlet".

In general, if sb refers to an instance of a StringBuilder, then sb.append(x) has the same effect as sb.insert(sb.length(), x). Every string builder has a capacity. As long as the length of the character sequence contained in the string builder does not exceed the capacity, it is not necessary to allocate a new internal buffer. If the internal buffer overflows, it is automatically made larger.

Instances of StringBuilder are not safe for use by multiple threads. If such synchronization is required then it is recommended that StringBuffer be used.

But if it is not as good as StringBuffer, why SUN tries to develop a new set of API? :roll:

In fact, are there really any situations that needed non-synchronized string construction?

Nick

In fact, are there really any situations that needed non-synchronized string construction?

Yes of course. If I am creating a StringBuffer object and manipulation it inside of a method , why do I need synchronization.

But if it is not as good as StringBuffer, why SUN tries to develop a new set of API?

Because in many cases it's better than StringBuffer. Did you read the quoted API? It's often faster.

I actually disagree wth the API somewhat here, because I find the synchronization of StringBuffer (and Vector) to be extremely useless in most cases, even if multiple threads are involved. So I recommend StringBuilder more strongly than the API does. Nonetheless, the API does clearly indicate why StringBuilder is good in at least some cases.

In fact, are there really any situations that needed non-synchronized string construction?

No, not if you don't mind your code being slow for no reason. :roll:

As previously stated, in most cases it's not a big issue. Even in cases where performance is an issue, most of your code is not going to be a problem, no matter how inefficient it is. There's usually a bottleneck somewhere else which is more important. But there's often a bottleneck somewhere, and in some cases, that bottleneck is in code that repeatedly accesses a StringBuffer. So it's good that Sun now offers a faster option. You're welcome to ignore it most of the time.

Thankyou all for your responses!
-Barry