Java 9 – Die Neuerungen E-Book

Michael Inden

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2018

Seitenzahl: 416

Beschreibung

Dieses Buch bietet einen fundierten Einstieg in Java 9 und gibt einen Überblick über die darin enthaltenen umfangreichen Neuerungen. Damit eignet sich das Buch für all jene, die ihr Java-Wissen auf den neuesten Stand bringen möchten. Eine Vielzahl von Übungen unterstützt Sie dabei, die einzelnen Themengebiete zu vertiefen und besser zu verstehen. Zunächst werden die Änderungen in der Sprache selbst behandelt. Einen weiteren Schwerpunkt bilden die Erweiterungen in diversen APIs, etwa dem Process-API, dem Stream-API, bei Collections, in der Klasse Optional und vielem mehr. Aber auch im Bereich Concurrency finden sich Erweiterungen – vor allem die Unterstützung von Reactive Streams. Viele dieser Neuerungen machen das Programmiererleben noch ein wenig angenehmer. Die fundamentalste Änderung in Java 9 stellt die als Projekt "Jigsaw" entwickelte Modularisierungslösung dar, die es erlaubt, eigene Programme in Softwarekomponenten – so genannte Module – zu unterteilen. Auf diese Weise lassen sich Abhängigkeiten klar definieren, um selbst größere Softwaresysteme möglichst beherrschbar und änderbar zu halten. Weil Java 9 einige Auswirkungen auf Build-Tools und IDEs besitzt, gibt ein Kapitel einen Überblick über das aktuelle Tooling rund um die neue Java-Version. Auch fortgeschrittenere Themen wie Services und die Migration bestehender Applikationen werden besprochen. Ein Schnelleinstieg in die wichtigsten Neuerungen von Java 8, die im Repertoire keines Java-Entwicklers fehlen sollten und die zudem hilfreich beim Verständnis der Neuerungen aus JDK 9 sind, rundet dieses Buch ab. Zudem widmen sich zwei kurze Anhänge den Build-Tools "Maven" und "Gradle".

Leseprobe

Dipl.-Inform. Michael Inden ist Oracle-zertifizierter Java-Entwickler für JDK 6. Nach seinem Studium in Oldenburg war er lange Zeit als Softwareentwickler und -architekt bei verschiedenen internationalen Firmen tätig und arbeitet derzeit als Teamleiter Softwareentwicklung in Zürich.

Michael Inden hat rund 20 Jahre Erfahrung beim Entwurf komplexer Softwaresysteme gesammelt, an diversen Fortbildungen und an mehreren Java-One-Konferenzen in San Francisco teilgenommen. Sein Wissen gibt er gerne als Trainer in Schulungen und auf Konferenzen weiter. Sein besonderes Interesse gilt dem Design qualitativ hochwertiger Applikationen mit ergonomischen, grafischen Oberflächen sowie dem Coaching von Kollegen.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Michael Inden

Java 9 – Die Neuerungen

Syntax- und API-Erweiterungen undModularisierung im Überblick

Michael [email protected]

Lektorat: Dr. Michael Barabas

Projektkoordination: Miriam Metsch

Technischer Review: Torsten Horn, Aachen

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Michael Inden

Herstellung: Susanne Bröckelmann

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print     978-3-86490-451-6

PDF      978-3-96088-378-4

ePub    978-3-96088-379-1

mobi    978-3-96088-380-7

1. Auflage 2018

Copyright © 2018 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Inhaltsverzeichnis

1Einleitung

ISprach- und API-Erweiterungen

2Syntaxerweiterungen

2.1Anonyme innere Klassen und der Diamond Operator

2.2Nutzung von »effectively final«-Variablen im ARM

2.3Neuerung bei der @SafeVarargs-Annotation

2.4Erweiterung der @Deprecated-Annotation

2.5Private Methoden in Interfaces

2.6Verbotener Bezeichner ’_’

3Neues und Änderungen im JDK

3.1Neue APIs

3.1.1Das neue Process-API

3.1.2Collection-Factory-Methoden

3.1.3Reactive Streams und die Klasse Flow

3.1.4Taskbar-Support

3.1.5Verarbeitung von Stackframes und die Klasse StackWalker

3.1.6HTTP/2-Support

3.2Erweiterte APIs

3.2.1Erweiterungen in der Klasse InputStream

3.2.2Erweiterungen rund um die Klasse Optional

3.2.3Erweiterungen im Stream-API

3.2.4Erweiterungen in der Klasse LocalDate

3.2.5Support von UTF-8 in ResourceBundles

3.2.6Erweiterungen in der Klasse Arrays

3.2.7Erweiterungen in der Klasse Objects

3.2.8Erweiterungen in der Klasse CompletableFuture

3.2.9Erweiterungen in Class<T>

3.2.10Die Klasse MethodHandle

3.2.11Die Klasse VarHandle

3.3Sonstige Änderungen

3.3.1Optimierung bei Strings

3.3.2Erweiterungen im Unicode-Support

3.3.3HiDPI-Support

3.3.4Multi-Resolution Images

3.3.5Unterstützung von TIFF-Grafiken

3.3.6Support für Spin-Wait-Loops

3.3.7Deprecation diverser Typen und Methoden im JDK

4Änderungen in der JVM

4.1Performance-Verbesserungen

4.2HTML5 Javadoc

4.3Änderung des Versionsschemas

4.4Browser-Plugin ist deprecated

4.5Garbage Collection

4.6Unterstützung von Multi-Release-JARs

4.7Java + REPL => jshell

5Übungen zu den Neuerungen in JDK 9

IIModularisierung

6Modularisierung mit Project Jigsaw

6.1Grundlagen

6.1.1Bisherige Varianten der Modularisierung

6.1.2Warum wir Modularisierung brauchen

6.2Modularisierung im Überblick

6.2.1Grundlagen zu Project Jigsaw

6.2.2Einführendes Beispiel

6.2.3Komplexeres Beispiel

6.2.4Packaging

6.2.5Linking

6.2.6Abhängigkeiten und Modulgraphen

6.2.7Module des JDKs einbinden

6.2.8Arten von Modulen

6.3Sichtbarkeiten und Zugriffsschutz

6.3.1Sichtbarkeiten

6.3.2Zugriffsschutz an Beispielen

6.3.3Transitive Abhängigkeiten (Implied Readability)

6.4Zusammenfassung

7Weiterführende Themen zur Modularisierung

7.1Modularisierung und Services

7.1.1Begrifflichkeiten: API, SPI und Service Provider

7.1.2Service-Ansatz in Java seit JDK 6

7.1.3Services im Bereich der Modularisierung

7.1.4Definition eines Service Interface

7.1.5Realisierung eines Service Provider

7.1.6Realisierung eines Service Consumer

7.1.7Kontrolle der Abhängigkeiten

7.1.8Fazit

7.2Modularisierung und Reflection

7.2.1Verarbeitung von Modulen mit Reflection

7.2.2Tool zur Ermittlung von Modulen zu Klassen

7.2.3Konvertierungstool für import zu requires

7.2.4Besonderheiten bei Reflection

7.3Kompatibilität und Migration

7.3.1Kompatibilitätsmodus

7.3.2Migrationsszenarien

7.3.3Fallstrick bei der Bottom-up-Migration

7.3.4Beispiel: Migration mit Automatic Modules

7.3.5Beispiel: Automatic und Unnamed Module

7.3.6Abwandlung mit zwei Automatic Modules

7.3.7Mögliche Schwierigkeiten bei Migrationen

7.3.8Fazit

8Übungen zur Modularisierung

IIIVerschiedenes

9Build-Tools und IDEs

9.1Nicht modularisierte Applikationen

9.1.1Gradle

9.1.2Maven

9.1.3Eclipse

9.1.4IntelliJ IDEA

9.1.5NetBeans

9.2Nicht modularisierte Applikationen mit HTTP/2-API

9.2.1Gradle

9.2.2Maven

9.2.3Eclipse

9.2.4IntelliJ IDEA

9.2.5NetBeans

9.3Modularisierte Applikationen

9.3.1Gradle

9.3.2Maven

9.3.3Eclipse

9.3.4IntelliJ IDEA

9.3.5NetBeans

9.4Besonderheiten beim Unit-Testen

9.4.1Gradle

9.4.2Maven

9.4.3Eclipse

9.4.4IntelliJ IDEA

9.4.5NetBeans

9.4.6Kommandozeile

9.5Kompatibilitätsmodus

9.5.1Gradle

9.5.2Maven

9.5.3Eclipse

9.5.4IntelliJ IDEA

9.5.5NetBeans

9.5.6Kommandozeile

9.6Fazit

10Zusammenfassung

IVAnhang

ASchnelleinstieg in Java 8

A.1Einstieg in Lambdas

A.1.1Lambdas am Beispiel

A.1.2Functional Interfaces und SAM-Typen

A.1.3Type Inference und Kurzformen der Syntax

A.1.4Methodenreferenzen

A.2Streams im Überblick

A.2.1Streams erzeugen – Create Operations

A.2.2Intermediate und Terminal Operations im Überblick

A.2.3Zustandslose Intermediate Operations

A.2.4Zustandsbehaftete Intermediate Operations

A.2.5Terminal Operations

A.3Neuerungen in der Datumsverarbeitung

A.3.1Neue Aufzählungen, Klassen und Interfaces

A.3.2Die Klasse Instant

A.3.3Die Klasse Duration

A.3.4Die Klassen LocalDate, LocalTime und LocalDateTime

A.3.5Die Klasse Period

A.3.6Datumsarithmetik mit TemporalAdjusters

A.4Diverse Erweiterungen

A.4.1Erweiterungen im Interface Comparator<T>

A.4.2Die Klasse Optional<T>

A.4.3Die Klasse CompletableFuture

BEinführung Gradle

B.1Projektstruktur für Maven und Gradle

B.2Builds mit Gradle

CEinführung Maven

C.1Maven im Überblick

C.2Maven am Beispiel

Literaturverzeichnis

Index

Vorwort

Zunächst einmal bedanke ich mich bei Ihnen, dass Sie sich für dieses Buch entschieden haben. Hierin finden Sie eine Vielzahl an Informationen zu den Neuerungen der brandaktuellen Version 9 von Java. Neben einigen Detailveränderungen in der Sprache selbst gibt es in vielen APIs diverse kleine und größere praktische Neuerungen – auch solche, die die mit JDK 8 eingeführten Erweiterungen ergänzen und abrunden. Ab und an kann das neu eingeführte Programm jshell interessant sein, das einen REPL (Read-Eval-Print-Loop) in die JVM integriert. Das bedeutendste Feature von Java 9 ist sicherlich die Modularisierung, die es erlaubt, eigene Programme in kleinere Softwarekomponenten, sogenannte Module, zu unterteilen. Zudem wurde auch das JDK in viele kleine Bausteine aufgeteilt.

An wen richtet sich dieses Buch?

Dieses Buch ist kein Buch für Programmierneulinge, sondern richtet sich an diejenigen Leser, die bereits solides Java-Know-how besitzen und sich nun kurz und prägnant über die Neuerungen in Java 9 informieren wollen.

Um die Beispiele des Buchs möglichst präzise und elegant zu halten, verwende ich diverse Features aus Java 8. Deshalb setzt der Text voraus, dass Sie sich schon mit den Neuerungen von Java 8 auseinandergesetzt haben. Alle, die eine kleine Auffrischung benötigen, finden zum leichteren Einstieg im Anhang einen Crashkurs zu Java 8. Für einen fundierten Einstieg in Java 8 möchte ich Sie auf meine Bücher »Java 8 – Die Neuerungen« [3] oder alternativ »Der Weg zum Java-Profi« [5] verweisen.

Zielgruppe

Dieses Buch richtet sich im Speziellen an zwei Zielgruppen:

Zum einen sind dies engagierte Hobbyprogrammierer, Informatikstudenten und Berufseinsteiger, die Java als Sprache beherrschen und an den Neuerungen in Java 9 interessiert sind.

Zum anderen ist das Buch für erfahrene Softwareentwickler und -architekten gedacht, die ihr Wissen ergänzen oder auffrischen wollen, um für zukünftige Projekte abschätzen zu können, ob und – wenn ja – für welche Anforderungen Java 9 eine gewinnbringende Alternative darstellen kann.

Was vermittelt dieses Buch?

Sie als Leser erhalten in diesem Buch neben Theoriewissen eine Vertiefung durch praktische Beispiele, sodass der Umstieg auf Java 9 in eigenen Projekten erfolgreich gemeistert werden kann. Sofern hilfreich, stelle ich zunächst eine herkömmliche Lösung mit Java 8 vor und vergleiche diese dann mit der Java-9-Variante. Ich setze zwar ein gutes Java-Grundwissen voraus, allerdings werden ausgewählte Themengebiete etwas genauer und gegebenenfalls einführend betrachtet, wenn dies das Verständnis der nachfolgenden Inhalte erleichtert.

Aufbau dieses Buchs

Nachdem Sie eine grobe Vorstellung über den Inhalt dieses Buchs haben, möchte ich die Themen der einzelnen Kapitel kurz vorstellen.

Kapitel 1 – EinleitungDie Einleitung stimmt Sie auf Java 9 ein und nennt auch Hintergründe zur Entstehungsgeschichte.

Kapitel 2 – SyntaxerweiterungenZunächst widmen wir uns verschiedenen Änderungen an der Syntax von Java. Neben Details zu Bezeichnern, dem Diamond Operator und Ergänzungen bei zwei Annotations gehe ich vor allem kritisch auf das neue Feature privater Methoden in Interfaces ein.

Kapitel 3 – Neues und Änderungen im JDKIn den APIs des JDKs finden sich diverse Neuerungen. Dieses Potpourri habe ich thematisch ein wenig gegliedert. Neben Vereinfachungen beim Prozess-Handling, der Verarbeitung mit Optional<T> oder von Daten mit InputStreams schauen wir auf fundamentale Neuerungen im Bereich der Concurrency durch Reactive Streams. Darüber hinaus enthält Java 9 eine Vielzahl weiterer Neuerungen, beispielsweise im Bereich Desktop und Unterstützung von HiDPI und Multi-Resolution Images.

Kapitel 4 – Änderungen in der JVMIn diesem Kapitel beschäftigen wir uns mit ein paar Änderungen in der JVM, die im JDK 9 enthalten sind, etwa bei der Garbage Collection oder der Einführung der jshell. Auch in Bezug auf javadoc und der Nummerierung von Java-Versionen finden wir in Java 9 Änderungen, die thematisiert werden.

Kapitel 5 – Übungen zu den Neuerungen in JDK 9In diesem Kapitel werden Übungsaufgaben zu den Themen der vorangegangenen Kapitel 2 bis 4 präsentiert. Deren Bearbeitung sollte Ihr Wissen zu den Neuerungen aus Java 9 vertiefen.

