String and StringBuffer

[honeybee]

Why did Java have these two objects, when the functionality could be combined into just the String object?

.

[Dillinger4]

That is a good question. I dont see why a String of a fixed length
and a StringBuffer would have to seperate. When they could just be combined.

[crptcblade]

Because that is what makes Java so cool. They have specialized classes for different needs. Strings are final and if you change the contents of a String pointer, it has to allocate new memory for the new String.

If you just want to have a String declared to same the same thing over and over, or whatever, then a String is the way to go, but if you are dynamically building a String, then a StringBuffer uses minimal memory and resources to append it.

[Dillinger4]

I think what it comes down to is optimization for the compiler since a string is immutable.

[honeybee]

So, in short it's like this:

If you are going to use a string value in your code which will not change (mainly in size/length), then you can use a String object. But if the string value is going to change in size/length, you should use the StringBuffer object, as it makes efficient use of memory in allocating/freeing space for the changing size.

Then why not just have the StringBuffer object instead of both? Surely, if the StringBuffer object handles memory more efficiently in case of dynamically constructed strings, there is no reason why it would not do so for fixed-length strings.

And although I don't like Java much, please don't take these questions as anti-Java. I am curious to the brink of being suspicious and want to know exactly how it works, and why it works as it works.

.

[filburt1]

String has a s***load of methods and functions for it: http://java.sun.com/j2se/1.3/docs/ap...ng/String.html

[Dillinger4]

Java permits you to create a String from an existing StringBuffer
and create a StringBuffer from an existing String through their constructors but you can only change a StringBuffer to a String on the fly by implementing the overridden toString() method. I dont think there is a toStringBuffer() method so you would have to create a new StringBuffer passing the String you wish to convert as an arguement.

[honeybee]

Originally posted by filburt1
String has a s***load of methods and functions for it: http://java.sun.com/j2se/1.3/docs/ap...ng/String.html

Even the StringBuffer seems to have many methods. Most methods are overridden versions of each other, and there really don't seem to be any unique methods which could not be incorporated into the other class. In short, the String class does not have any methods which could not be implemented in the StringBuffer class, or vice versa.

As for Dilenger4's explanation, it seems that String class is sort of universal, with every object having a toString method to convert itself into a String object. If so, it would just be logical to add the unique methods of StringBuffer class to the String class and implement it more efficiently. An entire class could be eliminated this way.

.

[nemaroller]

Stringbuffer does not handle constant strings more efficiently than the String type. That is why the String type is there. You don't have to build a Stringbuffer object, which takes more resources, to simply use constant text.

[honeybee]

It still does not solve my original doubt: Couldn't it all be combined into a single class with a bit of a tradeoff between the resources and flexibility?

.

[nemaroller]

I imagine it could but then we'd have a tradeoff as you just mentioned instead of the options we have now...

As an example, why not combine all data types into a Variant?

[Dillinger4]

As an example, why not combine all data types into a Variant?

That is a good example but i think a little extreme. Im not sure how the compiler actually treats Strings vs StringBuffers. There must be some type of optimizations that lead to the two classes being seperate. I think it has somthing to do with the length of the String being set a at fixed length when the String is created. But other than that im not too sure.

[honeybee]

All it takes is allocating memory for the bigger size of the string, and releasing memory for the old string. I don't think it takes a great deal of effort, but I just could be wrong.

.

[nemaroller]

There are some other differences besides memory allocation, such as you can share Strings between classes, where you cannot with Stringbuffer, so maybe they were seperated for security issues among other things.

[honeybee]

Hmmm... That is too complicated. As a developer, I shall always be confused as to why Java has two different classes to manage the same thing. And whether there is a great need to differentiate between fixed-length and variable-length strings, so great that you need two different ways to manage it.

.

[filburt1]

Read the documentation!

From http://java.sun.com/j2se/1.3/docs/api/index.html

A string buffer implements a mutable sequence of characters. A string buffer is like a String, but can be modified. At any point in time it contains some particular sequence of characters, but the length and content of the sequence can be changed through certain method calls.

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.

String buffers are used by the compiler to implement the binary string concatenation operator +. For example, the code:


x = "a" + 4 + "c"
is compiled to the equivalent of:


x = new StringBuffer().append("a").append(4).append("c")
.toString()
which creates a new string buffer (initially empty), appends the string representation of each operand to the string buffer in turn, and then converts the contents of the string buffer to a string. Overall, this avoids creating many temporary strings.
The principal operations on a StringBuffer 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 buffer. The append method always adds these characters at the end of the buffer; the insert method adds the characters at a specified point.

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

In general, if sb refers to an instance of a StringBuffer, then sb.append(x) has the same effect as sb.insert(sb.length(), x).

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 buffer array. If the internal buffer overflows, it is automatically made larger.

[Dillinger4]

HoneyBee looking at the docs i really
think it all comes down to memory management
since a string is at a fixed length when it is declared.
Looking a the java.lang.String class i noticed that
there is no way to add to a string unless you
use the concat(String str) method. Really the only
other method that can be used to add internally to
a String is the replace(char old char, char, new char)
everything else seems to just enable you to compare
strings to strings or look for substrings within strings.
So in the end you cant make a String longer unless
you use concat(String str).

[nemaroller]

Just use Stringbuffer for everything then, that'll solve your problems...