stringbuffer plugin...

Hi all. I searched for quite a while but could not find a good example of the stringbuffer plugin in use. In looking at the methods of the plugin itself, I believed I figured out how to use it, but it left me with some questions I thought I’d ask on the list. First of all, look at how I implemented it and tell me if I used it as it was intended:

  1. Inject the plugin into my model object (‘campaignService’) via coldspring.xml:
  1. within my model object, use stringbuffer to build a Transfer TQL statement:

<cfset thisTQL.append(“select,, C.description, C.createdDate, as batchid,u.firstname,u.lastname, as userID from campaign.campaign as C outer join batch.batch as b outer join user.user as u”) />

<cfset thisTQL.append(" order by,") />


That is how I implemented it and it worked just fine, but if I have misused it, please do correct me.

My big question now, though, is in regards to the whole “buffer length” idea. Why is this addressed within the CFC at all? Why has an initial buffer length been allowed to be set when calling the ‘setup’ method? I experimented with using a large bufferlength value at setup, a small bufferlength value at setup, and NO bufferlength value at setup, and it made zero difference at all in the outcome: everything worked fine. I read in the java docs for stringbuffer that “…If the internal buffer overflows, it is automatically made larger…”, so why then do I care about setting the buffer length, or looking at the buffer capacity or current buffer length, as several of this plugin’s methods allow me to do??? Just curious why these provisions would have been made when ignoring them doesn’t appear to have any effect whatsoever on the final results. Perhaps I’m missing a vital piece of understanding.


Doug :0)

Hi Doug,

You will see the effects of the length in the string buffer when doing multiple operations and even long string concatenaning operations. At first look, the changes are not evident, but as you have extermely long concatenations and operations, then you will see a difference.

The rest of the code looks great.


  This thread is timely for me because I recently had a case where I
was running out of memory in CF when doing string concatenation. Since
I'm on cf8, I went with StringBuilder and saw insane improvements.
This leads me to wonder:

would it be a good idea in the StringBuffer plugin to choose
StringBuilder when it recognizes a java 1.5 vm? the javadocs prefer
STringBuilder over StringBuffer.

Is the internal SB object guaranteed to be threadsafe (is it a
function-level variable or a member variable?)? if so, it might be
worth considering.

simply a recommendation/thought/something to think about. if it's
class level and the plugin is an application/server/session-scoped
singleton, then obviously this won't fly.

2 cents!



We did some experiments with StringBuilder but due to some CF8 issue,
dropped for this release.

(length() method does not exists)
Here is the code myBuffer.toString().length()


that's interesting, Sana. I tried this and it worked fine.

Again, I'm not saying "you should do this". I just thought it was
interesting how much faster StringBuilder was for me with really large
strings. In the past, working with StringBuffer, I'd see not much
performance benefit vs. straight string comparison, and in many cases,
it was indeed slower. I think that's what caused my stinkeye toward

here's the code i used, by the way, to show that each works OK for me on cf8:

<cfset sb = createObject("java","java.lang.StringBuilder").init("")>

<cfset sbuf = createObject("java","java.lang.StringBuffer").init("")>

<cfloop from="1" to="10" index="i">
  <cfset sb.append( repeatString(i, randRange(1,100) ) )>
  <cfset sbuf.append( repeatString(i, randRange(1,100) ) )>

  #sb.toString().length()# <br>





I agree on StringBuilder, however, please read this:

That is the reason of reverting to StringBuffer. Also, this bug is not in Railo, only Adobe!!

nice! now that's freakin' weird.

good stuff, Sana and Luis. Thanks for the heads up.

I believe its a bug in how Adobe implements the java proxy.