© Excellent backgrounds/Shutterstock.com
Java Magazin
Warum sich das Warten auf Textblöcke in Java gelohnt hat

Was lange währt, wird endlich gut

Lange Zeit mussten Java-Entwickler beim Formulieren von mehrzeiligen String-Literalen unschöne Umwege nehmen, während sie neidisch zu Scala, Kotlin, Groovy und anderen Sprachen schielten. Mit JEP 355 halten Textblöcke nun als Vorschau in Java 13 Einzug.

Tim Zöller


String-Literale in Java-Code zu schreiben, über mehrere Zeilen und unter Umständen mit Whitespace formatiert, ist für viele Entwickler ärgerlich. Um z. B. ein SQL Statement im Code übersichtlich über mehrere Zeilen zu formatieren, ist die Nutzung des +-Operators mit händisch eingefügten Zeilenumbrüchen am Ende üblich (Listing 1). Um festzustellen, dass die meisten Sprachen die Fähigkeit zu ordentlich formatierten String-Literalen bereits enthalten, muss man sich nur Groovy, Scala und Kotlin anschauen. Andere höhere Programmiersprachen wie C#, Swift oder Python stehen dem in nichts nach. Bei einer so hohen Anzahl an Vorbildern ist es möglich, die besten Eigenschaften der Umsetzungen für Java zu adaptieren. Das lässt sich am JEP 326 für Raw String Literals erkennen, ursprünglich für Java 12 vorgesehen. Die Community hatte viele Anmerkungen und Einwände, woraufhin der Vorschlag zurückgezogen wurde [1]. JEP 355 hat viele der Anmerkungen berücksichtigt und ermöglicht nun Entwicklern ab Java 13, auf einfache Art Multi-line-Strings im Code zu definieren. Das Feature hält im JDK 13 zunächst als Vorschau Einzug – wer es nutzen möchte, muss seinen Code also mit dem Flag --enable-preview kompilieren.

Listing 1String statement = "SELECT\n" + " c.id,\n" + " c.firstname,\n" + " c.lastName,\n" + " c.customernumber\n" + "FROM customers c;";

JEP 326: Raw Strings

Um einige der Designentscheidungen für Text Blocks besser einordnen zu können, lohnt sich ein Blick auf den zurückgezogenen JEP 326 [2]. Dieser hatte das JDK 12 als Ziel und sah vor, Raw Strings in Java einzuführen – Zeichenfolgen, die sich über mehrere Zeilen erstrecken können und keine Escape-Sequenzen interpretieren. Um möglichst flexibel und unabhängig vom enthaltenen Text funktionieren zu können, wurde als Begrenzungssequenz eine beliebige Anzahl von Backquotes (`) vorgeschlagen. Enthält der String selbst einen Backquote, müsste die Begrenzungssequenz mindestens zwei enthalten. Enthält die Sequenz zwei aufeinanderfolgende Backquotes, hätte die Begrenzungssequenz zumindest drei usw. In der Ankündigung, dass der JEP zurückgezogen wird, erwähnt Brian Goetz einige Kritikpunkte aus der Community, die zu dieser Entscheidung geführt haben. Viele Entwickler befürchteten, die variable Anzahl an Zeichen in der Begrenzungssequenz könne für Menschen und Entwicklungsumgebungen verwirrend sein. Außerdem wurde Kritik daran laut,...

Java Magazin
Warum sich das Warten auf Textblöcke in Java gelohnt hat

Was lange währt, wird endlich gut

Lange Zeit mussten Java-Entwickler beim Formulieren von mehrzeiligen String-Literalen unschöne Umwege nehmen, während sie neidisch zu Scala, Kotlin, Groovy und anderen Sprachen schielten. Mit JEP 355 halten Textblöcke nun als Vorschau in Java 13 Einzug.

Tim Zöller


String-Literale in Java-Code zu schreiben, über mehrere Zeilen und unter Umständen mit Whitespace formatiert, ist für viele Entwickler ärgerlich. Um z. B. ein SQL Statement im Code übersichtlich über mehrere Zeilen zu formatieren, ist die Nutzung des +-Operators mit händisch eingefügten Zeilenumbrüchen am Ende üblich (Listing 1). Um festzustellen, dass die meisten Sprachen die Fähigkeit zu ordentlich formatierten String-Literalen bereits enthalten, muss man sich nur Groovy, Scala und Kotlin anschauen. Andere höhere Programmiersprachen wie C#, Swift oder Python stehen dem in nichts nach. Bei einer so hohen Anzahl an Vorbildern ist es möglich, die besten Eigenschaften der Umsetzungen für Java zu adaptieren. Das lässt sich am JEP 326 für Raw String Literals erkennen, ursprünglich für Java 12 vorgesehen. Die Community hatte viele Anmerkungen und Einwände, woraufhin der Vorschlag zurückgezogen wurde [1]. JEP 355 hat viele der Anmerkungen berücksichtigt und ermöglicht nun Entwicklern ab Java 13, auf einfache Art Multi-line-Strings im Code zu definieren. Das Feature hält im JDK 13 zunächst als Vorschau Einzug – wer es nutzen möchte, muss seinen Code also mit dem Flag --enable-preview kompilieren.

Listing 1String statement = "SELECT\n" + " c.id,\n" + " c.firstname,\n" + " c.lastName,\n" + " c.customernumber\n" + "FROM customers c;";

JEP 326: Raw Strings

Um einige der Designentscheidungen für Text Blocks besser einordnen zu können, lohnt sich ein Blick auf den zurückgezogenen JEP 326 [2]. Dieser hatte das JDK 12 als Ziel und sah vor, Raw Strings in Java einzuführen – Zeichenfolgen, die sich über mehrere Zeilen erstrecken können und keine Escape-Sequenzen interpretieren. Um möglichst flexibel und unabhängig vom enthaltenen Text funktionieren zu können, wurde als Begrenzungssequenz eine beliebige Anzahl von Backquotes (`) vorgeschlagen. Enthält der String selbst einen Backquote, müsste die Begrenzungssequenz mindestens zwei enthalten. Enthält die Sequenz zwei aufeinanderfolgende Backquotes, hätte die Begrenzungssequenz zumindest drei usw. In der Ankündigung, dass der JEP zurückgezogen wird, erwähnt Brian Goetz einige Kritikpunkte aus der Community, die zu dieser Entscheidung geführt haben. Viele Entwickler befürchteten, die variable Anzahl an Zeichen in der Begrenzungssequenz könne für Menschen und Entwicklungsumgebungen verwirrend sein. Außerdem wurde Kritik daran laut,...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang