Java – die Neuerungen in Version 17 LTS, 18 und 19

Von Michael Inden

Bleiben Sie bei Java auf dem Laufenden!

• •Aktuelle Infos bis zur neuesten Java-Version
• •Vertiefen Sie Ihr Know-how durch praktische Übungen
• •Lernen Sie die wichtigen Änderungen kompakt kennen

Dieses Buch von Michael Inden richtet sich an alle Entwickler:innen mit soliden Programmierkenntnissen, die ihr Java-Wissen auf den neuesten Stand bringen und es durch eine Vielzahl an Übungen festigen möchten. Es beschreibt alle wichtigen Neuerungen ausgehend vom letzten Java 11 LTS bis hin zum aktuellen Java 17 LTS. Darüber hinaus bietet es einen Ausblick auf die Folgeversionen Java 18.
"Java – die Neuerungen in Java 17 LTS und 18" behandelt alle wesentlichen Änderungen. Einen Schwerpunkt bildet die Beschreibung einer Vielzahl an Syntaxverbesserungen und die Erweiterungen in diversen APIs. Beispiele sind eine viel prägnantere Syntax bei switch sowie die mehrzeiligen Strings und records, welche die Definition von Werteklassen erleichtern. Auch das immer populärer werdende Pattern Matching für instanceof und switch wird vorgestellt. Nicht nur in der Syntax sondern auch in den APIs finden sich herausragende Neuerungen, etwa der mit Java 11 offiziell ins JDK aufgenommene HTTP/2-Support sowie diverse Detailverbesserungen beispielsweise im Stream-API. Schließlich bietet die JVM mit Direct Compilation, der JShell, JMH sowie jpackage wichtige Neuerungen. Dabei ragen das JMH Framework zum Erstellen von Microbenchmarks sowie jpackage zum Bereitstellen von Self-Contained-Installationen heraus.
Auch fortgeschrittenere Themen, beispielsweise der Ersatz aus dem JDK entfallener Funktionalitäten wie JAXB oder auch das Zusammenspiel von Java 17 mit u.a. Spring, Jackson, JPA sowie SonarQube, runden dieses Buch ab.
Ein Anhang beschreibt einige Highlights aus den Java-Versionen 8, 9 und 10, um Ihnen damit den Umstieg auf modernes Java 17 und 18 zu erleichtern.

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 29. Juli 2022
• ISBN: 9783969108376

Buchvorschau

1Einleitung

Dieses Buch stellt Ihnen alle wesentlichen Neuerungen aus den LTS-Releases (Long Term Support) Java 11 und 17 vor und behandelt damit natürlich auch die dazwischen liegenden Releases wie Java 12, 13, 14 usw. Darüber hinaus gebe ich einen Ausblick auf das brandaktuelle Java 18 und das zukünftige Java 19.

Alle Leser, die privat oder beruflich noch auf Java 8 setzen, finden in Anhang A einen kompakten Schnelleinstieg zu den herausragendsten bzw. bedeutendsten Änderungen der Java-Versionen 8, 9 sowie 10, um sich für die Erweiterungen ab Java 11 inhaltlich und syntaktisch vorzubereiten.

Bevor wir uns ein wenig mit den in diesem Buch behandelten Themen beschäftigen, möchte ich die Veränderungen der letzten Jahre in der Releasepolitik von Oracle darlegen, weil sich hier einiges getan hat.

1.1Releasepolitik

Vor Java 9 gab es keinen festen Takt oder Releasezyklus. Stattdessen wurde die Veröffentlichung einer neuen Java-Version an die Fertigstellung wesentlicher Features geknüpft. Wir alle kennen es noch gut: Früher wurden Java-Releases aufgrund unfertiger Features häufiger verschoben. Um dem entgegenzuwirken, hat Oracle nach dem Erscheinen von Java 9 auf einen halbjährlichen Releasezyklus umgestellt. Das erlaubt es, die jeweils bis zu diesem Zeitpunkt fertig implementierten Funktionalitäten zu veröffentlichen. Allerdings sind logischerweise nicht immer schon alle Features auch so weit, um final veröffentlicht zu werden. Daher gibt es seit Java 9 zwei Besonderheiten: die Preview-Features und die Incubator-Features.

Preview-Features

Sogenannte Preview-Features sind zwar vollständig spezifiziert und implementiert. Sie werden aber zunächst als Vorschau zum Sammeln von Erfahrungen und Feedback ins JDK integriert. Durch die Rückmeldungen möchte man der Funktionalität dann in Folgereleases einen weiteren Feinschliff geben. Allerdings sind Preview-Features standardmäßig nicht zugänglich und müssen explizit über die Angabe von --enable-preview sowohl beim Kompilieren als auch beim Ausführen über den gleichnamigen JVM-Aufrufparameter freigeschaltet bzw. aktiviert werden, um die Preview-Features in eigenen Programmen verwenden zu können.

Incubator-Features

Ergänzend zu den Preview-Features gibt es noch sogenannte Incubator-Features, die oftmals in Form korrespondierender Module implementiert und bereitgestellt werden. Auch hierbei geht es um das Sammeln von Erfahrungen und Feedback, allerdings auf einer vorläufigen Umsetzung. Es kann bei Incubator-Features durchaus sein, dass sich Dinge noch grundlegend ändern oder sogar später vollständig entfernt bzw. gar nicht in ein finales JDK aufgenommen werden. Weil Incubator-Features bzw. die bereitstellenden Module nicht offizieller Bestandteil des JDKs sind, müssen diese speziell aufgenommen werden. Dazu dient der JVM-Aufrufparameter --add-modules. Dieser ist interessanterweise nicht beim Kompilieren, sondern nur beim Ausführen anzugeben.

Releasekadenz im Wandel und die Auswirkungen

Kommen wir auf die Releasekadenz zurück. Bis einschließlich Java 9 wurden neue Java-Versionen immer Feature-basiert veröffentlicht. Das hatte in der Vergangenheit oftmals und mitunter auch beträchtliche Verschiebungen des geplanten Releasetermins zur Folge, nämlich immer dann, wenn für die Version wesentliche Features noch nicht fertiggestellt waren. Insbesondere deshalb verzögerten sich die Veröffentlichungen von Java 8 und Java 9 um mehrere Monate bzw. sogar über ein Jahr. Erinnern wir uns: Die Java-Gemeinde musste auf die Veröffentlichung von Java 9 deutlich länger als ursprünglich geplant warten – es gab gleich mehrere Verschiebungen, zunächst von September 2016 auf März 2017, dann auf Juli 2017 und schließlich auf September 2017. Schlimmer noch: Es war damals absolut nicht abzusehen oder vorab zu planen, wann eine neue Java-Version tatsächlich veröffentlicht werden würde.

Mit der Umstellung auf eine zeitbasierte Releasestrategie möchte man derartigen Verzögerungen entgegenwirken und die Planbarkeit erhöhen, indem jedes halbe Jahr eine neue Java-Version veröffentlicht wird, die all jene Features enthält, die bereits bis zu dem Termin fertig sind. Zudem sollte dann alle drei Jahre eine LTS-Version (Long Term Support) erscheinen. Eine solche ist in etwa vergleichbar mit den früheren Major-Versionen. Das war zwischen Java 11 und 17 dann auch der Fall. Mit Letzterem wurde dann eine Verkürzung des LTS-Zyklus auf 2 Jahre beschlossen, wodurch auch diejenigen Firmen schneller von den Neuerungen profitieren, die lediglich von LTS zu LTS springen wollen oder können.

Lassen Sie mich noch auf Folgendes hinweisen: Zwar kann die schnelle, halbjährliche Releasefolge eine größere Herausforderung für Toolhersteller sein, für uns als Entwickler ist es aber oftmals positiv, weil wir potenziell weniger lang auf neue Features warten müssen. Das konnte früher recht zermürbend sein.

