Stringbuffer as SQL string?

[Keith Fiske]

I've been working through the OReilly JavaServer Pages book, and I've come across something I can't find an answer for just googling around.

For the classes that create the SQL string, a Stringbuffer is used to build the SQL command whenever a PreparedStatement will be used. Before I got to this part, I'd just been creating the SQL command as a plain String. I read about the thread safety the Stringbuffer provides, but I'm not sure I see where that is the reason it's being used here, especially since it's just converted to a regular string when it's sent to the SQLCommandBean that does the actual processing.
Is there another reason for this that I'm not understanding? Some example code below.

 
... 
StringBuffer sql = new StringBuffer();
sql.append("INSERT INTO Employee ").
append("(Dept, EmpDate, EmailAddr, FirstName, LastName, ").
append("Password, ModDate, UserName) ").
append("VALUES(?, ?, ?, ?, ?, ?, ?, ?)");

SQLCommandBean sqlCommandBean = new SQLCommandBean();
        sqlCommandBean.setConnection(conn);
        sqlCommandBean.setSqlValue(sql.toString());
        ... further code that adds dynamic values and executes sql statement ...

[Sebastian Janisch]

well, if you don't use multiple threads you don't need to worry about the synchronization of the StringBuffer ..

the reason it is used when concatenating Strings is because it is faster, due to it's internal buffer ... check here
https://coderanch.com/t/455484/Java-General-intermediate/java/Why-StringBuffer-size-charectors-java

[Keith Fiske]

If the String is created as just a single statement, with no concatenation, there's no real need for the StringBuffer then?

Appreciate the info in that link, though. Didn't know about the performance difference when concatenating.

[Jelle Klap]

It's probably an attempt at maintining readability of the SQL String, and they are making use of the StringBuffer class to avoid lots of String concatination.
Not a very good attempt, because first of all they're using a StringBuffer instead of a StringBuilder, and I rather doubt they chose StringBuffer explicitly for reasons related to concurrency.
However, as they are exclusively and consecutively appending String literals anyway, they whole point of using a StringBuilder/StringBuffer is rather moot.
They could just as easily have chosen normal String concatination, which in my opinion could have made the code more readable.

[Sebastian Janisch]

well, even if you already know the final length of your String, StringBuilder/-buffer can be better regarding performace if your String spreads over several lines and is to
be concatenated with the + operator ...

if you code

  String s = "This " + " is" + " Java";  

there will be 3 String objects on the heap
1. 'This'
2. 'This is'
3. 'This is Java'

[Keith Fiske]

Thanks for the replies! Was just something that was bugging me and I wanted to understand why they were doing it. If there was some big reason I was missing, I wanted to understand it before I got further into my project.

[Sebastian Janisch]

I have to correct myself ....

String s = "This" + " is" + " Java";

does not result in 3 String objects on the heap...

The smart compiler detects that there is no dynamic expression between the concatenated Strings, it hence strips out the + signs and turns it into

String s = "This is Java";

hence

String s1 = "This" + " is" + " Java";
and
String s2 = "This is Java";

and

System.out.println(s1 == s2);

will output true...

[Keith Fiske]

Following up on your above correction, so if a concatenated String had dynamic values in the expression, it would create multiple objects on the heap, whereas the StringBuilder/Buffer would not?

[Joanne Neal]

Keith Fiske wrote:Following up on your above correction, so if a concatenated String had dynamic values in the expression, it would create multiple objects on the heap, whereas the StringBuilder/Buffer would not?

Yes and no. Suppose you have something like this

String ConcatenateStrings(String s1, String s2, String s3, String s4)
{
  String result = s1 + s2 +s3 + s4;
  return result;
}

Obviously, the Strings referenced by s1, s2, s3 and s4 will already exist on the heap before the method is called.
Now you might expect a number of intermediate Strings to be created by all those concatenations i.e. something like

String result = s1 + s2; // One new String created.
result = result + s3; // Another new String created.
result = result + s4; // Yet another new String created.

However, what actually happens is that the compiler is clever enough to optimise this. In the latest JDK this code will actually become something like

StringBuilder result = new StringBuilder(s1).append(s2).append(s3).append(s4);
return result.toString();

So, you might think, why not write the code to use StringBuilder in the first place ? This would be a mistake. As I said, the current JDK optimizes a string of concatenated Strings by using StringBuilder. However, a future JDK may come up with a better optimisation. If you've written code that uses StringBuilder, the compiler won't be able to use this better optimisation, whereas if you write it as a string of concatenations, it will.

[Keith Fiske]

Hmm... ok. Well, this is a brand new app and I'm developing against Java 1.6, so I guess it would be ok for me to do concatenation with a regular String object then since no synchronization is required?

[Jason Irwin]

Why use a Buffer or a Builder at all?

String myTemplateSQL = "SELECT foo FROM bar WHERE blah=\"%0$\"";
String mySQL = String.format(myTemplateSQL, myValue);

If you actually need to do concatenation, then you could use a combination of a StringBuilder and fomatted Strings.

[Keith Fiske]

Jason Irwin wrote:Why use a Buffer or a Builder at all?

That's my original question.

[Jason Irwin]

I guess it could be the age of the book and the version of Java at the time, or at least the version of Java that was about when that section was written and it has never been changed as it's not really "wrong". I've seen a few Java books where a section or so is clearly using Java from an earlier version; it still works but there are "better" ways to do it.

[Jesper de Jong]

Jason Irwin wrote:I guess it could be the age of the book and the version of Java at the time, or at least the version of Java that was about when that section was written and it has never been changed as it's not really "wrong".

It's not really "wrong" to use a StringBuffer to append a bunch of fixed strings together, but it is certainly unnecessary, makes your code more complicated than it should be, and inefficient for no reason at all, so you should never write code like that in a real program. It's not "wrong" in the sense that it does what it should do, but it's certainly not the right way to write a program in Java.

If I'd see code like that in a book, I'd strongly doubt if the authors are really good Java programmers.

[Keith Fiske]

Well, the third edition of the OReilly JavaServer Pages book was published in 2004, so old code is probably the answer.

I can't fault the book at all, though. I've learned a tremendous amount from it.