strings in java verpönt?

[Guest]

Hi,

hab da mal ne Frage zum Thema Strings...
viele behaupten, dass Strings in java verpönt sind... so nach dem Motto, bloß nicht zuviele String-Objekte im Programm usw......

Warum wird das gesagt und wie macht man es richtig??? z.B. Soll man StringBuffer nehmen und append für's konkatenieren anstatt string + string + string ...

ist das einfach nur auf die string-objekt anzahl bezogen oder wie soll ich das verstehen??

 

[maki]

Gerüchte...

Nimm einfach String +, wenn's zu lange dauert kannst du immer noch optimieren, lesbarkeit ist meist wichtiger.

 

[tfa]

Anstatt + in Schleifen zu verwenden, sollte man möglichst einen StringBuilder nehmen. Ansonsten ist die Aussage "strings in java verpönt" Blödsinn.

 

[Der Müde Joe]

http://books.google.ch/books?id=ZZO...X&oi=book_result&resnum=3&ct=result#PPA155,M1

 

[Gast]

danke für den spitzenlink... erleuchtung pur

 

[OneAndZero]

Der Müde Joe hat recht, auch rein aus SQM Sicht ist die Aussage von maki nicht sehr possitiv zu werten.
Natürlich kann man Strings mit + konkatenieren, sollte man jedoch immer darauf achten wie groß und umfangreich ein Projekt wird.
Und das mit der Lesbarkeit ist reine Geschmackssache!

 

[Guest]

Hat aber auch etwas mit dem Heap zu tun ...
Meiner Meinung nach sind StringBuffer für so etwas besser geignet da der Heap
dann nicht "zumüllt" weil jeder neue veränderte String ja neu angelegt werden muss.
Ein Buffer ist meist automatisch so groß dimensioniert sodass dieses Problem meistens
umgangen wird.
Bei kleinen Programmen ist dies wohl eher egal aber bei großen kann es schon
zu Leistungseinbrüchen kommen.
Von daher lieber gleich den String Buffer benutzen.

 

[tfa]

Der Müde Joe hat recht, auch rein aus SQM Sicht ist die Aussage von maki nicht sehr possitiv zu werten.
Natürlich kann man Strings mit + konkatenieren, sollte man jedoch immer darauf achten wie groß und umfangreich ein Projekt wird.
Und das mit der Lesbarkeit ist reine Geschmackssache!

Dir ist schon klar, dass die Konkatenation mit + vom Compiler in nichts anderes als StringBuilder (bzw. früher StringBuffer) umgewandelt wird? Und was hat das mit QM zu tun?

 

[L-ectron-X]

StringBuffer ist alt, jetzt nehmen wir StringBuilder.

 

[maki]

http://books.google.ch/books?id=ZZOiqZQIbRMC&pg=PA155&lpg=PA155&dq=effective+java+string&source=bl&ots=UZM29viI75&sig=mWWP2oKx2avbXJ0_zqhWREc8wrw&hl=de&sa=X&oi=book_result&resnum=3&ct=result#PPA155,M1

Ist veraltet, stammt noch aus der Zeit als der Javacomiler nicht optimiert hat.

auch rein aus SQM Sicht ist die Aussage von maki nicht sehr possitiv zu werten.

Was ist SQM?

Natürlich kann man Strings mit + konkatenieren, sollte man jedoch immer darauf achten wie groß und umfangreich ein Projekt wird.

Lustigerweise macht der Compiler dass schon ganz von selbst.
Aber natürlich nicht mit dem hier erwähnten StringBuffer, da dieser veraltet ist, StringBuilder ist angesagt.

Und das mit der Lesbarkeit ist reine Geschmackssache!

Manche Leute haben einen komischen Geschmack..

.append()
vs.
+

tfa hatte schon die Ausnahme erwähnt, nämlich in Schleifen.