Kapitel 6 – Modularisierung mit Project JigsawKlar strukturierte Softwarearchitekturen mit sauber definierten Abhängigkeiten sind erstrebenswert, um selbst größere Softwaresysteme möglichst beherrschbar zu machen und Teile unabhängig voneinander änderbar zu halten. Dazu wird Java 9 um Module als eigenständige Softwarekomponenten erweitert. In diesem Kapitel wird die Thematik Modularisierung zunächst eingeführt und anhand von Beispielen vorgestellt. Im Speziellen werden auch Themen wie Sichtbarkeit und Zugriffsschutz behandelt.

Kapitel 7 – Weiterführende Themen zur ModularisierungIn diesem Kapitel schauen wir uns einige fortgeschrittenere Themen zur Modularisierung an. Zwar hilft die Modularisierung bei der Strukturierung eines Systems, jedoch besitzen die Module dann auch direkte Abhängigkeiten bereits zur Kompilierzeit. Wird eine losere Kopplung benötigt, so kann man dafür Services nutzen. Zudem ändern sich durch die Modularisierung ein paar Dinge bezüglich Reflection, beispielsweise lassen sich neue Eigenschaften ermitteln, etwa die Moduldaten zu einer Klasse. Das werden wir zur Erstellung von Tools nutzen. Verbleibt noch ein wichtiges Thema, nämlich die Migration einer bestehenden Applikation in eine modularisierte. Weil dabei doch ein paar Dinge zu beachten sind, ist diesem Thema ein ausführlicher Abschnitt gewidmet, der insbesondere die verschiedenen Arten von Modulen und ihre Eigenschaften behandelt.

Kapitel 8 – Übungen zur ModularisierungWie für die API-Erweiterungen werden auch für die Modularisierung verschiedene Übungsaufgaben in einem Kapitel zusammengestellt.

Kapitel 9 – Build-Tools und IDEsWährend frühere Versionen von Java der Rückwärtskompatibilität viel Aufmerksamkeit geschenkt haben und sich dadurch die notwendigen Anpassungen in IDEs und Build-Tools in Grenzen hielten, führt Java 9 durch die Modularisierung zum ersten Mal zu einem größeren Bruch. Die neue Art und Weise, wie Module den Sourcecode strukturieren, wie Klassen geladen werden und wie Zugriffe eingeschränkt werden können, und vor allem das Verbot zum Zugriff auf interne Klassen des JDKs führen zu Inkompatibilitäten und erfordern einige Anstrengungen bei Toolherstellern. Dieses Kapitel gibt einen Überblick über den derzeitigen Stand.

Kapitel 10 – ZusammenfassungDieses Kapitel fasst die Themen rund um die vielfältigen Neuerungen aus Java 9 noch einmal kurz zusammen. Dabei nenne ich auch einige mit JDK 9 geplante, aber leider nicht umgesetzte Sprachfeatures.

Anhang A – Schnelleinsteg in Java 8In Anhang A werden für dieses Buch wesentliche Neuerungen aus Java 8 rekapituliert. Damit können Sie von diesem Buch selbst dann profitieren, wenn Sie sich noch nicht eingehend mit Java 8 beschäftigt haben. Neben einem Einstieg in die funktionale Programmierung mit Lambdas widmen wir uns den Streams, einer weiteren wesentlichen Neuerung in JDK 8 zur Verarbeitung von Daten. Abgerundet wird Anhang A durch einen kurzen Blick auf das Date and Time API und verschiedene API-Erweiterungen.

Anhang B – Einführung GradleAnhang B liefert eine kurze Einführung in das Build-Tool Gradle, mit dem die Beispiele dieses Buchs übersetzt wurden. Mit dem vermittelten Wissen können Sie dann auch kleinere eigene Projekte mit einem Build-System ausstatten.

Anhang C – Einführung MavenIn diesem Anhang wird Maven als Build-Tool kurz vorgestellt. Derzeit bietet es die beste Unterstützung für modularisierte Applikationen in Java. Zudem kann man derartige Maven-Projekte einfach in gängige IDEs importieren.

Sourcecode und ausführbare Programme

Um den Rahmen des Buchs nicht zu sprengen, stellen die Listings häufig nur Ausschnitte aus lauffähigen Programmen dar, wobei wichtige Passagen zum besseren Verständnis mitunter fett hervorgehoben sind. Auf der Webseite zu diesem Buch www.dpunkt.de/java-9 steht dann der vollständige, kompilierbare Sourcecode zu den Programmen zum Download bereit. Neben dem Sourcecode befindet sich auf der Webseite auch ein Eclipse-Projekt, über das sich alle Programme ausführen lassen. Idealerweise nutzen Sie dazu Eclipse Oxygen 1A oder neuer, weil diese Version der IDE bereits Java 9 unterstützt. Aber auch NetBeans und IntelliJ IDEA sind gute Alternativen.

Ergänzend wird die Datei build.gradle mitgeliefert, die den Ablauf des Builds für Gradle beschreibt. Dieses Build-Tool besitzt viele Vorzüge, wie die kompakte und gut lesbare Notation, und vereinfacht die Verwaltung von Abhängigkeiten enorm. Gradle erlaubt aber auch das Starten von Programmen, wobei der jeweilige Programmname in Kapitälchenschrift, etwa DATETIMEEXAMPLE, angegeben wird.

Blockkommentare in ListingsBeachten 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.

Konventionen

Verwendete Zeichensätze

In diesem Buch gelten folgende Konventionen bezüglich der Schriftart: Neben der vorliegenden Schriftart werden wichtige Textpassagen kursiv oder kursiv und fett markiert. Englische Fachbegriffe werden eingedeutscht großgeschrieben, etwa Event Handling. Zusammensetzungen aus englischen und deutschen (oder eingedeutschten) Begriffen werden mit Bindestrich verbunden, z. B. Plugin-Manager. Namen von Programmen und Entwurfsmustern werden in KAPITÄLCHEN geschrieben. Listings mit Sourcecode sind in der Schrift Courier gesetzt, um zu verdeutlichen, dass dies einen Ausschnitt aus einem Java-Programm darstellt. Auch im normalen Text wird für Klassen, Methoden, Konstanten und Parameter diese Schriftart genutzt.

Tipps und Hinweise aus der Praxis

Dieses Buch ist mit diversen Praxistipps gespickt. In diesen werden interessante Hintergrundinformationen präsentiert oder es wird auf Fallstricke hingewiesen.

Tipp: Praxistipp

In derart formatierten Kästen finden sich im späteren Verlauf des Buchs immer wieder einige wissenswerte Tipps und ergänzende Hinweise zum eigentlichen Text.

Verwendete Klassen aus dem JDK

Werden Klassen des JDKs erstmalig im Text erwähnt, so wird deren voll qualifizierter Name, d. h. inklusive der Package-Struktur, angegeben: Die Klasse String würde demnach als java.lang.String notiert – alle weiteren Nennungen erfolgen dann ohne Angabe des Package-Namens. Diese Regelung erleichtert initial die Orientierung und ein Auffinden im JDK und zudem wird der nachfolgende Text nicht zu sehr aufgebläht. Die voll qualifizierte Angabe hilft insbesondere, da in den Listings eher selten import-Anweisungen abgebildet werden.

Im Text beschriebene Methodenaufrufe enthalten in der Regel die Typen der Übergabeparameter, etwa substring(int, int). Sind die Parameter in einem Kontext nicht entscheidend, wird mitunter auf deren Angabe aus Gründen der besseren Lesbarkeit verzichtet – das gilt ganz besonders für Methoden mit generischen Parametern.

