Let me provide some clarification on this issue (even though it appears to have been beaten to death).

As of JDK 1.3 (I believe), there is no difference between doing a String concatination ( "foo" + "bar" ) and using a StringBuffer to do the same thing. So, the moving of string concatinations to StringBuffers will have no speed difference in the newer JVM's (I'm assuming we're referring to Sun's JVM, as I'm not sure what IBM's does in the same situation).

As for the need for static...I don't believe it will add value. The final means that it's a constant, which means that it shouldn't even create a new value for each instance (I believe, when it's final, that if affects the *scope* of the field, and nothing else). I'm not a 100% sure of that, but I believe that to be the case.

The point is that, to a certain extent, the programmer shouldn't be too worried about certain optimizations, as it's a JVM issue, not a language issue. Obviously, this can be a problem when the JVM is a bottleneck and the programmer has to work around it. The nice thing about this is that newer JVM's speed up existing code (for free...no code changes).

Another example is that way the garbage collector works...lots of small, local object creations aren't that interesting anymore (that is, they aren't the bottleneck). So, doing the string concatination doesn't cost as much in the new JVM's. In fact, in one project I worked on, I'd built an object pool. It worked really nice in JDK 1.2, but when we ran it in JDK 1.3, it actually was slower (sped up after I removed the pool). Of course, I'd better note that the pool was accessible across multiple threads, so the synchronization was the speed cost (but I had to have it, because of the multiple threads).

Dan Shellman