Hatten das Thema hier schon oft, einfach mal suchen, da hatte ich schon einen Link gepostet in dem erklärt wird warum man sich mit "manuellen" Optimierungen zurückhalten soltle, solange man keine Performanceproblöme hat.

Dieser Thread ist aber ein schönes Beispiel wie lange sich Gerüchte halten, liegt wohl daran dass Leute gerne nachplappern als selbst zu testen bzw. nachzuforschen

 

[Gast]

Unter einem Anfängerforum erwarte ich einfach ein Grundverständnis für Leute, die nicht den ganzen Tag zu Hause rumimplementieren und programmieren vielleicht nur als hobby ansehen ... soviel zum thema forschen ...

am besten wir forschen alle nur noch bis wir nicht mehr forschen können.. anstatt auch mal zu kommunizieren .... viel zu viele fuzzis an den heimischen pc's kriegen die zähne nicht mehr auseinander und halten sich für die größten ...

Niemand zwingt einen auf eine normal gestellte Frage zu antworten

 

[Guest]

Unter einem Anfängerforum erwarte ich einfach ein Grundverständnis für Leute, die nicht den ganzen Tag zu Hause rumimplementieren und programmieren vielleicht nur als hobby ansehen ... soviel zum thema forschen ...

am besten wir forschen alle nur noch bis wir nicht mehr forschen können.. anstatt auch mal zu kommunizieren .... viel zu viele fuzzis an den heimischen pc's kriegen die zähne nicht mehr auseinander und halten sich für die größten ...

Niemand zwingt einen auf eine normal gestellte Frage zu antworten

Falls du der Ersteller des Threads bist, solltest du dir vielleicht nochmal alle Antworten durchlesen. Deine Frage wurde normal und zufriedenstellend beantwortet.
Und makis letzter Post galt nicht dir (mit dem forschen und nachplappern).

 

[maki]

>> Und makis letzter Post galt nicht dir (mit dem forschen und nachplappern).

Vielleciht sollte ich doch etwas höflicher schreiben...

 

[Wildcard]

Ist veraltet, stammt noch aus der Zeit als der Javacomiler nicht optimiert hat.

String + String ist noch genauso grausam wie schon vor Jahren. Klar wird mittlerweile StringBuilder verwendet, aber im Gegensatz zum Programmierer, kann der Compiler den richtigen Initialisierungszeitpunkt nicht finden.

Einfaches Beispiel (und jeder weiß wie wenig ich von Mikro Benchmarks halte, aber in diesem Fall ist der Unterschied einfach zu gravierend).

Erste Variante:

public class Test
{
    static int width = 20000;


    public static void main(String[] args)
    {
        long stamp = System.currentTimeMillis();
        StringBuilder s = new StringBuilder(10000);
        for (int i = 0; i < width; i++ )
        {
            s.append(i);
        }
        System.out.println(System.currentTimeMillis() - stamp);
    }
    
}

Dauert (dank Messungenauigkeit) 0ms.

Zweite Variante:

public class Test
{
    static int width = 20000;


    public static void main(String[] args)
    {
        long stamp = System.currentTimeMillis();
        String s = "";
        for (int i = 0; i < width; i++ )
        {
            s += i;
        }
        System.out.println(s);
        System.out.println(System.currentTimeMillis() - stamp);

    }
    
}

Dauert runde 5 Sekunden. Super optimiert :toll:

 

[Gast]

Ach Wildcard, die Ausnahme der Schleife wurde doch schon mehrfach erwähnt

Ansonsten gibt es doch keinen Grund so etwas zu schreiben:

"1".append("2").append("3");

Wenn es doch auch so geht:

"1"+"2"+"3";

und zwar ohne Performanceeinbussen

 

[tfa]

Was heißt Einbußen? Die 2. Variante ist viel schneller, das macht schon der Compiler.

 

[maki]

Naja, wo du recht hast...

 

[tfa]

sry, die Klugscheißeritis geht um

 

[maki]