Verwendete Abkürzungen

Im Buch verwende ich die in der nachfolgenden Tabelle aufgelisteten Abkürzungen. Weitere Abkürzungen werden im laufenden Text in Klammern nach ihrer ersten Definition aufgeführt und anschließend bei Bedarf genutzt.

Abkürzung

Bedeutung

API

Application Programming Interface

ASCII

American Standard Code for Information Interchange

(G)UI

(Graphical) User Interface

IDE

Integrated Development Environment

JDK

Java Development Kit

JLS

Java Language Specification

JRE

Java Runtime Environment

JSR

Java Specification Request

JVM

Java Virtual Machine

Danksagung

Ein Fachbuch zu schreiben ist eine schöne, aber arbeitsreiche und langwierige Aufgabe. Alleine kann man dies kaum bewältigen. Daher möchte ich mich an dieser Stelle bei allen bedanken, die direkt oder indirekt zum Gelingen des Buchs beigetragen haben. Insbesondere konnte ich bei der Erstellung des Manuskripts auf ein starkes Team an Korrekturlesern zurückgreifen. Es ist hilfreich, von den unterschiedlichen Sichtweisen und Erfahrungen profitieren zu dürfen.

Zunächst einmal möchte ich mich bei Michael Kulla, der als Trainer für Java SE und Java EE bekannt ist, für sein mehrmaliges, gründliches Review vieler Kapitel und die fundierten Anmerkungen bedanken.

Merten Driemeyer, Dr. Clemens Gugenberger, Prof. Dr. Carsten Kern sowie Andreas Schöneck haben mit verschiedenen hilfreichen Anmerkungen zu einer Verbesserung beigetragen. Zudem hat Ralph Willenborg mal wieder ganz genau gelesen und so diverse Tippfehler gefunden. Vielen Dank dafür! Auch von Albrecht Ermgassen erhielt ich den einen oder anderen Hinweis.

Schließlich bedanke ich mich bei einigen ehemaligen Arbeitskollegen der Zühlke Engineering AG: Jeton Memeti und Marius Reusch trugen durch ihre Kommentare zur Klarheit und Präzisierung bei. Auch von Hermann Schnyder von der Swissom erhielt ich ein paar Anregungen.

Ebenso geht ein Dankeschön an das Team des dpunkt.verlags (Dr. Michael Barabas, Martin Wohlrab, Miriam Metsch und Birgit Bäuerlein) für die tolle Zusammenarbeit. Außerdem möchte ich mich bei Torsten Horn für die fundierte fachliche Durchsicht sowie bei Ursula Zimpfer für ihre Adleraugen beim Copy-Editing bedanken.

Abschließend geht ein lieber Dank an meine Frau Lilija für ihr Verständnis und die Unterstützung. Glücklicherweise musste sie beim Entstehen dieses Buchs zu den Neuerungen in Java 9 einen weit weniger gestressten Autor ertragen, als dies früher beim Schreiben meines Buchs »Der Weg zum Java-Profi« der Fall war.

Anregungen und Kritik

Trotz großer Sorgfalt und mehrfachen Korrekturlesens lassen sich missverständliche Formulierungen oder sogar Fehler leider nicht vollständig ausschließen. Falls Ihnen etwas Derartiges auffallen sollte, so zögern Sie bitte nicht, mir dies mitzuteilen. Gerne nehme ich auch sonstige Anregungen oder Verbesserungsvorschläge entgegen. Kontaktieren Sie mich bitte per Mail unter:

[email protected]

Zürich, im November 2017

Michael Inden

1Einleitung

Rund 3,5 Jahre nach dem Erscheinen von JDK 8 am 18. März 2014 geht nun Java mit Version 9 im September 2017 an den Start. Wieder einmal hat die Java-Gemeinde auf die Veröffentlichung der neuen Version des JDKs etwas länger warten müssen. Zuletzt wurde sie von September 2016 auf März 2017, dann auf Juli 2017 und schließlich auf September 2017 und damit rund 1 Jahr verschoben. Aber das Warten hat sich gelohnt: Neben diversen Verbesserungen im JDK selbst liegt der Hauptfokus auf der Modularisierung, die eine verlässliche Konfiguration und besser strukturierte Programme mit klaren Abhängigkeitsbeziehungen begünstigt.1

Dieses Buch gibt einen Überblick über wesentliche Erweiterungen in JDK 9. Es werden unter anderem folgende Themen behandelt:

API- und SyntaxerweiterungenZunächst schauen wir uns verschiedene Änderungen an der Syntax von Java an. Neben Erleichterungen beim ARM (Automatic Resource Management) sowie Erweiterungen bei @Deprecated-Annotations widmen wir uns Details zu Bezeichnern, dem Diamond Operator und vor allem gehe ich kritisch auf das neue Feature privater Methoden in Interfaces ein.

Ebenfalls wurden diverse APIs ergänzt oder neu eingeführt. Auch Bestehendes, wie z. B. das Stream-API oder die Klasse Optional<T>, wurde adäquat um Funktionalität ergänzt. Dieses Potpourri habe ich thematisch ein wenig gegliedert. Neben Vereinfachungen beim Prozess-Handling, der Verarbeitung mit Optional<T> oder von Daten mit InputStreams schauen wir auf fundamentale Neuerungen im Bereich der Concurrency durch Reactive Streams. Darüber hinaus enthält Java 9 eine Vielzahl weiterer Neuerungen, beispielsweise im Bereich Desktop und zur Unterstützung von HiDPI und Multi-Resolution Images.

JVM-ÄnderungenIn einem eigenen Kapitel beschäftigen wir uns mit Änderungen in der JVM, die im JDK 9 enthalten sind, etwa bei der Garbage Collection oder in Bezug auf javadoc und der Nummerierung von Java-Versionen. 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.

ModularisierungDie Modularisierung adressiert zwei typische Probleme größerer Java-Applikationen. Zum einen ist dies die sogenannte JAR-Hell, womit gemeint ist, dass sich im CLASSPATH verschiedene JARs mit zum Teil inhaltlichen Überschneidungen (unterschiedliche Versionen mit Abweichungen in Packages oder gleiche Klassen, aber anderem Bytecode) befinden. Dabei kann aber nicht sichergestellt werden, wann welche Klasse aus welchem JAR eingebunden wird. Zum anderen sind als public definierte Typen beliebig von anderen Packages aus zugreifbar. Das erschwert die Kapselung. Mit JDK 9 kann man nun eigenständige Softwarekomponenten (Module) mit einer Sichtbarkeitssteuerung definieren. Das hat allerdings weitreichende Konsequenzen: Sofern man Module verwendet, lassen sich Programme mit JDK 9 nicht mehr ohne Weiteres wie gewohnt starten, wenn diese externe Abhängigkeiten besitzen. Das liegt vor allem daran, dass Abhängigkeiten nun beim Programmstart geprüft und dazu explizit beschrieben werden müssen.

Es gibt aber einen rein auf dem CLASSPATH basierenden Kompatibilitätsmodus, der ein Arbeiten wie bis einschließlich JDK 8 gewohnt ermöglicht.

Entdeckungsreise JDK 9 – Wünsche an die Leser

Ich wünsche allen Lesern viel Freude mit diesem Buch sowie einige neue Erkenntnisse und viel Spaß beim Experimentieren mit JDK 9. Möge Ihnen der Umstieg auf die neue Java-Version und die Migration bestehender Anwendungen in modulare Applikationen durch die Lektüre meines Buchs leichter fallen. Wenn Sie zunächst eine Auffrischung Ihres Wissens zu Java 8 und seinen Neuerungen benötigen, bietet sich ein Blick in den Anhang A an.

