Trennzeichen

darksmilie · 22. Juni 2006

Gibt es in Java eine Trennzeichen, damit ich in einer Stringvariablen ein zeilenumbruch machen kann. Der Sting ist sonst zu lang und ich müsste immer weit nach rechts scrollen.

terravotion · 22. Juni 2006

Code:

private String string = "Hallo ich blablablablalba. \n
                                 BlaBlaBlaBla";

\n ist dein Freund würde ich mal sagen.

darksmilie · 22. Juni 2006

heißt \n nicht zeilenumbruch?

ich meine eher ich habe ein ganz langen String und ich möchte diese eine zeile im code auf mehrere aufteilen, wie bei php mit dem zeichen .was dann immer vor der nächsten zeile steht.

also ich habe:

Code:

String bla = "blablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablabla"

würde das aber gerne so haben:

Code:

String bla = "blablablablabla
blablablablabla
blablablablabla
blablablablabla
blablablablabla
blablablablabla
blablabla"

und dafür brauch ich ein Trennzeichen, damit der Compiler weiß, dass das alles zu der Variable gehört

javaprogger1987 · 22. Juni 2006

Stringverkettung in Java mit + ^^

Java:

String test = "test" + "test" + "test" +
"test" + "test";

Nur aus Performancegründen solltest du das lieber unformatiert lassen

Gruß
Tobias

darksmilie · 22. Juni 2006

Herzlichen Dank

yves030 · 22. Juni 2006

Nur by the way.... abseits von Codeformatting und Style-Themen...:

...wenn es darum geht, zur Laufzeit einen String zu konstruieren, der sich aus mehreren TeilStrings zusammensetzt, solltest Du lieber auf die Klasse StringBuffer zurückgreifen. Das macht sich bei großen Strings (ich spreche hier nicht von Zweizeilern sondern von Strings > 20Kb und mehreren zig Konkatenationsanweisungen...) extrem (ca. Faktor 5 bis 10) bemerkbar!

y.

Thomas Darimont · 22. Juni 2006

Hallo!

...wenn es darum geht, zur Laufzeit einen String zu konstruieren, der sich aus mehreren TeilStrings zusammensetzt, solltest Du lieber auf die Klasse StringBuffer zurückgreifen. Das macht sich bei großen Strings (ich spreche hier nicht von Zweizeilern sondern von Strings > 20Kb und mehreren zig Konkatenationsanweisungen...) extrem (ca. Faktor 5 bis 10) bemerkbar!

Diese Regel gilt nur noch bedingt...
Seit Java 5 wird eine String Konkatentation ueber '+' so abgebildet:

Java:

/**
 * 
 */
package de.tutorials;

import java.util.Arrays;

/**
 * @author Tom
 *
 */
public class StringConcatenationExample {

    /**
     * @param args
     */
    public static void main(String[] args) {
        String s = "abc";
        s += s + Integer.MAX_VALUE + new Object() + Arrays.asList(new Object[]{"a","b","c"});
        System.out.println(s);
    }

}

Resultiert in folgendem java Code:

Java:

// Decompiled by DJ v3.7.7.81 Copyright 2004 Atanas Neshkov  Date: 6/22/2006 2:30:03 PM
// Home Page : http://members.fortunecity.com/neshkov/dj.html  - Check often for new version!
// Decompiler options: packimports(3) 
// Source File Name:   StringConcatenationExample.java

package de.tutorials;

import java.io.PrintStream;
import java.util.Arrays;

public class StringConcatenationExample
{

    public StringConcatenationExample()
    {
    }

    public static void main(String args[])
    {
        String s = "abc";
        s = (new StringBuilder(String.valueOf(s))).append(s).append(0x7fffffff).append(new Object()).append(Arrays.asList(new Object[] {
            "a", "b", "c"
        })).toString();
        System.out.println(s);
    }
}

Java 1.4 verwendet hier "aehnlich" geschickt einen StringBuffer.

Das ist nur ein Beispiel dafuer, dass die alten Java Performance Mythen bei den aktuellen Java Versionen nicht mehr zutreffen mehr dazu gibts hier:
http://www-128.ibm.com/developerworks/java/library/j-jtp04223.html
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-lnxw01JavaUrbanLegends

Gruss Tom

yves030 · 22. Juni 2006

Hi Tom,

bei der Suche nach einem Performanceleck in einer Servletbasierenden Webanwendung bin ich auf dieses Problem gestoßen.... da wurde die ganze Seite in einen bzw. mehrere Strings "gerendert", die dann auf einmal ausgegeben wurden... Bei normalen Seiten fiel das nicht ins Gewicht.... aber bei komplexeren Inhalten, die große Tabellen zur Folge hatten, deren Inhalt sich durch Iteration einer Schleife (über eine SQL-Abfrage z.B.) zusammensetzte kamen da enorme Einbußen zustande... diese simple Änderung brachte quasi einen Turbo...
Mich verwunderte Deine Aussage, weil ich mir sicher war, daß die damalige Anwendung schon mit einer 5er Release lief und daher habe ich mal folgenden Test gemacht:

Code:

public class StringPerfTest {

        System.out.println("Java-Version :"+System.getProperty("java.vm.version")+" ("+System.getProperty("java.vm.vendor")+")");
        String testString = "";
        long start = 0;
        long stop = 0;

        start = System.currentTimeMillis();
        for (int i=0;i<2000;i++)
            testString += "i hat den Wert: "+ i + "\n";
        stop = System.currentTimeMillis();