Allerdings gilt das Positive vor allem für eigene Hobbyprojekte, weil man dort mit den Neuerungen experimentieren kann und weniger durch Restriktionen eingeschränkt ist. Im professionellen Einsatz wird man eher auf Kontinuität und die Verfügbarkeit von Security Updates setzen, weshalb in diesem Kontext vermutlich nur LTS-Versionen in Betracht kommen, um Migrationsaufwände kalkulierbar und besser planbar zu halten.

Tipp: Am Rande …

Für jeden Entwickler (Amateur oder Profi) hat der halbjährliche Releasezyklus einen weiteren Vorteil: Man kann sich häppchenweise mit neuen Features beschäftigen, wenn sie erscheinen, und muss nicht alle zwei, drei oder mehr Jahre einen Riesenbatzen Neuerungen am Stück durcharbeiten, wobei man durch den schieren Umfang an Änderungen gegebenenfalls einige relevante Dinge übersehen kann oder aus Zeitgründen auf »das les ich mir später durch« verschieben muss.

Lizenzpolitik im Wandel und die Auswirkungen

Nicht nur beim Releasezyklus, sondern insbesondere auch bei der Lizenzpolitik gab es in den letzten Jahren ein paar Überraschungen.

All diejenigen, die Java 11 herunterladen wollten, wurden durch einen markanten Hinweis auf die Änderungen in der Lizenzpolitik hingewiesen.

Abbildung 1-1 Hinweis auf neue Lizenzbedingungen, exemplarisch für Java 11

Dort war zu entnehmen, dass sich die Bedingungen ändern, wenn Sie Ihre Software kommerziell vertreiben oder dies planen: Das bislang selbst in Produktionssystemen immer kostenfrei verwendbare Oracle JDK ist für Java 11 leider kostenpflichtig. Als Alternative existiert etwa das OpenJDK (https://openjdk.java.net/). Während der Entwicklung kann das Oracle JDK allerdings weiterhin kostenfrei genutzt werden.

Dieser Schritt, die Benutzer zur Lizenzierung zu nötigen, hat aber bei der Entwicklergemeinde für eine ziemliche Verstimmung gesorgt. Und es kam noch schlimmer: Kurze Zeit nach der Einschränkung für Java 11 wurde rückwirkend auch Java 8 kostenpflichtig. Viele Firmen haben daher erst einmal keine weiteren Updates auf neuere Versionen vorgenommen.

Es gab darüber hinaus eine massive Gegenreaktion. Dadurch, dass das OpenJDK seit Java 11 auf den gleichen Sourcen wie das Oracle JDK beruht und man das Open-JDK kostenfrei beziehen kann, haben sich diverse Firmen und Konsortien daran gemacht, freie Versionen von Java bereitzustellen. Hier seien Azul Systems, Adopt Open-JDK (nun Adoptium, an dem unter anderem IBM, Microsoft und Red Hat mitarbeiten) oder auch Amazon Corretto stellvertretend für viele weitere genannt.

Bei Oracle hatte man mit der Veröffentlichung von Java 17 ein Einsehen und das Oracle JDK steht nun auch für kommerzielle Zwecke wieder kostenfrei zur Verfügung. Die zugehörige Lizenz wird übrigens als No-Fee Terms and Conditions (NFTC) bezeichnet.

Ein wenig unverständlich ist allerdings, dass Java 11 weiterhin einer kostenpflichtigen Lizenz unterliegt. Damit wird es noch unattraktiver und wohl kaum mehr als Zwischenschritt auf dem Weg zu Java 17 eingesetzt werden – es sei denn, man nimmt ein anderes JDK als das von Oracle. Aber mittlerweile befinden wir uns schon auf dem Weg zu Java 21 LTS, somit empfiehlt sich sowieso eher Java 17 LTS.

1.2Inhaltsübersicht: Was erwartet Sie im Folgenden?

Dieses Buch gibt einen fundierten Überblick über diverse wesentliche Erweiterungen, die in Java 17 LTS und dem brandaktuellen Java 18 gebündelt sind. Es werden unter anderem die im Folgenden beschriebenen Themen behandelt. Ergänzend wagen wir einen kurzen Ausblick auf Java 19 und seine Neuerungen.

API- und Syntaxerweiterungen

Wir schauen uns verschiedene Änderungen an der Syntax von Java an. Wir beginnen mit sogenannten »Text Blocks«, die seit Java 13 mehrzeilige Strings erlauben. Im Kontext von instanceof ist es ab Java 14 möglich, künstliche Hilfsvariablen und unschöne Casts zu vermeiden. Auch bezüglich switch hat sich beginnend mit Java 12 einiges getan. Die neue Syntax erleichtert die Angabe und Auswertung von Bedingungen und sorgt für mehr Klarheit und Verständlichkeit. Zusätzlich bietet modernes Java seit Version 14 mit Records ein ganz besonders interessantes Feature, womit eine extrem kompakte Schreibweise zum Deklarieren spezieller Klassen mit unveränderlichen Daten bereitgestellt wird.

Darüber hinaus gibt es einige für die Praxis oft weniger relevante Dinge, wie die Unterstützung von lokalen Enums und Interfaces sowie statischer Attribute und Methoden in inneren Klassen seit Java 16 oder die Kontrolle von Vererbung durch Sealed Types seit Java 15. All dies komplettiert die Sprache und rundet sie ab. Neben diesen Details finden wir eine hilfreiche Neuerung zur Fehleranalyse bei NullPointerExceptions, die mit JDK 14 eingeführt wurde. Das ist eigentlich eine Erweiterung in der JVM, aber ich nenne sie trotzdem schon mal hier, weil es sich wie eine Syntaxerweiterung anfühlt.

Kommen wir zu den APIs: Hier finden wir Ergänzungen in der Klasse String sowie Kleinigkeiten im Interface Predicate sowie der Klasse Optional. Praktisch sind die Convenience-Funktionalitäten in der Utility-Klasse Files. Auch im Stream-API gibt es nennenswerte Neuerungen, unter anderem den Teeing-Kollektor sowie die Methoden toList() und mapMulti(). Eine herausragende Neuerung stellt das HTTP/2-API dar.

JVM-Änderungen

Mit Java 11 wurde ein neuer Garbage Collector eingeführt. Des Weiteren ermöglicht das Feature »Launch Single-File Source-Code Programs«, Java-Klassen ohne explizite vorherige Kompilierung auszuführen und somit für Scripting einsetzen zu können. Zudem kann für Quereinsteiger und Neulinge die durch das Tool jshell bereitgestellte Java-Konsole mit REPL-Unterstützung (Read-Eval-Print-Loop) erste Experimente und Gehversuche erleichtern, ohne dafür den Compiler oder eine IDE bemühen zu müssen. Java 12 bietet als wesentliche Neuerung die Integration des Microbenchmark-Frameworks JMH (Java Microbenchmarking Harness). Darüber hinaus behandle ich das Tool jpackage, mit dem sich eigene Applikationen als installierbare Distributionen erzeugen lassen. Plattformspezifisch entsteht somit etwa für Windows ein MSI-Installer (Microsoft Software Installation), für macOS ein DMG (Disk Image) und für Linux ein RPM (Red Hat Package Manager) – weitere Formate sind verfügbar.

Schließlich gibt es diverse Dinge, die aus dem JDK entfernt wurden: Unter anderem sind die Module zu CORBA, JavaFX und in Teilen auch zu XML, speziell JAXB (Jakarta XML Binding), nun nicht mehr Bestandteil des JDKs. Für einige davon zeige ich valide Alternativen und beschreibe etwa, wie man JAXB als externe Abhängigkeiten einbinden kann.

1.3Grundgerüst des Eclipse-Projekts

Das mitgelieferte Eclipse-Projekt orientiert sich in seinem Aufbau an dem des Buchs und bietet für die Kapitel jeweils ein eigenes Package, z. B. ch03_syntax oder ch05_api. Dabei weiche ich ausnahmsweise von der Namenskonvention für Packages ab, weil ich die Unterstriche in diesem Fall für eine lesbare Notation halte.

Das gesamte Projekt folgt dem Maven-Standardverzeichnisaufbau und somit finden sich die Sourcen unter src/main/java und die Tests unter src/test/java.

1.4Anmerkung zum Programmierstil

In diesem Abschnitt möchte ich vorab noch etwas zum Programmierstil sagen, weil bei Ihnen vielleicht ab und an einmal die Frage aufkommen mag, ob man gewisse Dinge nicht kompakter gestalten könnte oder sollte.

1.4.1Gedanken zur Sourcecode-Kompaktheit

In der Regel sind mir beim Programmieren und insbesondere für die Implementierungen in diesem Buch vor allem eine leichte Nachvollziehbarkeit sowie eine übersichtliche Strukturierung und damit später eine vereinfachte Veränderbarkeit wichtig. Deshalb sind die gezeigten Implementierungen möglichst verständlich programmiert. Dadurch ist vielleicht nicht jedes Konstrukt maximal kompakt, dafür aber in der Regel gut nachvollziehbar. Diesem Aspekt möchte ich in diesem Buch den Vorrang geben. Auch in der Praxis kann man damit oftmals besser leben als mit einer schlechten Wartbarkeit, dafür aber einer kompakteren Programmierung.

Beispiel

Schauen wir uns zur Verdeutlichung ein kleines Beispiel an. Zunächst betrachten wir die lesbare, gut verständliche Variante zum Umdrehen des Inhalts eines Strings, die zudem sehr schön die beiden wichtigen Elemente des rekursiven Abbruchs und Abstiegs verdeutlicht:

static String reverseString(final String input)

{

// rekursiver Abbruch

if (input.length() <= 1)

return input;

final char firstChar = input.charAt(0);

final String remaining = input.substring(1);

// rekursiver Abstieg

return reverseString(remaining) + firstChar;

}

Die folgende deutlich kompaktere Variante bietet diese Vorteile nicht:

static String reverseStringShort(final String input)

{

return input.length() <= 1 ? input :

reverseStringShort(input.substring(1)) + input.charAt(0);

}

Überlegen Sie kurz, in welcher der beiden Methoden Sie sich sicher fühlen, eine nachträgliche Änderung vorzunehmen. Und wie sieht es aus, wenn Sie noch Unit Tests ergänzen wollen: Wie finden Sie passende Wertebelegungen und Prüfungen?

Außerdem sollte man bedenken, dass die obere Variante entweder bereits während der Kompilierung (Umwandlung in den Bytecode) oder später während der Ausführung und Optimierung automatisch in etwas Ähnliches wie die untere Variante konvertiert wird – eben mit dem Vorteil der besseren Lesbarkeit beim Programmieren.

1.4.2Gedanken zu final und var

Normalerweise bevorzuge ich, unveränderliche Variablen als final zu markieren. In diesem Buch verzichte ich mitunter darauf. Ein Grund ist, dass die JShell das Schlüsselwort final nicht überall unterstützt, glücklicherweise aber an den wichtigen Stellen, nämlich für Parameter und lokale Variablen.

Local Variable Type Inference – var

Seit Java 10 existiert die sogenannte Local Variable Type Inference, besser bekannt als var. Diese erlaubt es, auf die explizite Typangabe auf der linken Seite einer Variablendefinition zu verzichten, sofern sich der konkrete Typ für eine lokale Variable anhand der Definition auf der rechten Seite der Zuweisung vom Compiler ermitteln lässt:

var name = Peter;                // var => String

var chars = name.toCharArray();    // var => char[]

var mike = new Person(Mike, 47); // var => Person

var hash = mike.hashCode();        // var => int

Insbesondere im Zusammenhang mit generischen Containern spielt die Local Variable Type Inference ihre Vorteile aus:

// var => ArrayList

var names = new ArrayList();

names.add(Tim);

names.add(Tom);

names.add(Jerry);

// var => Map

var personAgeMapping = Map.of(Tim, 47L, Tom, 12L,

Michael, 47L, Max, 25L);

Konvention: var, falls lesbarer

Sofern die Verständlichkeit darunter nicht leidet, werde ich var an geeigneter Stelle verwenden, um den Sourcecode kürzer und klarer zu halten. Ist jedoch eine Typangabe für das Nachvollziehen von größerer Wichtigkeit, bevorzuge ich den konkreten Typ und vermeide var – die Grenzen sind aber fließend.

Konvention: final oder var

Eine weitere Anmerkung noch: Zwar kann man final und var kombinieren, ich finde dies jedoch stilistisch nicht schön und verwende entweder das eine oder das andere.

1.4.3Blockkommentare in Listings

Beachten Sie bitte, dass sich in den Listings diverse Blockkommentare finden, die der Orientierung und dem besseren Verständnis dienen. In der Praxis sollte man derartige Kommentierungen mit Bedacht einsetzen und lieber einzelne Sourcecode-Abschnitte in Methoden auslagern. Für die Beispiele des Buchs dienen diese Kommentare aber als Anhaltspunkte, weil die eingeführten oder dargestellten Sachverhalte für Sie als Leser vermutlich noch neu und ungewohnt sind.

// Prozess erzeugen

final String command = sleep 60s;

final String commandWin = cmd timeout 60;

final Process sleeper = Runtime.getRuntime().exec(command);

//    ...

// Process => ProcessHandle

final ProcessHandle sleeperHandle = ProcessHandle.of(sleeper.pid()).

orElseThrow(IllegalStateException::new);

//    ...

1.4.4Gedanken zur Formatierung

Die in den Listings genutzte Formatierung weicht leicht von den Coding Conventions von Oracle¹ ab. Ich orientiere mich an denjenigen von Scott Ambler², der insbesondere (öffnende) Klammern in jeweils eigenen Zeilen vorschlägt. Dazu habe ich ein spezielles Format namens Michaelis_CodeFormat erstellt. Dieses ist im Projekt-Download integriert und wird nachfolgend für eine Klasse demonstriert:

import java.util.Arrays;

import org.apache.log4j.Logger;

public final class FormatingExample

{

private static final Logger log = Logger.getLogger(FormatingExample);

public static String asHex(final byte[] telegram)

{

log.info(asHex( + Arrays.toString(telegram) + ));

final StringBuffer sb = new StringBuffer(0x);

for (int i = 0; i < telegram.length; i++)

{

final String hex = Integer.toHexString(telegram[i]);

sb.append(hex);

}

return sb.toString();

}

// ...

}

1.5Konfigurationen für Build-Tools und IDEs

Zur Demonstration der Auswirkungen von Java 17 auf Build-Tools und IDEs nehmen wir eine Beispielapplikation und ein paar einfache Beispielklassen mit folgendem Verzeichnisaufbau an:

Java17Examples

|-- build.gradle

|-- pom.xml

`-- src

`-- main

`-- java

|-- ch03_syntax

|  |-- InstanceOfExamples.java

|  |-- LocalEnumAndInterfaceExamples.java

|  |-- RecordExamples.java

|  |-- SealedTypesExamples.java

|  `-- TextBlockExamples.java

...

Weil wir einige Aktionen auch auf der Kommandozeile ausführen, sei noch mal darauf hingewiesen, dass Sie zum Nachvollziehen

das aktuelle Java 17 heruntergeladen und installiert haben müssen sowie

die Umgebungsvariablen wie JAVA_HOME und PATH passend auf die Java-Installation verweisen lassen. Für macOS geschieht dies etwa wie folgt:³

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home

export PATH=$JAVA_HOME/bin:$PATH

1.5.1Java 17 mit Gradle

Zum Experimentieren mit Java 17 benötigt man zumindest Gradle 7.3 (oder neuer) und ein paar passende, nachfolgend fett markierte Angaben in der Datei build.gradle:

plugins {

id 'java'

}

sourceCompatibility=17

targetCompatibility=17

repositories

{

jcenter();

}

// Aktivierung von Preview-Features

tasks.withType(JavaCompile) {

options.compilerArgs += [" --enable-preview"]

}

Danach können wir wie gewohnt mit

gradle clean assemble

ein korrespondierendes JAR bauen und beispielsweise die Klasse TextBlockExamples folgendermaßen daraus starten:

java --enable-preview -cp build/libs/Java17Examples.jar \

java17.syntax.TextBlockExamples

Es ist wichtig, den JVM-Kommandozeilenparameter --enable-preview beim Start anzugeben. Denn nur dadurch lässt sich das Programm auch starten, wenn das Projekt mit Preview-Features kompiliert wurde.

1.5.2Java 17 mit Maven

Mit der im September 2020 veröffentlichten Maven-Version 3.6.3 (oder besser der im März 2022 veröffentlichten Version 3.8.5) und dem Maven-Compiler-Plugin in der Version 3.8.1 lassen sich Java-17-Projekte ohne Probleme übersetzen.

Um Java 17 mit Maven zu nutzen, muss man folgende fett markierte Angaben in der Datei pom.xml vornehmen:

maven-compiler-plugin

3.8.1

17

--enable-preview

Mit diesen Modifikationen lässt sich ein Maven-Build mit

mvn clean package

ausführen und es wird ein korrespondierendes JAR erzeugt.

Betrachten wir als Beispiel wieder den Start der Klasse TextBlockExamples:

java --enable-preview -cp target/Java17Examples-1.0.0-SNAPSHOT.jar \

java17.syntax.TextBlockExamples

1.5.3Java 17 mit Eclipse

Für Eclipse in Version 2022-03 ist der Support für Java 17 bereits integriert. Sofern Sie noch Eclipse 2021-09 nutzen, ist der Support durch die kurze Zeit zwischen der Veröffentlichung von Java 17 und Eclipse 2021-09 noch nicht fix integriert, sondern muss als Plugin über den Eclipse Marketplace nachinstalliert werden, wie es in Abbildung 1-2 angedeutet ist.

Abbildung 1-2 Installation von Java-17-Plugin im Eclipse Marketplace

Selbstverständlich müssen Sie den Compiler auf Java 17 einstellen und die Preview-Features aktivieren, um alle Beispiele ausprobieren zu können.

Abbildung 1-3 Compiler-Einstellungen in Eclipse für Java 17

1.5.4Java 17 mit IntelliJ

Um mit Java 17 zu experimentieren, nutzen Sie bitte IntelliJ IDEA 2021.2 oder aktueller. Allerdings sind noch ein paar Einstellungen vorzunehmen und folgende Dinge zu beachten:

Im Dialog »Project Structure« muss man im Bereich »Project SDK« den Wert 17 auswählen und zum Experimentieren mit Preview-Features im Bereich »Language level« den Wert »17 (Preview) - Pattern matching for switch« einstellen.

Durch die Nutzung von Preview-Features ist es für das Ausführen der Beispiele erforderlich, in der jeweiligen Run Configuration der zu startenden Klassen --enable-preview anzugeben.

Abbildung 1-4 Einstellungen in Project Structure für Java 17

Oben ist die Standardeinstellung gezeigt, nachfolgend diejenige zur Aktivierung der Preview-Features:

Abbildung 1-5 Einstellungen in Project Structure für Java 17 mit Preview

1.6Ausprobieren der Beispiele und Lösungen

Vielfach können Sie die abgebildeten Sourcecode-Schnipsel einfach in die JShell kopieren oder beispielsweise eine main()-Methode im Editor Ihrer IDE integrieren und danach ausführen. Alternativ finden Sie alle relevanten Sourcen in dem zum Buch mitgelieferten Eclipse-Projekt. Dort lassen sich die Programme durch eine main()-Methode starten.

Was gibt es noch zu beachten? Grundsätzlich verwende ich möglichst nachvollziehbare Konstrukte und keine ganz besonders ausgefallenen Syntax- oder API-Features. Sofern nicht explizit im Text erwähnt, sollten Sie die Beispiele und Lösungen daher mit der aktuellen LTS-Version Java 17 ausprobieren können. In wenigen Ausnahmen setze ich allerdings Preview-Syntaxerweiterungen aus Java 17 oder gar 18 ein. Erinnern wir uns: Durch die mittlerweile kurzen Abstände von 6 Monaten zwischen den Java-Releases werden der Entwicklergemeinde einige Features als Previews vorgestellt. Möchte man diese nutzen, so sind in den IDEs und Build-Tools gewisse Parametrierungen sowohl beim Kompilieren als auch beim Ausführen nötig, wie dies zuvor gezeigt wurde.

1.6.1Ausprobieren neuer Java-Features mit der JShell oder der Kommandozeile

Durch die recht eng getakteten Releasezyklen von 6 Monaten ist die Tool-Landschaft mitunter noch nicht immer parat, wenn man schon mal mit Vorabversionen experimentieren möchte. Dann bieten sich folgende Alternativen an:

Kommandozeile – Selbstverständlich ist es immer möglich, mit javac und java zu arbeiten, wenn auch manchmal etwas mühsamer.

Kommandozeile – Seit Java 11 gibt es das Feature, einzelne Java-Dateien direkt durch Aufruf von java, also ohne explizites vorheriges Kompilieren, starten zu können (vgl. Abschnitt 7.3).

JShell – Die JShell ist seit Java 9 eine Alternative für kleine Experimente, weil das REPL-Tool (Read-Eval-Print-Loop) Bestandteil der JVM ist und das Ausführen kleinerer Sourcecode-Schnipsel erlaubt.

Ausführen mit der Kommandozeile

Wie gerade erwähnt, kann man einzelne Java-Dateien direkt durch Aufruf von java, also ohne explizites vorheriges Kompilieren, starten. Das Editieren kann mit jedem beliebigen Texteditor oder einer IDE (gegebenenfalls mit der Markierung von Syntaxfehlern) erfolgen.

Betrachten wir exemplarisch ein Beispielprogramm:

import java.time.Duration;

import java.time.temporal.ChronoUnit;

public class DurationIntroExample

{

public static void main(String[] args)

{

System.out.println(Duration.of(20L, ChronoUnit.DAYS).isNegative());

System.out.println(Duration.of(-12L, ChronoUnit.DAYS).isNegative());

}

}

Dieses einfache aus einer Klasse bestehende Programm lässt sich ohne explizite Kompilierung direkt von der Konsole starten:

$ java src/main/java/intro/DurationIntroExample.java

Dann erhalten wir diese Ausgabe:

false

true

Ausführen mit der jshell

Mit der JShell wird es möglich, etwas Java-Sourcecode zu schreiben und Dinge schnell auszuprobieren, ohne dafür die IDE starten und ein Projekt anlegen zu müssen. Außerdem kann man immer auch die neuesten Features ausprobieren. Etwas detaillierter gehe ich in Abschnitt 7.2 auf die Möglichkeiten ein. Hier folgt ein einführendes Beispiel, um Sie für das Ausführen einzelner Kommandos vorzubereiten.

Starten wir die jshell und probieren einige Aktionen und Berechnungen aus. Dabei dient eine Abwandlung eines Hello-World-Beispiels als Startpunkt:

$ jshell

|  Welcome to JShell -- Version 17.0.2

|  For an introduction type: /help intro

jshell> System.out.println(Hello JShell)

Hello JShell

Danach addieren wir zwei Zahlen:

jshell> 2 + 2

$2 ==> 4

Anhand der Ausgabe sehen wir, dass die jshell das Berechnungsergebnis einer Shell-Variablen zuweist, die mit $ beginnt, hier $2.

Tipp: Besonderheit Preview-Features

Sofern Sie mit Preview-Features experimentieren möchten, müssen Sie diese