https://www.oracle.com/java/technologies/downloads/#JDK17
https://adoptium.net/ schreibt bisher nur:
14th Sept 2021 The Eclipse Temurin 17 GA Release Train has started!
You can track progress by platform or by detailed release checklist.
So wird es vorgeschlagen: https://mreinhold.org/blog/forward-even-faster.
So, let’s ship an LTS release every two years.
Quelle: https://www.slideshare.net/Pivotal/building-layers-of-defense-for-your-application?next_slideshow=1
Interessantes Feature, was die Javadoc doch dicker machen könnte. Geplant:
/**
* The following code shows how to use {@code Optional.isPresent}:
* {@snippet :
* if (v.isPresent()) {
* System.out.println("v: " + v.get());
* }
* }
*/
Interessant wird das ganze durch Includes (wie bei Asciidoc):/**
* The following code shows how to use {@code Optional.isPresent}:
* {@snippet file="ShowOptional.java" region="example"}
*/Dinge können zum Beispiel fett hervorgehoben werden:
/**
* A simple program.
* {@snippet :
* class HelloWorld {
* public static void main(String... args) {
* System.out.println("Hello World!"); // @highlight substring="println"
* }
* }
* }
*/Und Texte können ersetzt werden:
/**
* A simple program.
* {@snippet :
* class HelloWorld {
* public static void main(String... args) {
* System.out.println("Hello World!"); // @replace regex='".*"' replacement="..."
* }
* }
* }
*/Ziemlich wild, würdet ihr so was nutzen für eure Javadoc? Ich nutzte bisher immer Testfälle, um eine API zu zeigen und auch zu lernen.
Zum Weiterlesen: https://openjdk.java.net/jeps/413
Ankündigung unter https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6:
As announced at SpringOne yesterday, Spring Framework 6 and Spring Boot 3 are planned towards a high-end baseline for their general availability in Q4 2022:
- Java 17+ (from Java 8-17 in the Spring Framework 5.3.x line)
- Jakarta EE 9+ (from Java EE 7-8 in the Spring Framework 5.3.x line)
This forward-looking baseline will provide significant benefits in our API design and integration efforts, shining through to your application code and future-proofing the framework as well as your applications for many years to come. However, it comes at a cost, of course: Spring Framework 6 and Spring Boot 3 based applications will require a minimum of JDK 17 at runtime, as well as a minimum of Tomcat 10 / Jetty 11 (for Jakarta EE 9 compatibility). Even more importantly, there might be some changes required in your application source code: e.g. the javax to jakarta namespace change in Jakarta EE 9 wherever you’re touching the Servlet API, JPA, Bean Validation, etc.
While this may sound aggressive at first, keep in mind that we’re talking about a Q4 2022 release: By that time, not only will JDK 17 have superseded JDK 11 as the next Long-Term Support release for more than a year, it will itself have been superseded by JDK 18 and JDK 19 as then-available feature releases, with JDK 20 approaching its feature freeze already. Same for Jakarta EE 9: We expect Jakarta EE 10 to be out by then, and yet another generation of Tomcat, Jetty and co to be supported as runtime options. Keeping up the baseline above as a minimum, this allows for picking up further Java evolution in the Spring Framework 6.x generation, with Java 17 and Jakarta EE 9 only being the start.
Nächstes Jahr beginne ich mit einem neuen Buch; Thema: Spring Boot 3 und Spring Framework 6. Mit Rheinwerk haben wir uns überlegt, dass wir uns ein Spring Boot 2.x Buch sparen, daher wird es erst in rund 14 Monaten etwas.
Wer Probeleser*in sein möchte, bitte melden. Die ersten fertigen Kapitel gibt es vermutlich in ca. 1/2 Jahr.
Aus den Release-Notes: https://github.com/querydsl/querydsl/releases/tag/QUERYDSL_5_0_0:
This release of QueryDSL targets Java 8 minimally and comes with various improvements to make QueryDSL ready for the modern Java ecosystem.
This version also removes joda-time:joda-time, com.google.guava:guava and com.google.code.findbugs:jsr305 as required runtime dependencies for using QueryDSL.
QueryDSL 5.0 is the long awaited major release after the QueryDSL project was left mostly unmaintained for over two years.
Fetchable#stream() which returns a Stream<T>.forEach, collect).joda-time:joda-time is no longer a required dependency for querydsl-sql.joda-time:joda-time types will still be registered automatically if they are on the classpath.com.querydsl.core.alias.Alias.* to be used on a JRE by relying on ECJ as compilerJPAExpressions#treat which can be used to generate JPA 2.1 Treated path expressions.querydsl-collections.querydsl-spatialHibernateDomainExporter and JPADomainExporter.jakarta classifiers for Maven)nullif and coalesce methods.Wie ist denn der Einsatz bei euch von QueryDSL? Eine wichtiger Baustein in eurer Unternehmensanwendung?
So sagt es https://openjdk.java.net/projects/jdk/17/#Schedule.
Download wie bisher unter https://jdk.java.net/17/. Bei Adoptium müssen wir noch warten.
Das AdoptOpenJDK ist zur Eclipse Foundation gewandert und hat jetzt die Webseite live geschaltet: https://adoptium.net/.
Auf kurz oder lang wird es die vorherrschende Distribution werden.
Das javax.xml.bind-Paket bietet eine Klasse DatatypeConverter, die eigentlich für die Abbildung von XML-Typen auf Java-Typen gedacht ist, doch auch so einige nützliche Methoden bereitstellt. Wir finden in der Klasse statische parse*(String)-Methoden und print*(…)-Methoden: Die ersten konvertieren einen String in diverse Datentypen – etwa short parseShort(String) –, und die zweiten formatieren einen bestimmten Datentyp in einen String – etwa String printShort(short). Für die meisten Methoden gibt es mit String.valueOf(…) und den parse*(…)/toString(…)-Methoden in den Wrapper-Klassen bessere Alternativen, und die Umwandlung von Datumswerten und Fließkommazahlen ist nicht lokalisiert, doch hervorzuheben sind folgende zwei Methoden:
final class javax.xml.bind.DatatypeConverter
Mit diesen statischen Methoden können leicht Byte-Arrays in die String-Repräsentationen hexadezimal konvertiert werden. Das ist nötig, wenn etwa Bytes in einer Text-Konfigurationsdatei abgelegt werden sollen. DatatypeConverter bietet auch Methoden für eine Base64-Kodierung, allerdings sind die geschachtelten Klassen in java.util.Base64 üblicher.
Beispiel:
Konvertiere ein Byte-Array in eine String-Repräsentation, einmal im klassischen Hex-Format, einmal in Base64-Kodierung:
byte[] bytes = { 1, 2, 3, (byte) 254, (byte) 255 };
String s1 = DatatypeConverter.printHexBinary( bytes );
String s2 = DatatypeConverter.printBase64Binary( bytes );
System.out.println( s1 ); // 010203FEFF
System.out.println( s2 ); // AQID/v8=
// Arrays.equals( bytes, DatatypeConverter.parseHexBinary( s1 ) ) == true
// Arrays.equals( bytes, DatatypeConverter.parseBase64Binary( s2 ) ) == true
Zwischen Java 1.2 und Java 16 unterstützte der Java-Compiler das Schlüsselwort strictfp. Die Unterscheidung sollte es der Laufzeitumgebung erlauben, nicht strikt nach der IEEE-754-Spezifikation zu arbeiten und damit schneller auf der lokalen Hardware Java-Programme auszuführen. Doch seit 20 Jahren unterstützen alle Prozessoren IEEE-754, und die Unterscheidung ist irrelevant geworden – alle von der JVM ausgeführten mathematischen Operationen sind wie im IEEE-754-Standard beschrieben. Mit dem Abschied von strictfp wird auch die Klasse StrictMath irrelevant.
Details: https://openjdk.java.net/jeps/306
Die Konstanten einer Schnittstelle können einer anderen Schnittstelle vererbt werden. Dabei gibt es einige kleine Einschränkungen. Wir wollen an einem Beispiel sehen, wie sich die Vererbung auswirkt, wenn gleiche Bezeichner in den Unterschnittstellen erneut verwendet werden. Die Basis unseres Beispiels ist die Schnittstelle BaseColors mit ein paar Deklarationen von Farben. Zwei Unterschnittstellen erweitern BaseColors, und zwar CarColors und PlaneColors, die für Farbdeklarationen für Autos und Flugzeuge stehen. Eine besondere Schnittstelle FlyingCarColors erweitert die beiden Schnittstellen CarColors und PlaneColors, denn es gibt auch fliegende Autos, die eine Farbe haben können.
interface BaseColors {
int WHITE = 0;
int BLACK = 1;
int GREY = 2;
}
interface CarColors extends BaseColors {
int WHITE = 1;
int BLACK = 0;
}
interface PlaneColors extends BaseColors {
int WHITE = 0;
int GREY = 2;
}
interface FlyingCarColors extends CarColors, PlaneColors { }
public class Colors {
public static void main( String[] args ) {
System.out.println( BaseColors.GREY ); // 2
System.out.println( CarColors.GREY ); // 2
System.out.println( BaseColors.BLACK ); // 1
System.out.println( CarColors.BLACK ); // 0
System.out.println( PlaneColors.BLACK ); // 1
System.out.println( FlyingCarColors.WHITE );
// field FlyingCarColors.WHITE is ambiguous
System.out.println( FlyingCarColors.GREY );
// field FlyingCarColors.GREY is ambiguous
}
}
Die erste wichtige Tatsache ist, dass unsere drei Schnittstellen ohne Fehler übersetzt werden können, aber nicht die Klasse Colors. Das Programm und der Compiler zeigen folgendes Verhalten:
Mein neues Java-Buch, voraussichtlich März 2021. Details unter https://www.rheinwerk-verlag.de/captain-ciaociao-erobert-java/.
Details siehe https://blog.jetbrains.com/idea/2020/12/intellij-idea-2020-3/.
Eine Vorschau über einige Features in dem Video:
Details siehe https://github.com/spring-projects/spring-boot/releases/tag/v2.4.1
Veränderungen in der Verfügbarkeit des Java Development Kit seit dem Release des JDK 11 im September 2018 erschweren den sicheren Betrieb von Java-Anwendungen für viele Endnutzer. Die Nutzung des Oracle JDK ist im kommerziellen IT Betrieb nun nur noch mit Lizenz möglich.
Azul Systems tritt an, mit der Zulu OpenJDK Laufzeitumgebung eine wirtschaftlich attraktive Java-Distribution mit zuverlässigen Updates und Bug Fixes anzubieten.
2006 hat Sun Microsystems, zu diesem Zeitpunkt der Inhaber der Marke Java, angekündigt das JDK in ein Open-Source Projekt zu überführen. Zu diesem Zweck wurde das OpenJDK Projekt in Leben gerufen, das ein Zuhause auf http://openjdk.java.net fand. Beginnend mit dem JVM Source Code wurden bis Anfang 2007 auch die Kernbibliotheken veröffentlicht. Einige Teile des OpenJDK blieben bis April 2009 proprietär, bis mit build 53 des OpenJDK 7 eine vollständig auf Open Source basierende Distribution verfügbar war. Seit Java 7 SE ist das OpenJDK die Referenzimplementierung des Java SE-Standards, der durch die entsprechenden Java Specification Requests (JSR) festgelegt wird. Ein Projekt mit dem Ziel einer Open Source Umsetzung von Java SE 6 wurde ebenfalls gestartet, geleitet von Andrew Brygin von Azul Systems. Das OpenJDK steht unter der GNU Public License (GPL) version 2 with classpath exception (CPE). Die Lizenzierung unter der CPE verhindert das die „copyleft“ Natur der GPL sich auf die Anwendungen auswirkt die das OpenJDK als Laufzeitumgebung nutzen. Im September 2007 hat Oracle zahlreiche Veränderungen bei der Art und Weise wie das JDK entwickelt, verbreitet und aktualisiert wird. Diese lassen sich wie folgt zusammenfassen:
Das OpenJDK ist ein reines Source Code Projekt. Um es als Java Laufzeitumgebung nutzen zu können ist es nötig, das Projekt in eine Binärdistribution zu kompilieren. Die von Azul erstellte Distribution trägt den Namen Zulu. Zulu wird, mit dem vom OpenJDK vorgegebenen Standard
Build Prozess erstellt und alle Binaries mit dem Technology Compatibility Kit (TCK) validiert, um Kompatibilität und Konformität mit der Java SE-Spezifikation sicherzustellen. Um die den stabilen und sicheren Betrieb bei den Kunden zu ermöglichen werden regelmäßige Updates für
das OpenJDK erstellt, die Bug Fixes und Security Patches enthalten. Bis zu Version 9 des JDK wurden diese Updates jeweils für die aktuelle Version und die vorhergehende Version bereitgestellt. Die Überlappung der Supportzeiträume seit JDK 6 betrug zwischen 13 und 37 Monate. Unter der neuen Release Policy sind jedoch bereits OpenJDK 6, 7, 8 und 11 aus dem öffentlichen und freien Support herausgefallen. Azul liefert auf weiterhin Updates für all diese JDK-Versionen. Dies erlaubt es den Kunden auch ältere Java-Versionen sicher im produktiven Betrieb zu nutzen.
Da das OpenJDK die Referenzimplementierung des Java SE-Standards darstellt, nutzen Oracle und andere es als Basis ihrer Binärdistributionen. Vor JDK 11 enthielt das Oracle JDK eine Reihe von
zusätzlichen Features, von denen einige nun Open Source sind, andere bleiben proprietär.
Anwender können bei der Planung des OpenJDK-Rollout folgenge Option in Betracht ziehen:
Das Zulu OpenJDK wird unter der GPLv2 with CPE Lizenz veröffentlicht. Zulu Binaries stehen für Windows, Linux, Solaris und MacOS X auf https://www.azul.com/downloads/zulu-community/ zum Download bereit. Auch Release Notes mit Installationsanleitung finden sich auf dieser Seite. Diese decken alle bereitgestellten Paketformate, Abhängigkeiten sowie Anleitungen für die Installation in gängigen Cloud Umgebungen wie Microsoft Azure und Amazon Web Services bereit. Enthalten sind auch Post-Installationsschritte und eine Anleitung wie die Standard Java Runtime auf einem Server/Desktop aus festgelegt werden kann.
Die proprietären Lucida Font aus dem Oracle JDK sind nicht Teil des Standard OpenJDK. Falls erforderlich stellt das Zulu Commercial Compatibility Kit (CCK)diese Fonts bereit, um in GUIs und PDF Generatoren ein identisches Layout und Schriftbild zu erhalten.
Zum Download des Zulu CCK müssen die Nutzungsbedingungen akzeptiert werden. Der Installer überprüft, ob eine passende Zulu-Version installiert ist. Beim Download ist auf die korrekte Version zu achten! Details und Download gibt es unter https://www.azul.com/products/zulu-and-zulu-enterprise/cck-downloads/. Dies ermöglicht in der Regel eine Migration ohne zusätzlich betriebliche Aufwände.
Zulu ist eine OpenJDK Distribution die vollumfänglich der Java SE-Spezifikation entspricht. Jede Anwendung, die auf Standard Java-Komponenten und APIs setzt, kann durch einen einfachen Austausch des JDK Pfads migriert werden. Ein engagiertes Entwicklerteam nimmt komplexe Anpassungen, wie Backporting und Integration von Updates in ältere OpenJDK-Versionen vor; daher können sich Azul-Kunden der aktuellsten Security-Patches und Bug-Fixes auch auf älteren Java-Versionen erfreuen.
Die Zulu OpenJDK-Distribution bietet eine kostengünstige Alternative, um Applikationen auf aktuelle Java Versionen zu migrieren und sicher zu betreiben.
Während Array.asList(...) nur ein Dektorator ist, der ein Array so aussehen lässt, als wäre es eine List, übertragen drei überladene Methoden toArray(...) aus Collection alle Elemente einer Sammlung auf eine Liste:
Object[] toArray()<T> T[] toArray(T[] a)default <T> T[] toArray(IntFunction<T[]> generator) (Java 11)Was ist das Ergebnis der Ausgabe?
List<String> list = new ArrayList<>( Arrays.asList( "a", "b" ) );
System.out.println( list.toArray()[ 0 ] );
System.out.println( list.toArray( new String[ 0 ] )[ 0 ] );
System.out.println( list.toArray( new String[ 0 ] ).length );
System.out.println( list.toArray( new String[ 1 ] )[ 0 ] );
System.out.println( list.toArray( new String[ 1 ] ).length );
System.out.println( list.toArray( value -> new String[ 1 ] )[ 0 ] );
System.out.println( list.toArray( value -> new String[ 1 ] ).length );
System.out.println( list.toArray().getClass() );
System.out.println( list.toArray( new String[ 0 ] ).getClass() );
Lösung .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
List<String> list = new ArrayList<>( Arrays.asList( "a", "b" ) );
System.out.println( list.toArray()[ 0 ] ); // a
System.out.println( list.toArray( new String[ 0 ] )[ 0 ] ); // a
System.out.println( list.toArray( new String[ 0 ] ).length ); // 2
System.out.println( list.toArray( new String[ 1 ] )[ 0 ] ); // a
System.out.println( list.toArray( new String[ 1 ] ).length ); // 2
System.out.println( list.toArray( value -> new String[ 1 ] )[ 0 ] ); // a
System.out.println( list.toArray( value -> new String[ 1 ] ).length ); // 2
System.out.println( list.toArray().getClass() ); // class [Ljava.lang.Object;
System.out.println( list.toArray( new String[ 0 ] ).getClass() ); // class [Ljava.lang.String;
Es hilft beim Verständnis sich den Code aus dem OpenJDK anzuschauen:
Aus der OpenJDK-Implementierung von java.util.ArrayList:
public Object[] toArray() {
return Arrays.copyOf( elementData, size );
}
Aus der OpenJDK-Implementierung von java.util.ArrayList:
public T[] toArray( T[] a ) {
if ( a.length < size ) // Make a new array of a’s runtime type, but my contents: return (T[]) Arrays.copyOf( elementData, size, a.getClass() ); System.arraycopy( elementData, 0, a, 0, size ); if ( a.length > size )
a[ size ] = null;
return a;
}
Aus der OpenJDK-Implementierung von java.util.Collection:
default T[] toArray( IntFunction generator) {
return toArray(generator.apply(0));
}
Details siehe https://spring.io/blog/2020/09/16/spring-tools-4-8-0-released. Kurz zusammengefasst:
Download der Spring Tools 4: https://spring.io/tools/
Strings mit einem Zeilenumbruch kommen in Programmen immer wieder vor, etwa bei Bildschirmausgaben, eingebettetem HTML, XML, JSON oder SQL. Ein Beispiel:
String joke =
"Lehrer: '76 % aller Schüler in dieser Klasse haben keine Ahnung von Prozentrechnung.'\n" +
"Schüler: 'Herr Lehrer, so viele sind wir doch gar nicht!'";
Im ersten String-Literal steht \n für den Zeilenumbruch. Das Pluszeichen setzt die beiden Strings zusammen. Der Java-Compiler stellt selbständig aus den beiden Konstanten ein größeres String Literal her.
In Java 15 wurden Textblöcke eingeführt (standardisiert im JEP 378: Text Blocks, https://openjdk.java.net/jeps/378). Damit lassen sich einfacher mehrzeilige Strings aufbauen. Drei doppelte Anführungszeichen leiten einen Textblock ein (opening delimiter genannt) und drei doppelte Anführungszeichen schließen einen Textblock wieder ab (closing delimiter genannt). Mithilfe von Textblöcken sieht unser Beispiel von oben so aus:
String joke = """
Lehrer: '76 % aller Schüler in dieser Klasse haben keine Ahnung von Prozentrechnung.'
Schüler: 'Herr Lehrer, so viele sind wir doch gar nicht!'""";
System.out.println( joke );
Ein Textblock wird immer mit drei doppelten Anführungszeichen eingeleitet, und ein Zeilenumbruch muss folgen. Das bedeutet automatisch, dass die Textblöcke immer mindestens zwei Quellcodezeilen umfassen, und niemals nur in eine Zeile geschrieben werden können.
Nach der Einleitung eines Textblocks hängt der Compiler an jede Zeile, die nicht mit drei Anführungszeichen abgeschlossen wird, einen Zeilenumbruch LINE-FEED, kurs LF (Unicode \u000A). In unserem Beispiel haben wir nur einen Zeilenumbruch. Hätten wir die drei Anführungszeichen in die nächste Zeile geschrieben, hätten wir zwei Zeilenumbrüche im Ergebnis:
String joke = """
Lehrer: '76 % aller Schüler in dieser Klasse haben keine Ahnung von Prozentrechnung.'
Schüler: 'Herr Lehrer, so viele sind wir doch gar nicht!'
""";
Es macht also einen Unterschied, ob die drei Anführungszeichen zum Schließen des Textblocks in einer eigenen Zeile stehen (der entstehende String endet mit einem LF) oder am Ende eines Strings (der entstehende String endet nicht mit einem LF). Beim Schreiben würde das sicherlich etwas symmetrischer und hübscher aussehen, wenn der Beginn eines Textblocks und das Ende eines Textblocks jeweils in einer einzelnen Zeile stehen würden, doch das können wir nicht immer machen, denn das ergibt immer am Ende einen Zeilenumbruch, der vielleicht nicht gewünscht ist.
Textblöcke sind eine alternative Schreibweise für Strings in doppelten Anführungszeichen. Im Bytecode ist später nicht mehr zu erkennen, auf welche Art und Weise der String entstanden ist. Textblöcke können genauso wie reguläre Strings an allen Stellen eingesetzt werden, an denen Strings gefordert werden, etwa als Argument:
System.out.println( """
Lehrer: '76 % aller Schüler in dieser Klasse haben keine Ahnung von Prozentrechnung.'
Schüler: 'Herr Lehrer, so viele sind wir doch gar nicht!'""" );
Ist im Quellcode innerhalb vom Textblock ein Zeilenumbruch sinnvoll, damit z. B. die Zeile nicht so lang wird, lässt sich mit einem Backslash der Zeilenumbruch im Ergebnisstring verhindern:
String joke2 = """
Warum haben Giraffen so einen langen Hals? \
Weil der Kopf so weit oben ist.""";
// Warum haben Giraffen so einen langen Hals? Weil der Kopf so weit oben ist.
System.out.println( joke2 );
Da Textblöcke Strings sind, lassen sie sich auch mit dem +-Operator konkatenieren:
String person1 = "Lehrer", person2 = "Schüler";
String joke = person1 +
"""
: '76 % aller Schüler in dieser Klasse haben keine Ahnung von Prozentrechnung.'
""" + person2 + """
: 'Herr Lehrer, so viele sind wir doch gar nicht!'""";
System.out.println( joke );
Es lässt sich ablesen, dass das Einsetzen von Variableninhalten nicht besonders elegant ist — das war allerdings nicht das Ziel der Textblöcke gewesen, so etwas wie String-Interpolation zu schaffen, was etwa JavaScript kann. Etwas zur Hilfe kommt die String-Methode formatted(…), die als Objektmethode hinzugekommen ist:
String person1 = "Lehrer", person2 = "Schüler";
String joke = """
%s: '76 %% aller Schüler in dieser Klasse haben keine Ahnung von Prozentrechnung.'
%s: 'Herr Lehrer, so viele sind wir doch gar nicht!'""".formatted( person1, person2 );
System.out.println( joke );
Die Einrückung der Zeilen in einem Textblock spielt eine elementare Rolle. Die Zeilen eines Textblocks müssen nicht ganz links am Anfang einer Zeile bei der Position 0 beginnen, sondern dürfen rechts eingerückt sein und den üblichen Konventionen in der Einrückung von Java Programmen folgen. Bei der Einrückung sollte beiläufiger Weißraum (engl. incidental white space) aus dem eigentlichen Textblock ausgenommen werden. Hier wendet der Java-Compiler einen kleinen Algorithmus an. Die Regel ist, dass die Zeile die am weitesten links steht (die Zeile mit dem drei abschließenden Anführungszeichen gehört dazu) den beiläufigen Weißraum bestimmt, der abgeschnitten wird. Es ist dabei egal, ob das Zeichen ein Tabulator oder Leerzeichen ist, auch wenn das auf dem Bildschirm anders aussieht! Bestehen bleibt rechts von dieser Stelle der wesentliche Weißraum (engl. essential white space).
Beispiel 1:
String joke2 = """
Warum haben Giraffen so einen langen Hals?
Weil der Kopf so weit oben ist.""";
Ausgabe 1:
Warum haben Giraffen so einen langen Hals?
Weil der Kopf so weit oben ist.
Beispiel 2:
String joke2 = """
Warum haben Giraffen so einen langen Hals?
Weil der Kopf so weit oben ist.""";
Ausgabe 2:
Warum haben Giraffen so einen langen Hals?
Weil der Kopf so weit oben ist.
Beispiel 3:
String joke2 = """
Warum haben Giraffen so einen langen Hals?
Weil der Kopf so weit oben ist.
""";
Ausgabe 3:
Warum haben Giraffen so einen langen Hals?
Weil der Kopf so weit oben ist.
Kommen wir abschließend noch zu ein paar Regeln. Im Quellcode könnte ein Zeilenende durch unterschiedliche Symbole im Text vorkommen: CR (\u000D), CR-LF (\u000D\u000A) oder LF (\u000A). Der Compiler führt eine sogenannte Normalisierung durch, dass am Ende nur ein LF (\u000A) im String steht.
Textblöcke sind keine sogenannten Raw-Strings, die „roh“ sind, sondern können alle Escape-Sequenzen, unter anderem \n, \t, \‘, \“ und \\, enthalten. So lässt sich am Ende immer noch mit \r eine CR-LF-Sequenz erschaffen:
String joke = """
Lehrer: '76 % aller Schüler in dieser Klasse haben keine Ahnung von Prozentrechnung.'\r
Schüler: 'Herr Lehrer, so viele sind wir doch gar nicht!'""";
Das Ergebnis wäre „Lehrer: ’76 % aller Schüler in dieser Klasse haben keine Ahnung von Prozentrechnung.’\u000D\u000ASchüler: ‚Herr Lehrer, so viele sind wir doch gar nicht!'“.
Kommen im String einfache oder doppelte Anführungszeichen vor, können diese ohne Ausmaskierung eingesetzt werden. Ein Sonderfall ist allerdings, wenn das doppelte Anführungszeichen direkt am Ende vor den drei schließenden doppelten Anführungszeichen steht, dann eine Maskierung notwendig:
String joke = """
Lehrer: "76 % aller Schüler in dieser Klasse haben keine Ahnung von Prozentrechnung."
Schüler: "Herr Lehrer, so viele sind wir doch gar nicht!\"""";
Sollen drei Anführungszeichen selbst in der Ausgabe vorkommen, muss eines der drei Anführungszeichen ausmaskiert werden, um nicht fälschlicherweise als Abschluss interpretiert zu werden. Für die Ausgabe
1 "
2 ""
3 """
4 """"
5 """""
6 """"""
müssen wir schreiben:
System.out.println( """
1 "
2 ""
3 ""\"
4 ""\""
5 ""\"""
6 ""\"""\"""" );
Solche Zeichenketten sind nicht mehr besonders gut lesbar …
Eine weitere Regel ist, dass Leerzeichen am Ende abgeschnitten werden. Aus dem Textblock
String s = """
1␣␣␣␣␣␣␣
2␣␣␣
""";
wird der String „1\u0002“ — der “Offene Kasten” ␣ stehen hier für Leerzeichen, die man sonst im Druck nicht sehen würde.
Sollen Leerzeichen am Ende zählen, so führt man die Escape-Sequenz \s ein. Dies wird übersetzt in ein reguläres Leerzeichen \u0020. Für das obere Beispiel bedeutet das:
String s = """
1 \s
2 \s
""";
Leser können mit der folgenden Aufgabe ihr Verständnis prüfen: Was für ein String entsteht?
String joke2 = """
Warum haben Giraffen so einen langen Hals? \
Weil der Kopf so weit oben ist.
""";
Es entsteht „Warum haben Giraffen so einen langen Hals? Weil der Kopf so weit oben ist.\n“.