Tipp: IDE-Support und Kompatbilitätsmodus

Alle derzeit relevanten IDEs, also Eclipse, IntelliJ IDEA und NetBeans, erlauben es in ihren aktuellen Versionen, Java 9 zu nutzen. Die IDEs lassen sich allerdings eventuell (noch) nicht ohne Weiteres mit JDK 9 starten. Mitunter ist es ratsam, zusätzlich zu JDK 9 ein aktuelles JDK 8 installiert zu haben. Weitere Informationen zu Konfigurationen finden Sie in Kapitel 9.

Kompatbilitätsmodus

Zum Ausprobieren einiger Neuerungen aus JDK 9 werden wir kleine Applikationen in main()-Methoden erstellen. Dabei ist es für erste Experimente und für die Migration bestehender Anwendungen von großem Vorteil, dass man das an sich modularisierte JDK 9 auch ohne eigene Module und ihre Sichtbarkeitsbeschränkungen betreiben kann. In diesem Kompatbilitätsmodus wird wie zuvor bei Java 8 mit .class-Dateien, JARs und dem CLASSPATH gearbeitet. Für zukünftige Projekte wird man aber bevorzugt Module nutzen wollen. Das schauen wir uns nach der Vorstellung einiger wichtiger Änderungen in JDK 9 in eigenen Kapiteln an.

Teil I

Sprach- undAPI-Erweiterungen

2Syntaxerweiterungen

Bereits in JDK 7 wurden unter dem Projektnamen Coin verschiedene kleinere Syntaxerweiterungen in Java integriert. Für JDK 9 gab es ein Nachfolgeprojekt, dessen Neuerungen wir uns jetzt anschauen.

2.1Anonyme innere Klassen und der Diamond Operator

Bei der Definition anonymer innerer Klassen konnte man den Diamond Operator bis JDK 8 leider nicht nutzen, sondern der Typ aus der Deklaration war auch bei der Definition explizit anzugeben. Praktischerweise ist es mit JDK 9 (endlich) möglich, auf diese redundante Typangabe zu verzichten. Als Beispiel dient die Definition eines Komparators mit dem Interface java.util.Comparator<T>.

Beispiel mit JDK 8

Bis JDK 8 musste man bei der Definition einer anonymen inneren Klasse den Typ noch wie folgt angeben:

Beispiel mit JDK 9

Die Änderung zu JDK 8 ist kaum sichtbar: Mit JDK 9 ist es nun erlaubt, die Typangabe wegzulassen und somit den Diamond Operator zu verwenden, wie wir dies von anderen Variablendefinitionen bereits gewohnt sind:

2.2Nutzung von »effectively final«-Variablen im ARM

Das mit JDK 7 eingeführte Automatic Resource Management (ARM), auch try-with-resources genannt, erleichtert die Arbeit mit und die Freigabe von Ressourcen, indem automatisch die close()-Methode der korrespondierenden Ressourcenvariablen aufgerufen wird. Damit solche Variablen in ARM nutzbar sind, müssen diese das Interface java.lang.AutoCloseable erfüllen und zudem unveränderlich sein. Mit JDK 9 gibt es eine Vereinfachung für den Fall, dass bereits Ressourcenvariablen außerhalb des ARM-Blocks definiert sind. Das ist jedoch eher eine Ausnahme. Häufiger findet man wohl die Definition von Ressourcenvariablen direkt im ARM, die von dieser Neuerung nicht betroffen ist.

Beispiel mit JDK 8

Im folgenden Listing sind zwei Ressourcenvariablen bufferedIs und bufferedOs außerhalb des ARM-Blocks definiert. Bis einschließlich JDK 8 musste man für derartige Szenarien beim Einsatz von ARM immer (künstlich) noch jeweils eine weitere Variable im try-Block definieren, selbst dann, wenn die eigentliche Ressourcenvariable bereits unveränderlich war. Das Ganze war etwas schwierig zu lesen:

Im Beispiel sind bewusst die Variablen vom Typ java.io.BufferedInputStream als final und java.io.BufferedOutputStream als nicht final definiert, um zu zeigen, dass ARM sowohl mit final- als auch mit »effectively final«-Variablen verwendbar ist: Der Compiler kann die Unveränderlichkeit einer Variablen selbst dann erkennen, wenn diese nicht explizit final definiert ist, sondern lediglich ihren Wert nicht mehr ändert, also als »effectively final« zu betrachten ist.

Beispiel mit JDK 9

Für außerhalb des ARM-Blocks definierte Ressourcenvariablen wird mit JDK 9 die Syntax und die Nutzung ein wenig erleichtert. Sofern man bereits eine final oder »effectively final« definierte Ressourcenvariable besitzt, kann diese direkt im try-Block von ARM verwendet werden. Dadurch wird der Sourcecode ein wenig kürzer und man vermeidet die erneute Definition einer Variablen:

2.3Neuerung bei der @SafeVarargs-Annotation

Mit der Annotation @SafeVarargs kann man dem Compiler im Falle von Vararg-Parametern eine Hilfestellung geben, wenn es Uneindeutigkeiten bei der Verwendung gibt. Was ist damit gemeint und wie kann es zu dem Problem kommen? Schauen wir uns dazu ein einführendes Beispiel an:

// Simple Methode mit Vararg-Parameter

private static <T> void printAll(T... elements)

{

for (final T elem : elements)

{

System.out.println(elem + " of type " + elem.getClass());

}

}

public static void main(final String[] args)

{

// Keine Compiler-Warnung

printAll("Hello", "Varargs");

// Type safety: A generic array of List<String> is created

// for a varargs parameter

printAll(Arrays.asList("A", "B"), Arrays.asList("C", "D"));

}

Weil ein Vararg-Parameter intern wie ein Array gehandhabt wird und Generics und Arrays leider nicht ideal zusammenarbeiten, kommt es bei der Kombination von Generics und Varargs immer wieder zu Problemen, was oftmals – wie auch hier – zu Compiler-Warnungen führt. Das liegt insbesondere daran, dass die mit Generics angegebenen Typinformationen beim Kompilieren weitestgehend durch die sogenannte Type Erasure aus dem Bytecode entfernt werden. Darauf gehe ich im Anschluss an die Vorstellung von @SafeVarargs in einem Praxishinweis nochmals ein.

Wenn man als Entwickler einer Methode sicher ist, dass deren Verarbeitung ihres Vararg-Parameters keine Typprobleme verursacht, kann man die Annotation @SafeVarargs angeben – beachten Sie dazu bitte auch den folgenden Abschnitt »Vorsicht bei Vergabe der Annotation @SafeVarargs«. Für das Beispiel lässt sich die Compiler-Warnung wie folgt vermeiden:

@SafeVarargs

private static <T> void printAll(T... elements)

{

for (final T elem : elements)

{

System.out.println(elem + " of type " + elem.getClass());

}

}

Damit scheint das Problem gelöst. Doch was wäre, wenn die Methode nicht static wäre, sondern eine Instanzmethode? Dann käme es bis JDK 8 zu der Fehlermeldung @SafeVarargs annotation cannot be applied to non-final instance method printAll. Das liegt schlicht daran, dass bis JDK 8 die Annotation @Safe-Varargsnur für finale oder statische Methoden verwendet werden kann, weil sich nur so Effekte durch Overriding verhindern lassen. Private Methoden kann man auch ohne explizite Angabe von final nicht überschreiben, weshalb hier auch die Annotation anwendbar sein sollte. Das wird mit JDK 9 möglich.

