In Java, why use StringBuilder instead of Strings?
Stringbuilder vs. String - why use String builder
hibernate - In Java, when should I prefer String over StringBuilder vice versa? - Stack Overflow
Java .equals between String and StringBuilder - Stack Overflow
So far can't really tell the benefit of using it over Strings.
Is Stringbuilder used much? What uses does it have? (The only examples I found was concatenation, which you can do with Strings and the "+".)
You should use String, because String objects are cached in an object pool and might deliver better performance when you don't change them.
A StringBuilder is only useful when you keep on concatenating String tokens, which shouldn't be the case in a well normalized database table.
The JVM does all sorts of optimizations and chances are that even if you use concatenation the JVM might rewrite that routine to a StringBuilder version.
A simple rule of thumb (String is a type that represents character strings. StringBuilder a stream of mutable characters)
Use String to represent text values. By definition Java provides pooling of string values and thus providing you some space optimization. Think of this in a scenario where your application is dealing with millions of text values during a file batch processing. So as an example.
String str1 = "Test";
String str2 = "Test";
Here, str1 == str2 ( same reference)
Also, + operator is overloaded in String to construct String from different types. This can be used when constructing small Strings ( internally it gets done using StringBuilder so no worries) - but not while looping.
Use StringBuilder(or old counterpart StringBuffer) only when you are constructing a target String using small pieces of different types - and especially inside a loop - this will help you to avoid placing unnecessary string fragments in the string pool.
StringBuilder s1 = new StringBuilder("test");
StringBuilder s2 = new StringBuilder("test");
Here, s1 != s2
Also, I do not think there is someway you can manipulate the encoding of StringBuilder/Buffer - Meanwhile String allows this.
Edit: Representing Hibernate entities :
Always use String to represent a text type in your class. For reasons stated above.This should come to you like muscle memory. For example, int, float, char etc for primitive types and String for text type. Use the builder only to build strings and not to represent a type unless that is some strange requirement.
Because they both are Different objects.
String object!= StringBuilder object.
But,Your doubt is
name1.equals(s) returning true
Because in String class equals method ovverided in such a way.
And to get the desired output convert your StringBuilder to String.
System.out.println(s.equals(sb.toString())); //return true.
If you see the Source code of String#equals()
1012 public boolean equals(Object anObject) {
1013 if (this == anObject) {
1014 return true;
1015 }
1016 if (anObject instanceof String) { //key line
1017 String anotherString = (String)anObject;
1018 int n = count;
1019 if (n == anotherString.count) {
1020 char v1[] = value;
1021 char v2[] = anotherString.value;
1022 int i = offset;
1023 int j = anotherString.offset;
1024 while (n-- != 0) {
1025 if (v1[i++] != v2[j++])
1026 return false;
1027 }
1028 return true;
1029 }
1030 }
1031 return false;
1032 }
The line if (anObject instanceof String) { always returns false incase if you pass StringBuilder.
The reason for the two false cases is that this is how the respective equals(Object) methods are specified to work.
For
String.equals(Object), the javadoc says this:"Compares this string to the specified object. The result is true if and only if the argument is not null and is a String object that represents the same sequence of characters as this object."
For
StringBuilder.equals(Object), theequalsmethod is inherited fromObject, where the javadoc says this:"returns true if this object is the same as the obj argument; false otherwise."
So on Line #1 and Line #3, String.equals(Object) returns false because sb is not a String.
And if you reversed it and called sb.equals(name1) or sb.equals(s) you would get false also ... because sb.equals(...) is testing for the same object.
I dont understand why compiler does not think "name1" and "sb" as containing the same value
As you can see, it is nothing to do with the compiler ... and everything to do with the way that the equals method is specified.