StringBuffer over String Class

String myStr = “SchoolHoood”;
myStr = myStr.concat(” – Learn to Enjoy”);
myStr = myStr.concat(” – For 5 to 55.”);

Since strings are immutable in java, the above codes makes 2 hanging string objects in heap namely:
1. SchoolHood
2. SchoolHood – Learn to enjoy
Of course the final string “SchoolHoood – Learn to Enjoy – For 5 to 55.” will have a reference var as myStr.

If lot many modifications are required on a string, StrinBuilder/StringBuffer should be preferred over just plain String class. This is to avoid the loosing of strings in the heap-pool and hence saving the memory. For detail read Immutable String in Java.

The above code could be rewritten as:
StringBuffer myStrBuff = nw StringBuffer(“SchoolHoood”);
myStrBuff.append(” – Learn to Enjoy”);
myStrBuff.append(” – For 5 to 55.”);

Since append method is invoked on the StringBuffer object “myStrBuff” itself, hence append happens to be on the same string. Thus StringBuffer/SringBuilder objects can be modified over and over again without leaving behind a discarded String objects.

These two methods are used widely in case of FILE I/O because there you need to treat a large amount of data as a single unit. Say for example , while reading a file line by line — youStrBuilderObj.append(lineContent) — will make you to deal with data easily.

Immutable String in Java

Immutable concept : Once you assign a value to a string, you CANT change. Hence “replace” (or other methods like concat, subString etc) method couldn’t change myStr3.

Thus using string methods to create a new String by altering an existing String will never create a new string.

YOU NEED TO ASSIGN them to a NEW STRING, then only it will take in effect.

Look at step 6. Once everything is set to null. we know still “SchoolHood” & “JavaHood” do exist in Heap. What if we could take them back?

There is JVM plays major role. JVM sets aside a special area of memory called the “String constant pool.”

When the compiler encounters a String literal, it checks the pool to see if an identical String already exists. If a match is found, the reference to the new literal is directed to the existing String, and no new String literal object is created.

Thus if JAVA treats STRINGS as immutable; the thought design would have been to IMPROVE THE PERFORMANCE by having an excellent memory management.

public class StringReferenceDemo {
	public static void main(String[] args) {
		String myStr1 = "SchoolHood";  // 1
		String myStr2 = "SchoolHood";  // 2
		String myStr3 = myStr2; // 3

		System.out.println(myStr1.hashCode()); //1897055952 - Returns a hash code value for the object
		System.out.println(myStr2.hashCode()); // 1897055952
		System.out.println(myStr3.hashCode()); // 1897055952

		myStr3.replace("School", "Java"); // Still at 3
		System.out.println(myStr3); // SchoolHood
		myStr3 = myStr3.replace("School", "Java"); // 4a, 4b
		System.out.println(myStr3); // JavaHood
		System.out.println(myStr3.hashCode()); // -517433730
		String myStr4 = myStr3.replace("Java","School"); //5
		System.out.println(myStr4); // SchoolHood
		System.out.println(myStr4.hashCode());	 // 1897055952
		myStr1 = myStr2 = myStr3 = myStr4 = null; // 6

		String myStr5 = "SchoolHood"; // 7
    System.out.println(myStr5.hashCode()); // 1897055952


1: myStr1 is a reference variable pointing to the add location (Java converted hashcode value 1897055952)
2. myStr2 is a reference var pointing to the same location : #1897055952
In heap there is a space ALREADY allocated, hence no new location is assigned.
3. myStr3 is a reference var pointing to the same location : #1897055952
Although using a replace wont change the myStr3. Still myStr3 as the same location : #1897055952
Hence printing myStr3 even after replace you are getting the same “SchoolHood”
4a. Replace and assignment dereferences myStr3 from “SchoolHood” and
4b. references newly to the new location as “JavaHood”. Hence myStr3 is now “JavaHood” at #-517433730
5. myStr4 – Again replacing “JavaHood” to “SchoolHood”. Hence pointing back to the same #1897055952
Doesnt create any new location
5. Set all these vars to null.
Still in memory you will find SchoolHood at #1897055952 and JavaHood at #-517433730
7. myStr5 is claiming back the pos of #1897055952 coz of “String constant pool”


Still one question remains, what if such string name-values are quite large in the heap? What is the best to avoid it?

Answer is in STRING BUFFER/STRING BUILDER. Keep watching. Shortly it will be posted here.

DOS command – Not used frequently

TREE – Representing the folder hierarchy

FIND – to find particular text in a given file

/N – Line number

/I – Case insensitive

Do google for FINDSTR – interesting one.

TASKLIST – Show all the active services

TASKKILL – Kill the particular one based on the PID (Process Id)

SYSTEMINFO – Various details about your m/c configuration

For security reason few field values are masked in above screen shot.

If Class Name & Method Name are same?

Any guess for the code below? Will it compile or run time error?

package SchoolHood;  // SchoolHood as package name

public class SchoolHood {
      System.out.println("SchoolHood--As a Constructor.");

    public void SchoolHood(){
      System.out.println("SchoolHood--As a Simple Method");

    public static void main(String[] args) {
      System.out.println("SchoolHood--As a Class Name");
      new SchoolHood().SchoolHood();

Program written above is absolutely right. Package/Class/Method name may be the same as they share different namespaces. Hence no issue.
Seems to be some1 is loving the name rather than the ethics of programming. Aaahhhhh!