this being conditionally executed code (specifically the value
java.util.logging.Level.FINE) I think performance is not a relevant
argument for applying this patch; it will only be run by people
actually needing this level of debugging, I'm pretty sure they would
not be concerned with performance..
you are right the problem was with "+=" not with the simple "+"
Simone
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob:
Simone Giannecchini ha scritto:
> string1 + string2 + string3
>
> becomes
>
> temp=new StringBuffer(string1).append(string2)
> temp2= new StringBuffer(temp),apend(string3)
>
> result = temp2.toString();
>
> and this was true until the last time I checked, which was a while
> ago, but It was a
Jody Garnett ha scritto:
> Hi Andrea:
>
> StringBuilder is supposed to be slightly faster (and non threadsafe);
> but it is murder on readability.
Slightly faster than StringBuffer, but if you look the bytecode below
you'll see normal string concatenation already uses it.
So there is no differenc
string1 + string2 + string3
becomes
temp=new StringBuffer(string1).append(string2)
temp2= new StringBuffer(temp),apend(string3)
result = temp2.toString();
and this was true until the last time I checked, which was a while
ago, but It was at least using Java 5.
Simone
---
Hi Andrea:
StringBuilder is supposed to be slightly faster (and non threadsafe); but it is
murder on readability.
I used a java 5 trick in some GeoTools code that I am starting to be very fond
of. Using the Object... param syntax to hide the concatenation.
If we were add such a method to LOGGE