Neuerung in JDK 9: @SafeVarargs für private Methoden

Als Beispiel für die Neuerung in JDK 9 betrachten wir nachfolgende Hilfsmethode firstOrEmpty(T...), die das erste Element liefert, sofern das übergebene Array nicht leer ist, und ansonsten den Rückgabewert von java.util.Optional.empty():

Vorsicht bei Vergabe der Annotation @SafeVarargs

Prüfen Sie immer genau, ob die Annotation @SafeVarargs wirklich vergeben werden kann und dadurch tatsächlich keine Probleme ausgelöst werden. Im JDK findet man in der Onlinedokumentation folgendes Gegenbeispiel, in dem als Vararg-Parameter eine List<String>... entgegengenommen und dann mutwillig in den allgemeinsten Typ Object[] umgewandelt wird:

Die Zuweisung einer List<Integer> wird vom Compiler zwar erlaubt, ist aber unsinnig und nicht typsicher. Für Arrays würde zur Laufzeit eine java.lang.Array-StoreException ausgelöst.1 Im Beispiel kommt es für die generische Liste dagegen beim Auslesen zu einer java.lang.ClassCastException.

2.4Erweiterung der @Deprecated-Annotation

Die @Deprecated-Annotation dient bekanntlich zum Markieren von obsoletem Sourcecode und besaß bislang keine Parameter. Das ändert sich mit JDK 9: Die @Deprecated-Annotation wurde um die zwei Parameter since und forRemoval erweitert. Die Annotation ist nun im JDK wie folgt definiert:

@Documented

@Retention(RetentionPolicy.RUNTIME)

@Target(value={CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE, PARAMETER,

TYPE})

public @interface Deprecated {

/**

* Returns the version in which the annotated element became deprecated.

* The version string is in the same format and namespace as the value of

* the {@code @since} javadoc tag. The default value is the empty

* string.

*

* @return the version string

* @since 9

*/

String since() default "";

/**

* Indicates whether the annotated element is subject to removal in a

* future version. The default value is {@code false}.

*

* @return whether the element is subject to removal

* @since 9

*/

boolean forRemoval() default false;

}

Diese Erweiterung wurde nötig, weil in Zukunft geplant ist, veraltete Funktionalität aus dem JDK zu entfernen, statt sie – wie bislang für Java üblich – aus Rückwärtskompatibilitätsgründen ewig beizubehalten. Das folgende Beispiel zeigt eine Anwendung, wie sie aus dem JDK stammen könnte:

Diese Erweiterung der @Deprecated-Annotation kann man selbstverständlich auch für eigenen Sourcecode nutzen und so anzeigen, dass gewisse Funktionalitäten für die Zukunft nicht mehr angeboten werden sollen. Darüber hinaus empfiehlt es sich, in einem Javadoc-Kommentar das @deprecated-Tag zu verwenden und dort den Grund der Deprecation und eine empfohlene Alternative aufzuführen. Nachfolgend ist dies exemplarisch für eine veraltete Methode someOldMethod() gezeigt:

2.5Private Methoden in Interfaces

Allgemein bekannt ist, dass Interfaces der Definition von Schnittstellen dienen. Leider verlieren in Java die Interfaces immer mehr von ihrer eigentlichen Bedeutung. Unter anderem wurden mit JDK 8 statische Methoden und Defaultmethoden in Interfaces erlaubt. Mit beiden kann man Implementierungen in Interfaces vorgeben.2 Das führt allerdings dazu, dass sich Interfaces kaum mehr von einer abstrakten Klasse unterscheiden: Abstrakte Klassen können ergänzend einen Zustand in Form von Attributen besitzen, was in Interfaces (noch) nicht geht.

Mit JDK 9 wurde der Unterschied zwischen Interfaces und abstrakten Klassen nochmals verringert, weil nun auch die Definition privater Methoden in Interfaces erlaubt ist. Das Argument dafür war, dass sich damit die Duplikation von Sourcecode in Defaultmethoden reduzieren ließe. Das mag richtig sein. Allerdings ist es für die meisten Anwendungsprogrammierer eher fraglich, ob diese jemals Defaultmethoden selbst implementieren sollten. Trotz dieser Kritik möchte ich Ihnen das Feature anhand eines Beispiels vorstellen, da es eventuell für Framework-Entwickler von Nutzen sein kann.

Beispiel

Schauen wir uns zur Demonstration privater Methoden in Interfaces das nachfolgende Listing und vor allem die private Methode myPrivateCalcSum(int,int) sowie deren Aufruf aus den beiden öffentlichen Defaultmethoden an:

Kommentar

Vielleicht fragen Sie sich, warum ich den privaten Methoden in Interfaces so ablehnend gegenüberstehe. Tatsächlich wurde die Büchse der Pandora bereits mit JDK 8 und den Defaultmethoden geöffnet. Die privaten Methoden mögen für Framework-Entwickler mitunter praktisch sein, jedoch besteht die Gefahr, dass sie für »normale« Entwickler noch attraktiver werden und von diesen somit ohne großes Hinterfragen zur Applikationsentwicklung eingesetzt werden. Das wäre im Hinblick auf das Design und die Klarheit von Business-Applikationen ein Schritt in die falsche Richtung. Dadurch wird unter Umständen dem Schnittstellenentwurf weniger Aufmerksamkeit gewidmet, basierend auf der Annahme, dass benötigte Funktionalität immer noch nachträglich hinzugefügt werden kann. Allerdings verliert dieser Nachteil bei Nutzung einer modernen Microservice-Architektur ein wenig an Gewicht, da die Designsünde in einem solchen Fall relativ isoliert existiert.

2.6Verbotener Bezeichner ’_’

Bei den Bezeichnern gibt es eine kleine Änderung: Der Compiler erlaubt mit JDK 9 das Zeichen _ (Unterstrich) nicht mehr als Bezeichner.

Während folgende Zeile mit JDK 8 noch kompilierte

produziert der Java-Compiler mit JDK 9 folgende Fehlermeldung:

as of release 9, ’_’ is a keyword, and may not be used as an identifier

Ich persönlich halte ein einzelnes Zeichen als Variablenbezeichner fast immer für einen Bad Smell und insbesondere gilt dies für den Unterstrich.

3Neues und Änderungen im JDK

Nachdem wir diverse kleinere Änderungen in der Syntax der Sprache Java kennengelernt haben, wollen wir uns in diesem Kapitel relevante Erweiterungen im JDK anschauen. Erwähnenswert sind das neue Process-API, die Ergänzungen im Stream-API sowie in java.util.Optional<T>, aber auch die neuen Collection-Factory-Methoden. Darüber hinaus findet man Ergänzungen in den Klassen java.io.InputStream und java.util.ResourceBundle sowie diverse Neuerungen, unter anderem auch im Bereich Concurrency: Die Klasse java.util.concurrent.CompletableFuture<T> bietet mehr Funktionalität. Wesentlicher ist vermutlich aber die Unterstützung von Reactive Streams durch die im Package java.util.concurrent neu eingeführte Klasse Flow. Auch im Bereich von Unicode, Grafikformaten sowie Desktop-Technologie mit HiDPI-Support und Unterstützung der Taskbar bzw. des Docks hat sich einiges weiterentwickelt. Außerdem wurden Utility-Klassen wie java.util.Objects und java.util.Arrays sinnvoll ergänzt.

3.1Neue APIs