        System.out.println("Test 1 dauerte "+(stop-start)+" mS.\n");

        StringBuffer testBuffer = new StringBuffer();

        start = System.currentTimeMillis();
        for (int i=0;i<2000;i++)
            testBuffer.append("i hat den Wert: "+ i + "\n");
        stop = System.currentTimeMillis();

        System.out.println("Test 2 dauerte "+(stop-start)+" mS.\n");
    }
}

Bringt unter einer 5er JRE:

Code:

Java-Version :1.5.0_06-b05 (Sun Microsystems Inc.)
Test 1 dauerte 953 mS.

Test 2 dauerte 1 mS.

und unter einer 4er JRE:

Code:

Java-Version :1.4.2_10-b03 (Sun Microsystems Inc.)
Test 1 dauerte 656 mS.

Test 2 dauerte 1 mS.

Ich sehe da also von Version 4 auf Version 5 Performanceeinbußen in Punkto Stringhandling.... ganz zu schweigen, daß die Geschichte mit dem StringBuffer rund 1000mal schneller ist... oder unterliege ich hier einem Denkfehler?

y.

Thomas Darimont · 22. Juni 2006

Hallo!

Der Eclipse JDT Compiler generiert aus deinem Beispiel folgenden Java Code:

Java:

// Decompiled by DJ v3.7.7.81 Copyright 2004 Atanas Neshkov  Date: 6/22/2006 3:29:17 PM
// Home Page : http://members.fortunecity.com/neshkov/dj.html  - Check often for new version!
// Decompiler options: packimports(3) 
// Source File Name:   StringPerfTest.java

package de.tutorials;

import java.io.PrintStream;

public class StringPerfTest
{

    public StringPerfTest()
    {
    }

    public static void main(String args[])
    {
        System.out.println((new StringBuilder("Java-Version :")).append(System.getProperty("java.vm.version")).append(" (").append(System.getProperty("java.vm.vendor")).append(")").toString());
        String testString = "";
        long start = 0L;
        long stop = 0L;
        start = System.currentTimeMillis();
        for(int i = 0; i < 2000; i++)
            testString = (new StringBuilder(String.valueOf(testString))).append("i hat den Wert: ").append(i).append("\n").toString();

        stop = System.currentTimeMillis();
        System.out.println((new StringBuilder("Test 1 dauerte ")).append(stop - start).append(" mS.\n").toString());
        StringBuffer testBuffer = new StringBuffer();
        start = System.currentTimeMillis();
        for(int i = 0; i < 2000; i++)
            testBuffer.append((new StringBuilder("i hat den Wert: ")).append(i).append("\n").toString());

        stop = System.currentTimeMillis();
        System.out.println((new StringBuilder("Test 2 dauerte ")).append(stop - start).append(" mS.\n").toString());
    }
}

Das Problem bei dem ersten Lauf sind die die vielen String Objekte die nacheinander erzeugt werden. Da jedes mal ein neuer StringBuffer erzeugt wird, dem dann die entsprechenden Zeichenketten angehaengt werden. Anschliessend wird die String Repraesentation des StringBuilders erzeugt und diese im naechsten Durchgang als Basis fuer den neuen StringBuilder verwendet.

Am schnellsten waere diese Variante:

Java:

        testBuffer = new StringBuffer();
        start = System.currentTimeMillis();
        for (int i = 0; i < 2000; i++)
            testBuffer.append("i hat den Wert: ").append(i).append("\n");
        stop = System.currentTimeMillis();
        System.out.println("Test 3 dauerte " + (stop - start) + " mS.\n");

Ausserdem schrieb ich ja:

Diese Regel gilt nur noch bedingt...

Wenn man einmalig (oder sehr selten) eine groessere String Verkettung durchfuehrt reicht der + Operator IMHO vollkommen aus. Wenn man jedoch einen Anwendungsfall hat bei dem diese Verkettung sehr haeufig geschieht, dann sollte man auf die StringBuilder, StringBuffer Variante zurueckgreiffen.

Ich wollte damit nur zum ausdruck bringen, dass sich in Sachen String Verkettung seit Java 1.3 etwas getan hat:
Java 1.4: "geschickte Verwendung von StringBuffer"
Java 1.5 "geschickte Verwendung von StringBuilder" -> StringBuilder ist die nicht synchronized Varainte von StringBuffer.

Gruss Tom

yves030 · 22. Juni 2006

yip... ich meinte ja auch abseits von codystyling und für seeeeehr große, dynamisch generierte Strings... und führte als Beispiel eben den Fall an, wo aus einer SQL-Abfrage heraus dynamisch ein "großer" String generiert wird...

Was ich aber nach wie vor komisch finde, ist die Tatsache, das das unter 1.4 erzeugte Klässlein erheblich schneller läuft als das mit der 1.5 erzeugten...

Mal sehen, was uns der mustang da bringen wird....

y.

Trennzeichen

darksmilie

Erfahrenes Mitglied

terravotion

Erfahrenes Mitglied

darksmilie

Erfahrenes Mitglied

javaprogger1987

Erfahrenes Mitglied

darksmilie

Erfahrenes Mitglied

yves030

Mitglied

Thomas Darimont

Erfahrenes Mitglied

yves030

Mitglied

Thomas Darimont

Erfahrenes Mitglied

yves030

Mitglied

Neue Beiträge