Ich dachte das wäre Vorraussetzung um hier zu Posten

 

[ARadauer]

Der Müde Joe hat recht, auch rein aus SQM Sicht ist die Aussage von maki nicht sehr possitiv zu werten.
Natürlich kann man Strings mit + konkatenieren, sollte man jedoch immer darauf achten wie groß und umfangreich ein Projekt wird.
Und das mit der Lesbarkeit ist reine Geschmackssache!

Dir ist schon klar, dass die Konkatenation mit + vom Compiler in nichts anderes als StringBuilder (bzw. früher StringBuffer) umgewandelt wird? Und was hat das mit QM zu tun?

das wär mir neu...

 

[Noctarius]

Also ich behaupte auch der Java Compiler ist einer der itelligentesten wenns ums Optimieren von Sourcecode geht, aber dass er aus einen + - Konkatinator einen StringBuilder macht wäre auch mir neu aber das könnte man im Sourcecode vom Compiler nachsehen

 

[tfa]

Sieh dir doch einfach den Bytecode von was "+"-konkateniertem an.

 

[Noctarius]

Ok kann ich machen und wenn mein Bytecode anders aussehen sollte als deiner, weil du:
1. eine andere javac Version benutzt
2. z.B. nicht unter einem 64Bit Linux arbeitest (und somit die SUN VM toll arbeitet - ich benutz für GUI Anwendungen die IBM Version - ergo anderes javac)
3. du Kaffe oder was auch immer benutzt

Sich auf "Etwas" zu verlassen, dass nicht 100% klar definiert ist halte ich für reine Faulheit - sorry aber so sehe ich das ^^

Wenn du dem Compiler sagst was er machen soll, bekommst du auch in jedem Fall das gewünschte Ergebnis.

Aber abgesehen davon finde ich persönlich auch oft ein + übersichtlicher als ewiges append(...).

Kommt auch ein wenig auf die Anwendung an ob es wirklich einen merklichen Unterschied macht oder nicht.

 

[Wildcard]

Also ich behaupte auch der Java Compiler ist einer der itelligentesten wenns ums Optimieren von Sourcecode geht, aber dass er aus einen + - Konkatinator einen StringBuilder macht wäre auch mir neu aber das könnte man im Sourcecode vom Compiler nachsehen

Welche Wahl gibt es denn noch? Nur noch String#concat, in beiden Fällen wäre eine Umwandlung notwendig und es kommt sowieso fast auf das Gleiche raus.

 

[Noctarius]

Um das Thema von neulich aufzugreifen:
Java native Implementierung der Runtime Die sieht bei IBM bestimmt an einigen Stellen anders aus als bei SUN *einfach mal so behauptet* *gg*

 

[Wildcard]

Java native Implementierung der Runtime Die sieht bei IBM bestimmt an einigen Stellen anders aus als bei SUN *einfach mal so behauptet* *gg*

Klar sieht die anders aus. Genaus wie zig andere VMs anders aussehen. Hat damit aber null komma nichts zu tun. Nach dem kompilieren gibt es kein String + String mehr, dass muss auf Klassen und Methoden der J2SE umgebogen werden, sonst würde ein IBM Kompilat ja auf keiner anderen VM mehr funkionieren und dann dürfte es sich auch nicht mehr Java Compiler nennen.

 

[maki]

Das IBM so rückständig ist würde mcih zwar nicht überraschen, aber ein bisschen verwundern.
Welche Version des IBM Compilers ist das denn?

Hier noch der erwähnte Artikel:
http://java.sun.com/developer/technicalArticles/Interviews/community/kabutz_qa.html

 

[tfa]

Ok kann ich machen und wenn mein Bytecode anders aussehen sollte als deiner, weil du:
1. eine andere javac Version benutzt
2. z.B. nicht unter einem 64Bit Linux arbeitest (und somit die SUN VM toll arbeitet - ich benutz für GUI Anwendungen die IBM Version - ergo anderes javac)
3. du Kaffe oder was auch immer benutzt

