aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Use of StringBuffer instead of String Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Use of StringBuffer instead of String" Watch "Use of StringBuffer instead of String" New topic
Author

Use of StringBuffer instead of String

Samantha O'Neill
Greenhorn

Joined: Apr 15, 2003
Posts: 26
Hi there
For my method that builds the criteria string from the search criteria I currently use the append() method of StringBuffer and then call toString() on the buffer at the end. Originally I used the + operator and the += operator with the String class but I was concerned that under the bonnet each time I called += for example in the following:

my application was then having to allocate a new String, copy the existing string plus the extra string into it then again and again as I added more criteria. So it seemed a waste of resources.
Is it okay to append the criteria to a StringBuffer instead as this is what it all gets translated to in any case. It is more long winded but its easy to read.
Any opinions welcome. Thanks alot
Sam
Christian Garcia
Ranch Hand

Joined: Jan 29, 2002
Posts: 77
If you're using the append() method in a loop construct I think that's good choice. If the += syntax is present in a loop it will/could have an impact on the performace of the application. It may even result in points being deducted, but I'm not certain that's the case. The graders seem to nit-pick some of the finer details, so I think a StringBuffer is the way to go.
Also, the JDK states that:
String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved...
As long as the length of the character sequence contained in the string buffer does not exceed the capacity, it is not necessary to allocate a new internal buffer array. If the internal buffer overflows, it is automatically made larger.
. Thread-safe and no buffer overflow = GOOD CHOICE.
[ May 06, 2003: Message edited by: Christian Garcia ]

Christian
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
You mean this sort of thing:
?
This is possibly the other extreme with points lost for lack of readability.
[ May 06, 2003: Message edited by: Barry Gaunt ]
[ May 06, 2003: Message edited by: Barry Gaunt ]

Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
Samantha O'Neill
Greenhorn

Joined: Apr 15, 2003
Posts: 26
Actually Barry I have something more like this:

As its very easy to read. My concern is that its too long-winded. But on the other hand using the + operator would mean allocating a new String each time I use +=. For example

I'm not concerned about making sure my buffer is synchronized as this processing is on the client side so there are no other clients or other threads that could corrupt its contents in any place.
I agree Barry that the .append().append() idiom is ugly and difficult to read so have most gone for the String and + method?
Thanks for the input
Sam
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11479
    
  94

Hi Sam,
Personally I think your first example is much easier to read, and it has the advantage of not requiring new Strings to bounce in and out of scope. That is the one I would go for.
My code also uses StringBuffers for creating the search string.
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Use of StringBuffer instead of String