Verwirrung um StringBuilder und StringBuffer bei Eclipse
Im News and Noteworthy des Eclipse 3.4M4 habe ich heute morgen etwas ziemlich komisches gesehen, und zwar gibts es einen neuen Quickfix:
Was durch folgenden Code ersetzt wird:
Ok, was fällt auf? StringBuffer! Dabei sollte man grundsätzlich immer StringBuilder verwenden, welcher im Gegensatz zum StringBuffer nicht synchronisiert ist. Um Thomas, unseren Parall- und Netzwerkprogrammierexperten, zu zitieren, ist der StringBuffer “unglaublich schweinisch sauteuer”.
Nehmen wir an, es würde anstelle des Buffers ein Builder verwendet, dann wäre der QuickFix trotzdem ziemlich unsinnig, denn der Compiler (zumindest Sun’s) ersetzt manuelle String-Konkatenationen sowieso durch StringBuilder-Aufrufe. Aus:
int offset = 3, line = 5;entsteht also folgender ByteCode:
String s = "Offset " + offset + " is at line " + line;
0 iconst_3
1 istore_1 [offset]
2 iconst_5
3 istore_2 [line]
4 new java.lang.StringBuilder [16]
7 dup
8 ldc [18]
10 invokespecial java.lang.StringBuilder(java.lang.String) [20]
13 iload_1 [offset]
14 invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
17 ldc [27]
19 invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [29]
22 iload_2 [line]
23 invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
26 invokevirtual java.lang.StringBuilder.toString() : java.lang.String [32]
29 astore_3 [s]
30 return Interessanterweise wurde der QuickFix auch schon an anderer Stelle kritisiert, allerdings nicht das Kernproblem:
I know using StringBuffers is better for performance.
Tsts…
Ich überlege mir, einen Patch einzureichen, der den QuickFix wieder löscht 
5 comments on “Verwirrung um StringBuilder und StringBuffer bei Eclipse”
Leave a comment
You must be connected to write a comment.
Ja mach das, ich find das völlig unsinnig. Am Schluss wird das noch gängige Praxis wegen solchen Quickfixes.
Hm, ok, es gibt schon diverse Reports dafür, dann werde ich das wohl lassen..
IMHO sollte der Compiler das Optimieren übernehmen, nicht der Programmierer … und da er das ja anscheinend tut, sollte man weiterhin die (kürzere und besser lesbare) Variante mit + benutzen.
Zwei Punkte:
– StringBuilder ist nur fuer Java 1.5 und aufwaerts, also nicht als allgemeine Loesung brauchbar (man denke nur an JME Systeme, von Java 1.4 Systemen ganz zu schweigen). Natuerlich: der QuickFix koennte das KompatibilitaetsLevel checken und je nachdem StringBuffer/StringBuilder anbieten.
– das Performance Problem mit StringBuffer sollte heute nicht mehr existieren. Solange das StringBuffer Objekt nur von einer lokalen Variable referenziert wird, ist es ja sowieso nur von einem Thread aus sichtbar, und das ist vom JIT/DynamicCompiler erkennbar, und das ganze GeLocke braucht gar nicht gemacht werden.
Sali Werner!
Den ersten Punkt sah ich schon kommen, aber wie du sagst, das könnte man einfach erkennen.
Zum zweiten: Ok, wenn das wieder wegoptimiert wird dann ists ja gut, aber deswegen sehe ich den Sinn immer noch nicht. Und es wird ja behauptet, dass der Code “more efficient” wird, und das ist doch schlichtweg falsch. Wenn man also Glück hat wird der Code nicht ineffizienter, “nur” unleserlicher.