Ich versteh jetzt dein Problem nicht. Davon abgesehen, dass es kaum andere Möglichkeiten für eine Stringkonkatenation gibt (siehe Wildcard), ist mir noch nie ein Compiler untergekommen, der das anders macht. Selbst jikes zu Java 1.1-Zeiten arbeitete so. Das ist natürlich kein Beweis, dass das immer so sein muss. ABer wieso sollte man die einfachste (und bewährte) Methode ändern?

Sich auf "Etwas" zu verlassen, dass nicht 100% klar definiert ist halte ich für reine Faulheit - sorry aber so sehe ich das ^^

Wenn du dem Compiler sagst was er machen soll, bekommst du auch in jedem Fall das gewünschte Ergebnis.

Ich verlass mich nur darauf, dass String + String genau das macht, was in der JLS steht.

Aber abgesehen davon finde ich persönlich auch oft ein + übersichtlicher als ewiges append(...).

Das sehe ich absolut genau so.

 

[homer65]

Ich mache meistens auch String x += String y. Mag sein, das sowas nicht so performant ist. Aber meistens sind es doch nur Performance Peanuts. Kommt halt drauf an.

 

[didjitalist]

wie schon oft genug erwähnt in diesem thread, man sollte immer dann auf StringBuilder setzen, wenn man strings innerhalb einer schleife zusammensetzt. für alle anderen zwecke ist String + String gut genug, wenn nicht sogar in der performance identisch.

 

[Noctarius]

Ok kann ich machen und wenn mein Bytecode anders aussehen sollte als deiner, weil du:
1. eine andere javac Version benutzt
2. z.B. nicht unter einem 64Bit Linux arbeitest (und somit die SUN VM toll arbeitet - ich benutz für GUI Anwendungen die IBM Version - ergo anderes javac)
3. du Kaffe oder was auch immer benutzt

Ich versteh jetzt dein Problem nicht. Davon abgesehen, dass es kaum andere Möglichkeiten für eine Stringkonkatenation gibt (siehe Wildcard), ist mir noch nie ein Compiler untergekommen, der das anders macht. Selbst jikes zu Java 1.1-Zeiten arbeitete so. Das ist natürlich kein Beweis, dass das immer so sein muss. ABer wieso sollte man die einfachste (und bewährte) Methode ändern?

Sich auf "Etwas" zu verlassen, dass nicht 100% klar definiert ist halte ich für reine Faulheit - sorry aber so sehe ich das ^^

Wenn du dem Compiler sagst was er machen soll, bekommst du auch in jedem Fall das gewünschte Ergebnis.

Ich verlass mich nur darauf, dass String + String genau das macht, was in der JLS steht.

Aber abgesehen davon finde ich persönlich auch oft ein + übersichtlicher als ewiges append(...).

Das sehe ich absolut genau so.

Kein Problem - nur keine feststehende Definition, dass genau das hier behauptete rauskommen muss. Wenns einer nativ in seiner VM implementiert tut er es eben. Es steht im vollkommen frei. Möglich dass auch alle derzeit intern auf StringBuilder (bzw früher StringBuffer) zurückgreifen, aber da es nicht klar von SUN so definiert ist (bzw in einem JCR) kann man halt nicht zwangsweise davon ausgehen, dass es so sein muss.

Und das IBM das anders macht hab ich nicht behauptet, ich habe lediglich gesagt, dass es hier anders sein könnte Vergleich gibt's nicht weil ich mir den IBM VM Code noch nie angesehen habe. War lediglich ein Ansatzpunkt einer Erklärung.

 

[Wildcard]

Nein. Das entscheidet nicht die VM, sondern der Compiler, und der muss gemäß Spezifikation kompatiblen Bytecode produzieren, da SUN sonst die Prozesskeule auspackt. Da hat sich schon Microsoft die Finger dran verbrannt...