Java Strings and StringBuffers looked at

Miscellaneous Topics
#1

Wow just figured this out, before you read further down try thinking what the method below is going to outprint.


	public void test() {
		String s = "hello";
		String s1 = new String("hello");
		if (s == s1 || s1 == s) {
			System.out.println("TRUE");
		} else if (s != s1) {
			System.out.println("FALSE");
		}
	}

Results: “FALSE”.

I’m watching a series on youtube here:


(Random episode i’m watching).

The video pertaining to that method I created above is ‘Strings & StringBuffers’.

Basicly saying that instead of:


String s = "hello";

You should use this to save the JVM from creating more memory weight:


String s1 = new String("hello");

Or, if you were to go:


	public String test() {
		String s = "hello";
		String s1 = "world";
		String s2 = s += s1;
		return s2;
	}

It would save more space on the JVM/memory if you were to basically just complete the next method it’s going to perform.
(Saving the JVM some heap memory)


	public String test() {
		String s = new String("hello");
		String s1 = new String("world");
		String s2 = new StringBuffer("hello").append("world").toString();
		return s2;
	}

Basically because with this method:


	public String test() {
		String s = "hello";
		String s1 = "world";
		String s2 = s += s1;
		return s2;
	}

It’s creating 2 Memory Heaps/Storing Memory for each String, because out of those Strings if it involves ‘s1 += s2’ it than has to go through Java’s StringBuffer class, as seen in the method above.

Hope this helps somebody out, looks like i’m going to start smart coding.

#2

StringBuffer is unnecessarily synchronized. Use StringBuilder instead, which IIRC is what javac is itself using now for string concatenations (that lesson was probably written before StringBuilder existed).

#3

Wish there was a way to actually tell how much heap or how many stacks you were creating.
I’d sit here comparing methods all day o.O

#4

You can use a heap profiler to profile the heap, but this example is ridiculously short-lived, and isn’t going to eat any appreciable amount of memory unless you’re doing this with strings that are hundreds of megs – and then it’s more “WTF are you doing making them single strings”.

Stack is something you don’t need to worry about unless you’re a) running out of it, or b) spawning hundreds of threads.

It’s good to be aware of the costs of doing naive string concatenation, but since java started using StringBuffer/StringBuilder instead of the super-naive algorithm in most cases, it hasn’t been all that big a deal.

#5

This is what fascinated me:


public void test() {
      String s = "hello";
      String s1 = new String("hello");
      if (s == s1 || s1 == s) {
         System.out.println("TRUE");
      } else if (s != s1) {
         System.out.println("FALSE");
      }
   }

I deal with methods using a String peram all the time:


public void getName(String name) {
      if(name=="lol") {
            doLol();
      }

How can that return false…
String s = “lol”;
String q = new String(“lol”);
or vice versa:
String s1 = “lol”;
String s2 = new String(s1);

s IS = q;

and s1 IS = s2 which is = s1;

#6

String literals are interned, and will share the same reference if they’re the same literal string, but strings created through the String constructor never are, so they’re a unique object every time. Same goes for any string that’s computed in any way that the compiler can’t optimize away into a pure constant. This is why you always use .equals() to compare strings, never ==.

#7

Well I just learned something new:


	public static void test() {
		String s1 = "lol";
		String s2 = new String(s1);
		if (s1.equals(s2)) {
			System.out.println("TRUE");
		} else if (!s1.equals(s2)) {
			System.out.println("FALSE");
		}
	}

And now it returns True, thank you mate.

#8

Strings are just objects in JAva, take that example


class Stuff
{
    public static final Stuff ZERO = new Stuff(0);
    private int value;
    public Stuff(int v){value=v;}
    public boolean equal(Stuff other){return value == other.value;}
}

Stuff z = Stuff.ZERO;
Stuff z1 = new Stuff(0);

z == z1; //<= will be fals, because those are two different object references
z.equals(z1);// will be true, because both hold the same value, the equals method is checking for