What is string class and string buffer class in java?

Answer 1

Strings are probably one of the most commonly used java data-types. They can hold almost anything that are enclosed within a pair of double quotes and hence are very versatile and powerful. This chapter covers the String class.

Strings Are Immutable Objects

Handling "strings" of characters is a fundamental aspect of most programming languages. In Java, each character in a string is a 16-bit Unicode character. Because Unicode characters are 16 bits, a rich, international set of characters is easily represented in Unicode.

In Java, strings are objects. Just like other objects, you can create an instance of a String with the new keyword, as follows:

String s = new String();

This line of code creates a new object of class String, and assigns it to the reference variable s. So far, String objects seem just like other objects. Now, let's give the String a value:

s = "abc";

As you might expect, the String class has about a zillion constructors, so you can use a more efficient shortcut:

String s = new String("abc");

And just because you'll use strings all the time, you can even say this:

String s = "abc";

There are some subtle differences between these options that we'll discuss later, but what they have in common is that they all create a new String object, with a value of "abc", and assign it to a reference variable s. Now let's say that you want a second reference to the String object referred to by s:

String s2 = s; //refer s2 to the same String as s

String objects seem to be behaving just like other objects, so how is it that they are Immutable? Once you have assigned a String a value, that value can never change-it's immutable, frozen solid, won't change. The good news is that while the String object is immutable, its reference variable is not, so to continue with our previous example:

s = s.concat(" efg");

// the concat() method 'appends' a literal to the end

Didn't I just say that Strings are immutable? Yes, I perfectly did. But, here the stuff within the double quotes that is passed as argument to the concat method gets appended to the end of the String s. How did this happen?

The VM took the value of String s (which was "abc"), and added or rather appended " efg" onto the end, giving us the value "abc efg". Since Strings are immutable, the VM couldn't stuff this new value into the old String referenced by s, so it created a new String object, gave it the value "abc efg", and made s refer to it. At this point in our example, we have two String objects: the first one we created, with the value "abc", and the second one with the value "abc efg". Technically there are now three String objects, because the literal argument to concat, " efg", is itself a new String object. But we have references only to "abc" (referenced by s2) and "abc efg" (referenced by s).

Note, however, that the original "abc" String didn't change; only the reference variable s was changed, so that it would refer to a different String.

To wrap up, the original variable 's' in which we had "abc" as value would be abandoned and a new value "abc efg" would get assigned to it as soon as the s.concat(" efg") line of code is executed.

Strings are extremely useful but at the same time resource intensive too. In programs where numerous strings are used which need to be altered every now and then, it is advisable to use the StringBuffer or the StringBuilder class.

The java.lang.StringBuffer and java.lang.StringBuilder classes should be used when you have to make a lot of modifications to strings of characters. As we discussed in the previous chapter, String objects are immutable, so if you choose to do a lot of manipulations with String objects, you will end up with a lot of abandoned String objects in the String pool. On the other hand, objects of type StringBuffer and StringBuilder can be modified over and over again without leaving behind a great list of discarded String objects.

StringBuffer vs. StringBuilder

The StringBuilder class was added in Java 5. It has exactly the same API as the StringBuffer class, except StringBuilder is not thread safe. In other words, its methods are not synchronized. (For now just know that syncrhonized is used for thread safety and causes an overhead in terms of performance) Sun recommends that you use StringBuilder instead of StringBuffer whenever possible because StringBuilder will run faster. So apart from synchronization, anything we say about StringBuilder's methods holds true for StringBuffer's methods, and vice versa.