Wie bereits angedeutet, wurden in den APIs des JDKs diverse Verbesserungen vorgenommen und Neuerungen integriert, die wir nun thematisch gruppiert anschauen wollen. Dabei beginnen wir mit den Neuerungen im Process-API.

3.1.1Das neue Process-API

Bis einschließlich JDK 8 sind die Möglichkeiten recht eingeschränkt, wenn es darum geht, Prozesse des Betriebssystems zu kontrollieren und zu verwalten.

PID mit JDK 8 ermitteln

Ein simples Beispiel ist die Ermittlung der ID eines Prozesses, kurz PID genannt. Je nach Plattform muss man dies mit Java 8 unterschiedlich implementieren. Für Linux und Mac OS führt man dazu ein Shell-Kommando mit der Methode exec() aus der Klasse java.lang.Runtime aus – das korrespondierende Windows-Kommando unter Einsatz der Powershell ist als commandsWin definiert:

Im Listing wird ersichtlich, wie aufwendig das Auslesen der Informationen aus dem InputStream des erzeugten Prozesses ist und dass sogar rein theoretisch der Fall behandelt werden müsste, dass keine gültige Zahl zurückgeliefert wird – was wohl nur in Ausnahmesituationen bei Lesefehlern der Streams geschehen könnte und was wir hier der Vereinfachung halber außer Acht lassen.

Hinweis: Die Klasse Runtime

Java ist weitestgehend betriebssystemunabhängig. Manchmal ist es aber wünschenswert, externe Programme in Form von Prozessen auszuführen. Dies ist durch den Aufruf von exec() der Klasse Runtime möglich. Dadurch entsteht ein neues java.lang.Process-Objekt. Mit dessen Methode waitFor() kann man blockierend auf das Ende des Prozesses warten und anschließend mit der Methode exitValue() den Rückgabewert erfragen.

Zudem erhält man über getOutputStream(), getInputStream() und get-ErrorStream() Zugriff auf die dem Process zugeordneten Ein- und Ausgabeströme. Dabei sind allerdings einige Details zu beachten. Zunächst ist der Zugriff auf diese Streams insofern wichtig, als dass der erzeugte Prozess keine Konsole zur Ausgabe hat und dadurch die Ausgaben auf System.out an den Vaterprozess weitergeleitet werden. Auch kann man Eingaben an einen Subprozess weiterleiten. Dabei empfiehlt es sich, möglichst zeitnah aus den Streams zu lesen und nicht erst nach Terminierung des Prozesses, da es ansonsten zu Blockierungen und Deadlocks kommen kann.

PID mit JDK 9 ermitteln

Die Abfrage der PID mit Java 9 wird mithilfe der Klasse java.lang.ProcessHandle nun deutlich kürzer, besser lesbar und verständlich:

private static long getPidJdk9Style() throws InterruptedException, IOException

{

return ProcessHandle.current().pid();

}

Neben den genannten Vorteilen bietet die Methode pid() einen betriebssystemunabhängigen Weg zur Ermittlung der Prozess-ID (zumindest aus Sicht des Aufrufers).

Beispielprogramm

Wir wollen die beiden Methoden in Aktion erleben und deren Ergebnis prüfen. Dazu schreiben wir folgendes Programm:

public static void main(final String[] args) throws InterruptedException, IOException

{

System.out.println("PID old: " + getPidJdk8Style());

System.out.println("PID new: " + getPidJdk9Style());

}

Listing 3.1Ausführbar als’PIDEXAMPLE’

Startet man das Programm PIDEXAMPLE, so sieht man anhand der Ausgabe identischer Prozess-IDs, dass beide Varianten funktional übereinstimmen:

PID old: 41948

PID new: 41948

Das Interface ProcessHandle

Neben der PID kann man mithilfe von ProcessHandle noch diverse weitere Informationen zu Prozessen auslesen. Dazu gibt es unter anderem folgende Methoden:

current()

– Ermittelt den aktuellen Prozess als

ProcessHandle

.

info()

– Stellt Infos zum Prozess in Form des inneren Interface

ProcessHandle.Info

bereit, etwa zu Benutzer, Kommando usw.

info().command()

– Gibt das Kommando als

Optional<String>

aus einem

ProcessHandle.Info

zurück.

info().user()

– Liefert den Benutzer als

Optional<String>

aus einem

ProcessHandle.Info

.

info().totalCpuDuration()

– Ermittelt aus den Infos die benötigte CPU-Zeit als

Optional<Duration>

. Die Klasse

java.time.Duration

entstammt dem mit JDK 8 neu eingeführten Date and Time API.

1

Zum besseren Verständnis dieser Methoden betrachten wir ein Beispiel:

Listing 3.2Ausführbar als’PROCESSHANDLEEXAMPLE’

Das Programm PROCESSHANDLEEXAMPLE gibt in etwa Folgendes aus (gekürzt):

PID: 13670

Info: [user: Optional[michaeli], cmd: /Library/Java/JavaVirtualMachines/jdk

-9.jdk/Contents/Home/bin/java, args: [-Dfile.encoding=UTF-8, -Duser.country

=DE, -Duser.language=de, -Duser.variant, -cp, /Users/michaeli/Desktop/

PureJava9/quelltext/build/libs/Java9-all.jar:/Users/michaeli/Desktop/

PureJava9/quelltext/build/requiredLibs, ch3_1.processapi.

ProcessHandleExample], startTime: Optional[2017-04-06T17:21:56.927Z],

totalTime: Optional[PT0.230888S]]

Command: Optional[/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/

bin/java]

CPU-Usage: Optional[PT0.308141S]

Neben der PID werden diverse Informationen aus dem Info-Objekt aufgelistet, exemplarisch separat nochmals die Werte für command() und totalCpuDuration(). Für das mit command() als Optional<String> ermittelte Kommando erkennen wir, dass es sich um das Programm java aus JDK 9 handelt, das laut totalCpuDuration() etwa 0.31 Sekunden CPU-Zeit verbraucht hat, wie man anhand von Optional<Duration> sieht.

Alle Prozesse mit ProcessHandle abfragen

Neben Informationen zum aktuellen Prozess lassen sich Informationen für alle Prozesse des Benutzers sowie alle Subprozesse zu einem Prozess wie folgt ermitteln:

allProcesses()

– Liefert alle Prozesse als

Stream<ProcessHandle>

.

children()

– Ermittelt zu einem Prozess alle seine (direkten) Subprozesse als

Stream<ProcessHandle>

.

Im nachfolgenden Beispiel iterieren wir über das Ergebnis von allProcesses() und geben Infos zu solchen Prozessen aus, die Subprozesse besitzen. Die Anzahl an Subprozessen können wir durch Aufruf von children().count() erfragen:

Listing 3.3Ausführbar als’ALLPROCESSHANDLESEXAMPLE’

Das Programm ALLPROCESSHANDLESEXAMPLE produziert die folgenden Ausgaben (gekürzt), die eine Liste der zurückgelieferten Informationen widerspiegeln:

All Processes:

Info: [user: Optional[michaeli], cmd: /Applications/Adobe Acrobat Reader DC.app/

Contents/MacOS/AdobeReader, args: [-psn_0_3822501], startTime: Optional

[2016-08-02T21:16:30.322Z]] has 3 children

...

Info: [user: Optional[michaeli], cmd: /System/Library/CoreServices/Dock.app/

Contents/MacOS/Dock, startTime: Optional[2016-07-24T08:17:12.938Z]] has 1 children

Info: [user: Optional[root], startTime: Optional[2016-07-24T08:16:40.564Z]] has

