When Not To Use StringBuffer

The old adage about only having a hammer and thinking everything is a nail can apply just as easily to programming. If you blindly apply the rule that appending strings in Java is way more expensive than using a StringBuffer you can end up with some strange and arguably wrong results.
Take for example the PreparedStatements in a large piece of code I’m charged with working on. The SQL queries in this code are quite large and would stretch out to several hundred characters if they were not wrapped in some way within the code. So they were broken up into multiple strings, but the original author apparently feared the horrific overhead that String could impose and we ended up with a lot of code that looks like this.
StringBuffer selectStatement = new StringBuffer();
selectStatement.append("select blah, blah1, blah2, blah3, ");
selectStatement.append("blah4 from BLAH where );

I did a really short one as an example but imagine this going on for 20+ lines because the individual field names are long, etc. And it’s all completely pointless in this case. We aren’t building a dynamic string that has changing elements in it. There aren’t any other strings being passed into be appended, they are all just static strings containing text and question marks where the paramaters will later be put by the prepared statement. So it never changes!
In this case the StringBuffer is actually slower than just using plus signs where we had to break the lines and a String that the entire thing is assigned to. Any compiler worth its salt will take note that all the strings are static and append them into a single string at compile time without any .append() calls being needed. Plus all the extra function calls are just an obfuscation around the SQL query which you would like to have easily readable in the code. Note: The thought of moving the queries out of the code completely using something like iBatis hasn’t even been touched yet. This is really straight up JDBC stuff here.
Please, think before you blindly follow rules. Why is the rule there? When does it make sense to break the rule?


3 thoughts on “When Not To Use StringBuffer

  1. Tom Hawtin

    A few years ago an Apache project (I believe James) had changes right across the project to use StringBuffers in just this sort of situation. Worse, the programmer, presumably not wanting to come up with names other than “buff” reused local variables for completely different strings. Horrible code.
    Even if you are adding dynamic parts (but not within loops), using + may be faster. javac will use StringBuffer behind the scense (use javap -c to see exactly what it does). For 1.5, it will switch to using StringBuilder which should be fractionally faster (possibly).

  2. Rick Stabile

    If these Strings won’t be changing, why not put them into a properties file (back-slashes can be used for line continuations in the values) and read them from there into a Map, collection, or array of Strings when the time comes?

  3. John Munsch

    As I said in my posting, I haven’t tackled removing all the repetitious code in these JDBC calls or moving the queries themselves out of the code. It will happen, but not yet.
    My friend Don has used iBatis for this purpose in the past and I know he was fairly happy with it.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s