285 children

Prozesse mit ProcessHandle kontrollieren

Neben der Bereitstellung und Abfrage von Informationen zu Prozessen existieren auch verschiedene Möglichkeiten, Prozesse zu beenden sowie auf das Ende eines Prozesses zu reagieren. Dazu findet man im Interface ProcessHandle folgende Methoden:

of(long)

– Liefert ein

Optional<ProcessHandle>

zu einer gegebenen PID.

destroy()

– Terminiert einen Prozess, sofern dies erlaubt ist. Ansonsten, etwa für den mit

current()

ermittelten Prozess, wird eine Exception ausgelöst:

Exception in thread "main" java.lang.IllegalStateException: destroy of

current process not allowed

onExit()

– Liefert ein

CompletableFuture<ProcessHandle>

zurück, das man dazu nutzen kann, verschiedene Aktionen als Reaktion auf das Ende eines Prozesses auszuführen.

Zur Demonstration dieser Methoden wollen wir ein Beispiel erstellen. Es soll zunächst mit Runtime.exec() ein Prozess gestartet werden. Als Rückgabe erhält man ein Process-Objekt. Dieses bietet seit JDK 9 ebenfalls die Methode pid() sowie diverse andere, die auch durch ProcessHandle bereitgestellt werden. Auch kann man ein Process-Objekt durch einen Aufruf von toHandle() in ein ProcessHandle-Objekt transformieren:

Listing 3.4Ausführbar als’CONTROLPROCESSEXAMPLE’

Startet man das Programm CONTROLPROCESSEXAMPLE, so können wir anhand der folgenden Ausgaben recht gut die im Listing definierten Aktionen nachvollziehen:

Started process is 60392

Same handle? true

Registered exitHandler

Destroying process 60392

exitHandler called

Fazit

Wir haben in verschiedenen Beispielen kennengelernt, wie man mit dem neuen Process-API mit Prozessen des Betriebssystems interagieren oder zumindest Informationen darüber gewinnen kann. Die große Stärke des Process-APIs ist, dass die Aktion aus Sicht eines Java-Entwicklers betriebssystemunabhängig erfolgen kann. Damit kommt man Javas Versprechen von einer weitestgehend betriebssystemunabhängigen Programmierung wieder ein Stück näher.

3.1.2Collection-Factory-Methoden

Das Erzeugen von Collections für ein paar vordefinierter Werte ist in Java mitunter etwas umständlich. Sprachen wie Groovy oder Python bieten dafür eine spezielle Syntax, sogenannte Collection-Literale. Bereits 2009 hat man auch für Java über eine Integration einer einfacheren Schreibweise zur Erzeugung von und zum Zugriff auf Collections nachgedacht. Leider wurde nichts Derartiges realisiert, obwohl es einige, vielversprechende Vorschläge gab.

Vorschlag: Collection-Literale und Collection-Erzeugung

Nachfolgendes Listing zeigt, wie eine mögliche Syntax für Collection-Literale für die im Package java.util definierten Collections List<E>, Set<E> und Map<K,V> aussehen könnte. Dabei werden die Elemente der Collection in geschweifte oder eckige Klammern eingeschlossen:

Möglichkeiten mit JDK 8Mit JDK 8 existieren folgende gebräuchliche Varianten, um eine Liste zu befüllen – auf die Darstellung der Variante mit den doppelten geschweiften Klammern verzichte ich hier:

Beide Varianten besitzen jedoch ihre Nachteile. Die erste ist offensichtlich viel länger als der Einsatz eines Collection-Literals. Variante 2 ist zwar ähnlich kurz, erlaubt aber im Gegensatz zu Variante 1 keine nachträglichen Modifikationen an der Zusammensetzung der Liste,2 was aber durchaus auch als Vorteil gewertet werden kann.

Nützliche Utility-Funktionalität rund um Collections finden Sie übrigens auch in der Bibliothek Google Guava (https://github.com/google/guava), die ich in meinem Buch »Der Weg zum Java-Profi« [5] ein wenig genauer beschreibe.

Vorschlag: Collection-Literale und Datenzugriff

Während man auf Arrays indiziert mit eckigen Klammern zugreift, muss man für Listen die Methode get(int) und für Maps die Methode get(K) nutzen. Wertzuweisungen erfolgen durch Aufruf von set(int,E) bzw. put(K,V).

Für indizierte Zugriffe und Wertzuweisungen auf Listen bzw. Zugriffe auf Schlüssel und Werte bei Maps war für Java eine Notation analog zu indizierten Array-Zugriffen vorgesehen, wodurch explizite Methodenaufrufe überflüssig geworden wären:

Realisierung mit JDK 9

Leider wurden Collection-Literale nicht in der zuvor beschriebenen Form in Java 9 realisiert. Stattdessen wurde eine Armada an Factory-Methoden mit den Namen of() bzw. ofEntries() in die Interfaces List<E>, Set<E> und Map<K,V> integriert, die sich wie folgt zur Erzeugung von Collections nutzen lassen:3

Listing 3.5Ausführbar als‘COLLECTIONFACTORYMETHODSEXAMPLE’

Das Programm COLLECTIONFACTORYMETHODSEXAMPLE gibt Folgendes aus:

MAX

MORITZ

MIKE

1

2

3

6:six

5:five

6:six

5:five

Die Reihenfolge der Elemente bei Sets und Maps ist bei der Nutzung der Collection-Factory-Methoden allerdings nicht definiert und insbesondere wird die Einfügereihenfolge oftmals nicht beibehalten. Auch die Reihenfolge bei einer Iteration ist zufällig, sodass es durchaus etwa zu folgenden Ausgaben kommen kann:

MAX

MORITZ

MIKE

3

2

1

5:five

6:six

5:five

6:six

Besonderheiten bei der Konstruktion In den jeweiligen Collection-Interfaces sind die Collection-Factory-Methoden explizit für 0 bis 10 Parameter sowie als Vararg-Variante definiert. Allerdings führt diese performanceoptimierte Realisierung zu einer Menge an Methoden. Zudem gibt es für den Fall mit dem Vararg-Parameter noch einen speziellen switch-case, der die spezialisierten Methoden aufruft:

static <E> List<E> of() {

return ImmutableCollections.List0.instance();

}

static <E> List<E> of(E e1) {

return new ImmutableCollections.List1<>(e1);

}

...

@SafeVarargs

@SuppressWarnings("varargs")

static <E> List<E> of(E... elements) {

switch (elements.length) {

case 0:

return new ImmutableCollections.List0<>();

case 1:

return new ImmutableCollections.List1<>(elements[0]);

case 2:

return new ImmutableCollections.List2<>(elements[0], elements[1]);

default:

return new ImmutableCollections.ListN<>(elements);

}

}

Glücklicherweise sieht man diese Implementierungsdetails nur dann, wenn man in den JDK-Sourcecode schaut. Allerdings scheint diese Unschönheit zumindest in der IDE bei der Auto-Completion durch, die eine Horde gleichnamiger Methoden anbietet.

Space Efficiency Das obige Listing zeigt, dass spezielle innere Klassen aus der Klasse java.util.ImmutableCollections erzeugt werden. Neben ihrer Unveränderlichkeit und auf Arrays basierenden Spezialimplementierungen zeichnen sich die durch die Collection-Factory-Methoden erzeugten Collections dadurch aus, dass sie viel weniger Speicherplatz verbrauchen als diejenigen aus dem Collections-Framework. Betrachten wir ein java.util.HashSet<String> mit zwei Elementen: