Archiv der Kategorie: Java 9

Was Eclipse bisher bei Java 9 unterstützt

Siehe https://wiki.eclipse.org/Java9/Examples

Feature / Steps
Expected Result

The Pre-requisite: Java 9 JRE Support

Add Java 9 JRE
Use Eclipse Preferences -> Java -> Installed JREs -> Add

Addj9.jpg

Java 9 JRE recognized as a valid JRE

Project JRE
In Package Explorer Use Project Context Menu and add Java 9 JRE
JRE specific (eg Object) gets resolved in the project.

Package Explorer
Go to Package Explorer and expand the Java 9 JRE
Modules (eg java.base etc) are listed in the package explorer view

The First Step: Module Creation

Manual
Context Menu of src -> New -> File – give the module-info.java as name
no compiler errors

Automatic
Context Menu of Project -> Cofigure -> Create module-info.

AutomoduleCreate.jpg

A default module-info.java with all packages exported should be created

Basic Necessity : Compilation, Module Dependency & Error Reporting

Unspecified Dependency
create projects "first" and "second" and create module-info.java files in each of giving the module names "first" and "second" respectively.

In the first module add the directive requires second; . This initial configuration would look something similar to the one shown in the figure.
Initmods.jpg

Compiler gives error "second cannot be resolved to a module"

Define Dependency
In the above scenario, add Project second as a dependent project for project first
Compiler error goes away

Duplicate Dependency
Continuing from the above scenario, add a duplicate requires second; directive in the module-info.java file of the first
Compiler gives error "Duplicate requires entry: second"

Circular Dependency
add a circular dependency ie

add second project dependent on first
add requires first; directive in the module-info.java file of the second project ie replace // empty by design comment by this directive

Two compiler errors " Cycle exists in module dependencies, Module second requires itself via first"

Editing with Ease: Completion in module-info.java file

Keyword Completion (1)
In the module-info.java file of say second project, after module first {, press completion key (for eg, ctrl+space in windows)

Keycomplete1.jpg

keywords exports, opens, requires, provides and uses shown

Keyword Completion (2)
after exports packagename, or opens packagename press completion key
keyword to is shown as an option

Package Completion
after exports, opens, provides or uses, press completion key
package completion shown.

Type Reference Completion
after exports, opens, provides or uses, or optionally after a dot after a package, ie exports packagename. press completion key
Type completion shown.

Implementation TypeRef Completion
after provides typename with press completion key
Type completion shown and these typereferences are implementations of the type given before with.

The Essential Utilities: Code Select, Hover, Navigate, Search and Rename

Module Select & Hover

In the module-info.java file of the first project, select second in the requires second; directive
Hover.jpg

Hover appears

Module Select, Hover & Navigate
In the above scenario, after hover appears, click on the navigate
module-info.java file of second opened

Module Select, & Search

In the module-info.java file of the second project, select second in module declaration module second { and search for references
Modsearch2.jpg

In the search view, the reference in directive requires second; in file first -> module-info.java is shown.

Package Search

create package pack1 to the project first.
add exports pack1; directive in module-info.java file of first.
search for references of pack1

In the search view, the reference of pack1 in directive exports pack1; in file first -> module-info.java is shown, similar to other pack1references if any

Type Search
create Type X in the project first, add directive uses X; in module-info.java file of first, and search for references of X
In the search view, the reference of Xin directiveuses X; in file first -> module-info.java is shown, similar to other Xreferences if any

Code Select & Rename
in module-info.java file of first, select X in directive uses X; and rename to X11
rename exhibits usual behavior – renames definition and references of Xto X11

The Outlier: Milling Project Coin Enhancements

@Safevarargs
@SafeVarargs is now allowed on private instance methods. There is even a support of quick assist for that. Use the following code which has warnings, and use the quick assist at the point mentioned in the comment

package packsafe;
import java.util.ArrayList;
import java.util.List;   public class SafeVar {
	private int getLen(List<String>...list) {
		List<String>[] l = list;
		return l.length;
	}   public static void main(String[] args) {
		SafeVar x = new SafeVar();
		List<String> l = new ArrayList<>();
		int len = x.getLen(l); // Use Quick Assist of SafeVarargs here<br>
		System.out.println("Length:" + len);
	}
}

@SafeVarargsinserted before getLen() and the warnings go away

Effectively Final Autoloseables

Effectively-final variables are allowed to be used as resources in the try-with-resources statement. The code below has an error. Try removing the line t1 = null; // Remove this code .

package packtry;
import java.io.Closeable;
import java.io.IOException;   class Two implements Closeable {
	@Override
	public void close() throws IOException {
		// nothing
	}
}
public class TryStmtTwo {   public void foo() throws IOException {
		Two t1 = new Two();
		try (t1; final Two t2 = new Two()) {
		// Empty by design
	}
	t1 = null; // Remove this code
	}
	public static void main(String[] args) {
		System.out.println("Done");
	}
}

Code without errors. For the more inquisitive, check the generated code to see that the close is generated for t1 as well which is not a final variable but an effectively final variable.

Anonymous Diamond

In the following code, there is a warning about Y being a raw type and need to be parameterized. with Java 9 support, just add a diamond operator after Y.

public class Dia {
@SuppressWarnings("unused")
	public static void main(String[] args) {
		Y<?> y1 = new Y(){}; // Change this to new Y<>(){}
	}
}
class Y<T> {}

Diamond operator <>accepted and code compiles without warning

Illegal Underscore

Underscore is an illegal identifier from Java 9 onwards. Uncomment the commented line in the following example

public class UnderScore {
	//Integer _ ;
}

error: "’_‘ should not be used as an identifier, since it is a reserved keyword from source level 1.8 on"

Private Methods

private interface methods are allowed. Change the default of worker to private

public interface I {
	default void worker() {}<   default void foo() {
		worker();
	}   default void bar() {
		worker();
	}
}

Code compiles with privateas well. Note that this is a useful feature if two default methods wants to share the worker code and does not want the worker to be an public interface method.

Reaktive Programmierung und die Flow-API

Sollen Produzenten und Konsumenten entkoppelt werden, so gibt es eine Reihe von Möglichkeiten. Nehmen wir zum Beispiel einen Iterator, der eine einfache API definiert, sodass sich auf immer die gleiche Art und Weise Daten von einem Produzenten abholen lassen. Oder nehmen wir einen Beobachter (Observer/Listener): ein Produzent verschickt seine Daten an Interessenten. Oder nehmen wir ein Bussystem: Publisher (Sender) und Subscriber (Empfänger) senden Datenpakete über einen Bus. All diese Design-Pattern sind für bestimmte Anwendungsfälle gut, haben jedoch alle eine Schwäche: es entstehen oft Blockaden und die Gefahr der Überflutung mit Nachrichten besteht.

Neu in Java 9 sind Schnittstellen eingezogen, die vorher unter http://www.reactive-streams.org/ diskutiert und als Defacto-Standard gelten. Ziel ist die Standardisierung von Programmen, die „reaktiv“ programmiert sind. Grundidee ist, dass es Publisher und Subscriber gibt, die einen asynchron Datenstrom austauschen aber nicht blockieren und mit „Gegendruck“ (engl. back pressure) arbeiten. Vergleichen wir das mit dem bekannten Bussystem, dann wird das Problem schnell klar; es kann passieren, dass ein Publisher viel zu schnell Ereignisse produziert, und die Subscriber nicht mitkommen, wo sollen dann die Daten hin? Oder, wenn der Publisher nichts sendet, dann wartet der Subscriber blockierend. Genau diese Probleme möchte das reaktive Modell vermeiden, in dem zwischen Publisher und Subscriber liegt ein Vermittler eingeschaltet wird, der über Gegendruck steuert, dass der Subscriber Daten anfordert und der Publisher dann so viel sendet, wie nicht-blockierend verarbeitet werden kann. Das realisiert eine Flusskontrolle, sodass wir auch von der Flow-API sprechen.

Die API ist untergebraucht in einer finalen Klasse java.util.concurrent.Flow, die vier statische innere Schnittstellen deklariert:

@FunctionalInterface  

public static interface Flow.Publisher<T> { 

    public void    subscribe(Flow.Subscriber<? super T> subscriber); 

}  

 

public static interface Flow.Subscriber<T> { 

    public void    onSubscribe(Flow.Subscription subscription); 

    public void    onNext(T item) ; 

    public void    onError(Throwable throwable) ; 

    public void    onComplete() ; 

}  

 

public static interface Flow.Subscription { 

    public void    request(long n); 

    public void    cancel() ; 

}  

 

public static interface Flow.Processor<T,R>  extends Flow.Subscriber<T>, Flow.Publisher<R> { 

}

Es ist gar nicht Aufgabe der Java SE diverse Implementierungen für die Schnittstellen bereitzustellen; es gibt lediglich von Publisher eine Implementierung, java.util.concurrent.SubmissionPublisher<T> . Allgemein sind die Implementierungen aber nicht trivial und daher ist es ratsam, sich mit zum Beispiel RxJava, „Reactive Extensions for the JVM“ (https://github.com/ReactiveX/RxJava) und Akka Streams (http://doc.akka.io/docs/akka/2.5.3/java/stream/index.html) zu beschäftigen, die Datenströme sehr schön in eine Kette verarbeiten können. Der eigentliche Wert der Java SE-Schnittstellen ist, dass es damit zu einer offiziellen API wird und Algorithmen problemlos unter den reaktiven Bibliotheken ausgetauscht werden können.

Asnychrones Programmieren mit CompletableFuture (CompletionStage)

So schöne an Future-Objekten ist die Abarbeitung im Hintergrund und die Möglichkeit, später abzufragen, ob das Ergebnis schon da ist. Allerdings fehlt der Future-Schnittstelle eine Methode, automatisch nach der Fertigstellung einen Folgeauftrag abzuarbeiten. Dafür bietet die Java-Bibliothek eine spezielle Unterklasse CompletableFuture. Die Klasse implementiert die Schnittstelle CompletionStage, die vermutlich die größte Anzahl Operationen in der gesamten Java SE hat. Der Typname drückt aus, das es um die Fertigstellung (engl. completion) von Abschnitten (engl. stage) geht.

Ein Beispiel für einen trinkfesten mutigen Piraten:

package com.tutego.insel.concurrent;




import java.time.LocalTime;

import java.util.concurrent.CompletableFuture;

import java.util.concurrent.TimeUnit;

import java.util.logging.Logger;




class Pirate {




  public static void main( String[] arg ) throws Throwable {




    String result = CompletableFuture.supplyAsync( Pirate::newName )

                                     .thenApply( Pirate::swears )

                                     .thenCombine( drinkRum(), Pirate::combinePiratAndDrinks )

                                     .thenCombine( drinkRum(), Pirate::combinePiratAndDrinks )

                                     .get();

    System.out.println( result ); // Pirat Guybrush flucht und trinkt dann 10 Flaschen Rum und trinkt dann 11 Flaschen Rum

  }




  static String newName() {

    Logger.getGlobal().info( "" + Thread.currentThread() );

    return "Pirat Guybrush";

  }




  static String swears( String pirate ) {

    Logger.getGlobal().info( "" + Thread.currentThread() );

    return pirate + " flucht";

  }




  static CompletableFuture<Integer> drinkRum() {

    Logger.getGlobal().info( "" + Thread.currentThread() );

    try { TimeUnit.SECONDS.sleep( 1 ); } catch ( Exception e ) { }

    return CompletableFuture.supplyAsync( () -> LocalTime.now().getSecond() );

  }




  static String combinePiratAndDrinks( String pirat, int bottlesOfRum ) {

    Logger.getGlobal().info( "" + Thread.currentThread() );

    return pirat + " und trinkt dann " + bottlesOfRum + " Flaschen Rum";

  }

}

Die Ausgabe ist:

Juni 15, 2017 10:41:56 NACHM. com.tutego.insel.thread.concurrent.Pirate drinkRum

INFORMATION: Thread[main,5,main]

Juni 15, 2017 10:41:56 NACHM. com.tutego.insel.thread.concurrent.Pirate newName

INFORMATION: Thread[ForkJoinPool.commonPool-worker-1,5,main]

Juni 15, 2017 10:41:56 NACHM. com.tutego.insel.thread.concurrent.Pirate swears

INFORMATION: Thread[ForkJoinPool.commonPool-worker-1,5,main]

Juni 15, 2017 10:41:57 NACHM. com.tutego.insel.thread.concurrent.Pirate combinePiratAndDrinks

INFORMATION: Thread[main,5,main]

Juni 15, 2017 10:41:57 NACHM. com.tutego.insel.thread.concurrent.Pirate drinkRum

INFORMATION: Thread[main,5,main]

Juni 15, 2017 10:41:58 NACHM. com.tutego.insel.thread.concurrent.Pirate combinePiratAndDrinks

INFORMATION: Thread[main,5,main]

Pirat Guybrush flucht und trinkt dann 57 Flaschen Rum und trinkt dann 58 Flaschen Rum

Zum Programm: Zunächst muss die Kette von Abschnitten aufgebaut werden. Das kann entweder mit dem Standardkonstruktor geschehen, oder mit statischen Methoden. In unserem Fall nutzen wir supplyAsync(Supplier<U> supplier). Die Methode nimmt sich einen freien Thread aus dem ForkJoinPool.commonPool() und lässt den Thread den supplier abarbeiten. Das Ergebnis ist über die Rückgabe, einem CompletableFuture, abrufbar. Als nächsten wenden wir thenApply(Function<? super T,? extends U> fn) an, die vergleichbar ist mit einer map(…)-Operation eines Streams. Interessant wird es bei thenCombine(CompletionStage<? extends U> other, BiFunction<? super T,? super U,? extends V> fn); sie verbindet das Ergebnis der eigenen CompletionStage über eine Funktion mit einer anderen CompletionStage, die wir in unserem Fall auch wieder mit supplyAsync(…) aufbauen. So kombinieren wir zwei unabhängige CompletionStage miteinander und synchronisieren das Ergebnis. Wir können das gut an der Ausgabe auslesen, dass drinkRum ganz am Anfang schon ausgeführt wird, und zwar vom Thread[main,5,main], nicht vom ForkJoinPool, weil es unabhängig von den anderen läuft.

HTTP Client API in Java 9

Der HTTP-Standard ist schon relativ alt und die Ursprünge wurden Anfang der 1990er Jahre gelegt. Offiziell wurde die Version 1.0 im Jahr 1996 verabschiedet, also etwa zu gleichen Zeit, als Java 1.0 erschien. 2015 wurde HTTP/2 verabschiedet, und viele Verbesserungen eingeführt. Die Java-Klassen rund um HTTP wurden allerdings nicht aktualisiert, sodass quelloffene Bibliothek die Lücken füllen.

Statt für Java 9 die existierenden HTTP-Klassen wie HttpURLConnection zu erweitern, hat Oracle ein ganz neues Paket eingeführt. Allerdings ist das noch nicht wirklich „freigeschaltet“, sondern ist im „Brutkasten“ (engl. incubator) und ein Modul jdk.incubator.httpclient muss bewusst hinzugenommen werden – in Java 10 soll es dann umbenannt werden, wobei sich die API noch ändern kann.

Die wesentlichen Typen sind:

  • HttpClient
  • HttpRequest, HttpResponse
  • WebSocket

Schauen wir uns ein Beispiel an:

try {

  URI uri = new URI( "https://tutego.de/" );

  HttpRequest httpRequest = HttpRequest.newBuilder().uri( uri ).GET().build();

  HttpResponse<String> response = HttpClient.newHttpClient().send(

                                    httpRequest, HttpResponse.BodyHandler.asString() );

  System.out.println( response.body() );

}

catch ( URISyntaxException | IOException | InterruptedException e ) {

  e.printStackTrace();

}

Um das Programm unter Java 9 laufen zu lassen ist unerlässlich –add-modules jdk.incubator.httpclient auf der Kommandozeile aufzunehmen.

Die Methoden von HttpRequest sind allesamt abstrakt:

  • Optional<HttpRequest.BodyProcessor> bodyProcessor()
  • Duration duration()
  • boolean expectContinue()
  • HttpHeaders headers()
  • String method()
  • Builder newBuilder()
  • Builder newBuilder(URI uri)
  • BodyProcessor noBody()
  • URI uri()
  • Version version()

Führt der HttpClient die Anfrage aus, bekommen wir ein HttpResponse; die Klasse hat folgende (abstrakte) Methoden:

  • T body()
  • int statusCode()
  • HttpRequest finalRequest()
  • HttpHeaders headers()
  • HttpRequest request()
  • SSLParameters sslParameters()
  • CompletableFuture<HttpHeaders> trailers()
  • URI uri()
  • Version version()

Was die Methode body() für einen Typ liefert bestimmt die Parametrisierung von HttpResponse<T>, und die ergibt sich aus dem übergebenen BodyHandler<T>  der HttpClient-Methode send(…):

  • HttpResponse<T> send(HttpRequest req, HttpResponse.BodyHandler<T> responseBodyHandler)

Der BodyHandler ist eine funktionale Schnittstelle mit ein paar statischen Methoden für vordefinierte Implementierungen:

  • BodyHandler<String> asString()
  • BodyHandler<String> asString(Charset charset)
  • BodyHandler<byte[]> asByteArray()
  • BodyHandler<Void> asByteArrayConsumer(Consumer<Optional<byte[]>> consumer)
  • BodyHandler<Path> asFile(Path file)
  • BodyHandler<Path> asFile(Path file, OpenOption… openOptions)
  • BodyHandler<Path> asFileDownload(Path directory, OpenOption… openOptions)
  • <U> HttpResponse.BodyHandler<U> discard(U value)

Insel-Update: Aufräumen mit finalize()

Wenn die automatische Speicherbereinigung feststellt, dass es keine Referenz mehr auf ein bestimmtes Objekt gibt, so ruft sie automatisch die besondere Methode finalize() auf diesem Objekt auf. Danach kann die automatische Speicherbereinigung das Objekt entfernen. Wir können diese Methode für eigene Aufräumarbeiten überschreiben, die Finalizer genannt wird (ein Finalizer hat nichts mit dem finally-Block einer Exception-Behandlung zu tun).

Seit Java 9 ist die Methode deprecated[1], um Entwickler zu ermutigen, auf diese Methode zu verzichten, obwohl sie natürlich weiterhin von der JVM aufgerufen wird. Es gibt mehrere Probleme. Einige Entwickler verstehen die Arbeitsweise der Methode nicht richtig und denken, sie wird immer aufgerufen. Doch hat die virtuelle Maschine Fantastillionen Megabyte an Speicher zur Verfügung und wird dann beendet, gibt sie den Heap-Speicher als Ganzes dem Betriebssystem zurück. In so einem Fall gibt es keinen Grund für eine automatische Speicherbereinigung als Grabträger und Folglich kein Aufruf von finalize(). Und wann genau der Garbage-Collector in Aktion tritt, ist auch nicht vorhersehbar, sodass im Gegensatz zu C++ in Java keine Aussage über den Zeitpunkt möglich ist, zu dem das Laufzeitsystem finalize() aufruft – alles ist vollständig nicht-deterministisch und von der Implementierung der automatischen Speicherbereinigung abhängig. Üblicherweise werden Objekte mit finalize() von einem Extra-Garbage-Collector behandelt, und der arbeitet langsamer als der normale GC, was somit ein Nachteil ist.

Sprachenvergleich

Einen Destruktor, der wie in C++ am Ende eines Gültigkeitsbereichs einer Variablen aufgerufen wird, gibt es in Java nicht.

 

class java.lang.Object

  • protected void finalize() throwsThrowable
    Die Methode wird von der automatischen Speicherbereinigung aufgerufen, wenn es auf dieses Objekt keinen Verweis mehr gibt. Die Methode ist geschützt, weil sie von uns nicht aufgerufen wird. Auch wenn wir die Methode überschreiben, sollten wir die Sichtbarkeit nicht erhöhen, also nicht public

Einmal Finalizer, vielleicht mehrmals die automatische Speicherbereinigung

Objekte von Klassen, die eine finalize()-Methode besitzen, kann Oracles JVM nicht so schnell erzeugen und entfernen wie Klassen ohne finalize(). Das liegt auch daran, dass die automatische Speicherbereinigung vielleicht mehrmals laufen muss, um das Objekt zu löschen. Es gilt zwar, dass der Garbage-Collector aus dem Grund finalize() aufruft, weil das Objekt nicht mehr benötigt wird, es kann aber sein, dass die finalize()-Methode die this-Referenz nach außen gibt, sodass das Objekt wegen einer bestehenden Referenz nicht gelöscht werden kann und so zurück von den Toten geholt wird. Das Objekt wird zwar irgendwann entfernt, aber der Finalizer läuft nur einmal und nicht immer pro GC-Versuch.[2]

Löst eine Anweisung in finalize() eine Ausnahme aus, so wird diese ignoriert. Das bedeutet aber, dass die Finalisierung des Objekts stehen bleibt. Die automatische Speicherbereinigung beeinflusst das in ihrer Arbeit aber nicht.

super.finalize()

Überschreiben wir in einer Unterklasse finalize(), dann müssen wir auch gewährleisten, dass die Methode finalize() der Oberklasse aufgerufen wird. So besitzt zum Beispiel die Klasse Font ein finalize(), das durch eine eigene Implementierung nicht verschwinden darf. Wir müssen daher in unserer Implementierung super.finalize() aufrufen (es wäre gut, wenn der Compiler das wie beim Konstruktoraufruf immer automatisch machen würde). Leere finalize()-Methoden ergeben im Allgemeinen keinen Sinn, es sei denn, das finalize() der Oberklasse soll explizit übergangen werden:

@Override protected void finalize() throws Throwable {
try {
// …
}
finally {
super.finalize();
}
}

Der Block vom finally wird immer ausgeführt, auch wenn es im oberen Teil eine Ausnahme gab.

Die Methode von Hand aufzurufen, ist ebenfalls keine gute Idee, denn das kann zu Problemen führen, wenn der GC-Thread die Methode auch gerade aufruft. Um das Aufrufen von außen einzuschränken, sollte die Sichtbarkeit von protected bleiben und nicht erhöht werden.

Hinweis

Da beim Programmende vielleicht nicht alle finalize()-Methoden abgearbeitet wurden, haben die Entwickler schon früh einen Methodenaufruf System.runFinalizersOnExit(true); vorgesehen. Mittlerweile ist die Methode veraltet und sollte auf keinen Fall mehr aufgerufen werden. Die API-Dokumentation erklärt:

„It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock.“

Dazu auch Joshua Bloch, Autor des ausgezeichneten Buchs „Effective Java Programming Language Guide“:

„Never call System.runFinalizersOnExit or Runtime.runFinalizersOnExit for any reason: they are among the most dangerous methods in the Java libraries.“

Gültige Alternativen

Gedacht war die überschriebene Methode finalize() um wichtige Ressourcen zur Not freizugeben, etwa File-Handles via close() oder Grafikkontexte des Betriebssystems, wenn der Entwickler das vergessen hat. Alle diese Freigaben müssten eigentlich vom Entwickler angestoßen werden, und finalize() ist nur ein Helfer, der rettend eingreifen kann. Doch da die automatische Speicherbereinigung finalize() nur dann aufruft, wenn sie tote Objekte freigeben möchte, dürfen wir uns nicht auf die Ausführung verlassen. Gehen zum Beispiel die File-Handles aus, wird der Garbage-Collector nicht aktiv; es erfolgen keine finalize()-Aufrufe, und nicht mehr erreichbare, aber noch nicht weggeräumte Objekte belegen weiter die knappen File-Handles. Es muss also ein Mechanismus her, der korrekt ist und und immer funktioniert. Hier gibt es zwei Ansätze:

  1. try-mit-Ressourcen ist ein eleganter Weg, damit auf Ressourcen die close()-Methode aufgerufen wird. Nachteil ist, dass die genutzte Ressource das selbst nicht weiß, ob der Nutzer sie mit close()
  2. Die unter Java 9 eingeführte Klasse lang.ref.Cleaner hilft beim Aufräumen, dazu später mehr in diesem Kapitel.

 

[1]      https://bugs.openjdk.java.net/browse/JDK-8165641

[2] Einige Hintergründe erfährt der Leser unter http://www.iecc.com/gclist/GC-lang.html#Finalization.

Versionskennungen aufbauen, parsen, vergleichen

In Java 9 wurde die Kennung für die Java-Version standardisiert. Wo früher von zum Beispiel 1.9.0_31-b08 die Rede war, heißt es heute 9.1.4+8; die 1. ist also verständig verschwunden. Auch eigene Programme können Versionskennungen nutzen und die Java SE stellt eine Klasse bereit, mit der sich zum Beispiel Versionen vergleichen lassen. Details zu den sogenannten semantischen Versionierung liefert http://semver.org/lang/de/.

Versionskennung

Ein Versionskennung hat die Form $MAJOR.$MINOR.$SECURITY. Das Schema besteht aus drei Teilen, die durch Punkte voneinander getrennt sind:

  1. Hautversion (engl. major version). Wird immer bei zentralen Änderungen und Updates um eine Stelle erhöht. Oft verbunden mit inkompatiblen API-Änderungen. Dann wird die Unterversion zurück auf 0 gesetzt.
  2. Unterversion (engl. minor verson). Wird erhöht bei kleineren Änderungen, wie Bug-Fixes. Das Release selbst bleibt rückwärtskompatibel.
  3. Sicherheitsrelease/Patch. Wird erhöht nach kritischen Sicherheitsupdates. Wichtig: Die Release-Nummer wird nicht auf 0 zurückgesetzt, wenn die Unterversion erhöht wird. Ein hoher Zähler der Sicherheitsreleases weist auf viele Änderungen hin, unabhängig von der Unterversion.

Die Versionen sind rein numerisch und der Gesamtstring matcht auf den regulären Ausdruck [1-9][0-9]*((\.0)*\.[1-9][0-9]*)*. Die Kennung endet nicht mit 0 – so wird $SECURITY weggelassen, wenn sie 0 ist und $MINOR wird nicht gesetzt, wenn $MINOR und $SECURITY beide 0 sind.

Versionsstring

Ein Versionsstring ist eine Versionskennung mit einem optionalen Zusatz von Informationen wie einer Vorversion (engl. pre release) oder Build-Informationen. Den Aufbau erklärt die API-Dokumentation an der Klasse Runtime.Version.

Version-API

Die Runtime-Klasse hat unter Java 9 eine innere Klasse Version bekommen, die so einen Versionsstring aufbauen und parsen kann. Die Version der aktuellen Laufzeitumgebung liefert die statische Methode version().

Beispiel

Gib alle Informationen über den Versionsstring aus:

System.out.println( Runtime.version() ); // 9-ea+159

System.out.println( Runtime.version().major() ); // 9

System.out.println( Runtime.version().minor() ); // 0

System.out.println( Runtime.version().security() ); // 0

System.out.println( Runtime.version().pre() ); // ea

System.out.println( Runtime.version().build() ); // 159

System.out.println( Runtime.version().optional() ); // Optional.empty

Eigene Version-Objekte lassen sich aus einem Versionsstring aufbauen mit der einzigen statischen Methode der Klasse Version, und zwar parse(String).

Beispiel

Version version = Version.parse( "9.2.4+45" );

System.out.println( version.version() );  // [9, 2, 4]

An dem Beispiel ist auch version() abzulesen, die eine numerische Liste mit Versionsnummern liefert.

Neben diesen Abfragemethoden kommen weitere Methoden hinzu. Zunächst überschreibt Version die Object-Methoden equals(…), hashCode() und toString(). Und da Version die Schnittstelle Comparable<Runtime.Version> implementiert, hat die Klasse eine Methode compareTo(Runtime.Version), was die Versionsnummern in eine Ordnung bringt. Zusätzlich gibt es compareToIgnoreOptional(Runtime.Version) und equalsIgnoreOptional(Object), was so etwas wie Build-Informationen ignoriert.

Java 9 wieder verschoben um 2 Monate

Auf den vermutlich 21. September 2017.  Aus der E-Mail http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html von Mark Reinhold:

As you probably know by now, the JCP Executive Committee (EC) recently voted [1] not to approve JSR 376, the Java Platform Module System [2], for the next stage of the process.

This vote does not mean that JSR 376 is dead, nor that Jigsaw has been rejected. It only means that the EC raised a number of concerns that it wanted the JSR 376 Expert Group (EG) to address. The JCP rules give the EG thirty days, until 7 June, to submit a revised specification for a second EC vote, which will end no later than 26 June [3].

The JSR 376 EG held a series of conference calls over the past two weeks in order discuss the EC’s concerns [4]. The net impact of those meetings on JDK 9 itself was to clarify the specification of the module system’s resolution algorithm, work on which had already begun, and to add one five-line method to the module-system API. These changes, together with additional clarifications to the JSR 376 and JSR 379 (Java SE 9) [5] Specifications, will hopefully address the EC’s concerns.

In order to be ready for all possible outcomes I suggest that here in the JDK 9 Project we continue to work toward the current goal of producing an initial Release Candidate build on 22 June [6], but adjust the GA date in order to accommodate the additional time required to move through the JCP process. To be specific, I propose that we move the GA date out by eight weeks, from 27 July to 21 September.

Comments on this proposal from JDK 9 Committers are welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC next Tuesday, 6 June, or if they’re raised and satisfactorily answered, then per the JEP 2.0 process proposal [7] this will be the new schedule for JDK 9.

Wird es bei Jigsaw (Module) in Java 9 bleiben?

RedHat hat mit  „The critical missing pieces and a path forward“ (http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-May/000874.html) ausgedrückt, Jigsaw so nicht unterstützen zu können.

Tim Ellison von IBM legt noch einmal nach in http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-May/000870.html und adressiert mit Links weitere Probleme.

Insgesamt sehe ich drei Ausgänge:

  1. Alles bleibt wie es ist und Oracle ignoriert die Probleme bzw. verschiebt Lösungen auf Java 10
  2. Das Release von Java 9 wird noch einmal nach hinten verschoben
  3. Jigsaw fliegt aus Java 9 raus

Was meint ihr?

JShell, die interaktive REPL-Shell in Java 9

Im JDK 9 ist ein neues Programm eingezogen: die JShell. Mit ihr lassen sich auf einfache Weise kleine Java-Programme und einzelne Anweisungen testen, sogenannte Snippets, ohne eine große IDE starten zu müssen. Die JShell ist eine Befehlszeile (Shell), die nach dem Read-Evaluate-Print-Loop-Prinzip arbeitet:

  • Read (Lesen): Eingabe des Programms von der Kommandozeile. Eine gute Shell bietet eine Historie der letzten Kommandos und Tastaturvervollständigung.
  • Eval (Ausführen): Compiliert das Snippet und führt es aus.
  • Print (Ausgaben): Die der Anweisungen und Programme werden in der Umgebung ausgegeben.
  • Loop (wiederholen): Es folgt ein Rücksprung auf den Zustand Lesen.

Das bekannteste Beispiel für eine REPL-Umgebung ist die Unix-Shell. Doch viele Skriptsprachen wie Lisp, Python, Ruby, Groovy und Clojure bieten solche REPL-Shells. Nun auch Java seit Version 9. Die Rückmeldung ist schnell, und gut zum Lernen und Ausprobieren von APIs.

Im bin-Verzeichnis vom JDK finden wir das Programm jshell. Rufen wir sie auf:

|  Welcome to JShell -- Version 9-ea

|  For an introduction type: /help intro




jshell>

Die JShell besitzt eingebaute Kommandos, die mit / beginnen, um zum Beispiel alle deklarierten Variablen ausgeben oder das Skript speichern. /help gibt eine Hilfe über alle Kommandos, /exit beendet JShell.

Nach dem Start wartet JShell auf die Snippets. Gültig sind:

  • Import-Deklarationen
  • Typ-Deklarationen
  • Methoden-Deklarationen
  • Anweisungen
  • Ausdrücke

Es sind also Teilmengen der Java-Sprache und keine eigene Sprache.

Anweisungen und einfache Navigation in der JShell

In der JShell lässt sich jeder Code schreiben, der im Rumpf einer Methode gültig ist. Ein Semikolon am Ende einer Anweisung ist nicht nötig:

jshell> System.out.println( "Hallo Welt" )

"Hallo Welt"

Compilerfehler zeigt die JShell sofort an:

jshell> System.out.pri()

|  Error:

|  cannot find symbol

|    symbol:   method pri()

|  System.out.pri()

|  ^------------^

Ausnahmen müssen nicht behandelt werden, es lassen sich alle Methoden ohne try-catch aufrufen; falls es zu Ausnahmen kommt werden diese direkt gemeldet:

jshell> Files.exists( Paths.get("c:/") )

$2 ==> true




jshell> Files.exists( Paths.get("lala:/") )

|  java.nio.file.InvalidPathException thrown: Illegal char <:> at index 4: lala:/

|        at WindowsPathParser.normalize (WindowsPathParser.java:182)

…

|        at (#3:1)

Die letzte Zeile zeigt die Zeilennummer im Skript an. Eine Liste der bisher eingegebenen Zeilen listet /list auf, und das inklusive Zeilennummern. Diese sind nützlich, wenn es zu Ausnahmen wie oben kommt.

jshell> /list




   1 : System.out.println( "Hallo Welt" );

   2 : Files.exists(Paths.get("c:/"))

   3 : Files.exists(Paths.get("lala:/"))

Die JShell pflegt eine Historie der letzten Kommandos, die sich mit den Cursor-Tasten abrufen lässt. Es funktioniert auch die Vervollständigung mit der Tabulator-Taste wie in einer IDE, wobei die Groß-Kleinschreibung relevant ist:

jshell> Sys

System        SystemColor   SystemTray




jshell> System.out.println(java.time.LocalDateTime.n

jshell> System.out.println(java.time.LocalDateTime.now(

now(




jshell> System.out.println(java.time.LocalDateTime.now())

2017-03-23T11:50:43.859385900

Mit dem Cursor lässt sich in die Zeile vorher gehen und die Zeile nacheditieren.

Variablendeklarationen

Variablen lassen sich deklarieren und später jederzeit verwenden:

jshell> String name = "Christian"

name ==> "Christian"

Die JShell gibt die Variable mit der Belegung zur Kontrolle aus.

Variablen lassen sich mit einem ganz neuen Typ redefinieren:

jshell> StringBuilder name = new StringBuilder( "Christian" )

name ==> Christian

Es lassen sich auch ohne Zuweisung Ausdrücke in die JShell setzen. Das Ergebnis des Ausdrucks wird einer temporären Variablen zugewiesen, die standardmäßig mit einem Dollar beginnt und der einer Zahl folgt, etwa $1. Auf diese Variable lässt sich später zugreifen:

jshell> BigInteger.TEN.pow(10)

$1 ==> 10000000000




jshell> $1

$1 ==> 10000000000




jshell> $1.bitLength()

$2 ==> 34




jshell> System.out.println(2*$2)

68

Welche Variablen in welcher Reihenfolge in der Sitzung deklariert wurden zeigt das Kommando /vars auf:

jshell> /vars

|    StringBuilder name = Christian

|    BigInteger $1 = 10000000000

|    int $2 = 34

Unvollständige Eingabe

Wenn die JShell auf einen nicht kompletten Code trifft, symbolisiert die Ausgabe …> die Notwendigkeit einer weitere Eingabe:

jshell> System.out.println(

   ...> "Hallo"

   ...> +

   ...> " Welt"

   ...> )

Hallo Welt

Import-Deklarationen

Standardmäßig sind für den Java-Compiler alle Typen vom Paket java.lang direkt importiert. Die JShell erweitert das um eine ganze Reihe weiterer Typen. Wir können sie mit dem Kommando /imports erfragen:

jshell> /imports

|    import java.io.*

|    import java.math.*

|    import java.net.*

|    import java.nio.file.*

|    import java.util.*

|    import java.util.concurrent.*

|    import java.util.function.*

|    import java.util.prefs.*

|    import java.util.regex.*

|    import java.util.stream.*




jshell> import java.awt.*




jshell> /imports

|    import java.io.*

|    import java.math.*

|    import java.net.*

|    import java.nio.file.*

|    import java.util.*

|    import java.util.concurrent.*

|    import java.util.function.*

|    import java.util.prefs.*

|    import java.util.regex.*

|    import java.util.stream.*

|    import java.awt.*

Methoden- und Typ-Deklarationen

Methoden und Klassen lassen sich deklarieren und auch wieder überschreiben, wenn eine neue Version eine alte ersetzen soll. JShell schreibt dann „modified“ bzw. „replaced“.

jshell> String greet(String name) { return "BÖLK " + name; }

|  created method greet(String)




jshell> String greet(String name) { return "Mit vorzüglicher Hochachtung " + name; }

|  modified method greet(String)




jshell> class MyFrame extends java.awt.Frame {}

|  created class MyFrame




jshell> class MyFrame extends java.awt.Frame { MyFrame() { setTitle("FENSTER"); } }

|  replaced class MyFrame




jshell> new MyFrame().show()

Welche Methoden und neue Typen in der Sitzung deklariert sind listet /methods und /types auf:

jshell> /methods

|    String greet(String)




jshell> /types

|    class OkButton

|    class MyFrame

Exceptions müssen wie üblich behandelt werden, eine Sonderbehandlung, wie bei der direkten, in die JShell eingegeben Anweisungen, gibt es nicht.

Forward-Reference

Greift eine Methoden- oder Klassendeklaration auf Typen und Methoden zurück, die in dem Kontext noch nicht vorhanden sind, ist das in Ordnung; allerdings müssen alle Typen und Methoden spätestens dann bekannt sein, wenn der Code ausgeführt werden soll.

jshell> double cubic(double v) { return sqr(v) * v; }

|  created method cubic(double), however, it cannot be invoked until method sqr(double) is declared




jshell> cubic(100)

|  attempted to call method cubic(double) which cannot be invoked until method sqr(double) is declared




jshell> double sqr(double v) { return v*v; }

|  created method sqr(double)




jshell> cubic(100)

$14 ==> 1000000.0

Laden, speichern und ausführen von Skripten

Snippets können in der JShell mit /save Dateiname gespeichert, mit /open Dateiname geöffnet und mit /edit in einem Standard-Editor bearbeitet werden.

Auf der Kommandozeile werden JShell-Skripte auf vorhandenen Skripten einfach ausgeführt mit:

$ jshell datei

JShell API

Anders als die Benutzung von JavaScript aus Java heraus integriert sich die JShell nicht als Skript-Sprache. Stattdessen gibt es eine eigene API, in der die Klasse JShell im Mittelpunkt steht, wobei sich die Möglichkeiten der JShell-Kommandozeile eins zu eins in der API – dokumentiert unter http://download.java.net/java/jdk9/docs/jdk/api/jshell/overview-summary.html – wiederfinden lassen.

Ein einfaches Beispiel:

try ( JShell shell = JShell.create() ) {

  // Semikolon wichtig!

  String program = "java.math.BigInteger.TEN.pow( 10 );";

  List<SnippetEvent> events = shell.eval( program );

  for ( SnippetEvent snippetEvent : events ) {

    System.out.println( snippetEvent.status() );

    System.out.println( snippetEvent.value() );

    System.out.println( snippetEvent.snippet().source() );

    System.out.println( snippetEvent.snippet().kind() );

    if ( snippetEvent.snippet() instanceof VarSnippet ) {

      VarSnippet varSnippet = (VarSnippet) snippetEvent.snippet();

      System.out.println( varSnippet.typeName() );

    }

  }

}

Die Ausgabe ist:

VALID

10000000000

java.math.BigInteger.TEN.pow( 10 );

VAR

java.math.BigInteger

Ein paar Dinge sind an der API bemerkenswert, und zwar die Typen und Ergebnisse: sie sind Strings. varSnippet.typeName() ist ein String und snippetEvent.value() ebenso. Es ist nicht möglich, eine echte Objektrepräsentation zu bekommen, was die Nutzung als eingebettete Skriptsprache einschränkt.

Zum Weiterlesen

Weitere Informationen lassen sich aus dem JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)[1] entnehmen und von den Quellen, die bei Java 9 dabei sind. Fragen über das Produkt lassen sich in der Mailingliste http://mail.openjdk.java.net/mailman/listinfo/kulla-dev stellen.

[1]            http://openjdk.java.net/jeps/222

Java DB nicht mehr in Java 9

Gerade habe ich angefangen mein JDBC-Kapitel zu aktualisieren, weg von HSQLDB hin zur mitgelieferten  Java DB. Ich habe die Java DB-Datenbank gestartet, den Text und Beispiele umgeschrieben, usw. Irgendwie habe ich das db-Verzeichnis von Java 8 genutzt, ohne das mir das aufgefallen wäre. Das Kapitel ist fertig gewesen, da wollte ich schauen, ob Java 9 die aktuelle Version von Apache DB nutzt und was ist? Arrrg. In Java 9 ist die Java DB rausgeflogen. Verdammt. Alle Änderungen wieder rückgängig machen, es bleibt vorerst bei HSQLDB.

StackWalker and Stack-Walking API

Der Stack-Trace, den Java über die StackTraceElement bietet, ist relativ arm an Informationen, und die Standardausgabe über die Throwable-Methode printStackTrace(…) ist unübersichtlich. Aus Performance-Gründen können sogar Einträge fehlen, so dokumentiert es die Javadoc an der Methode:

Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this thread is permitted to return a zero-length array from this method.

Zudem fehlen spannende Informationen wie Zeitpunkte, und ein Thread.getAllStackTraces() ist bei vielen Threads und tiefen Aufrufhierarchien sehr langsam. Summa summarum: Ein guter Debugger oder ein Analysetool mit Zugriff auf die JVM-Eigenschaften ist für die ernsthafte Entwicklung unumgänglich.

In Java 9 hat Oracle die “JEP 259: Stack-Walking API” umgesetzt. Ein java.lang.StackWalker wandert die Aufrufhierarchie ab und repräsentiert die Aufrufhierarchie als StackFrame-Objekte von dort, wo der Stack generiert wurde, nach unten zur Aufrufstelle. Es gibt mehrere überladenen statische getInstance(…)-Methoden, die einen StackWalker generieren. Wir können dann mit

  • void forEach(Consumer<? super StackFrame> action) oder
  • <T> T walk(Function<? super Stream<StackFrame>, ? extends T> function)

über die StackFrames laufen.

Beispiel:

public static void showTrace() {

  List<StackFrame> frames =

    StackWalker.getInstance( Option.RETAIN_CLASS_REFERENCE )

               .walk( stream  -> stream.collect( Collectors.toList() ) );

  for ( StackFrame stackFrame : frames )

    System.out.println( stackFrame );

}

Da alle Informationen zu liefern die Geschwindigkeit senkt, und vielleicht unnötig viel Arbeit verursacht, deklariert die Aufzählung StackWalker.Option die Konstanten RETAIN_CLASS_REFERENCE, SHOW_HIDDEN_FRAMES, SHOW_REFLECT_FRAMES für unterschiedliche Vollständigkeit der Informationen.  Die Aufzählungen sind ein Argument für getInstance(…). Um die Class-Objekte über getDeclaringClass() abrufen zu können, muss getInstance(…) mit der Option.RETAIN_CLASS_REFERENCE gesetzt sein.

Beispiel: Die forEach(…)-Methode eines Streams konsumiert einen Consumer auf jedem Element. Finde heraus, ob unsere Consumer-Methode accept(…) indirekt von einer Klasse aus dem Paket  java.util.concurrent aufgerufen wurde:

Consumer<String> walkStack = String -> {

  StackWalker.getInstance( Option.RETAIN_CLASS_REFERENCE )

        .walk( stream -> stream.map( StackFrame::getDeclaringClass )

                               .map( Class::getPackageName )

                               .filter( s -> s.startsWith( "java.util.concurrent" ) )

                               .findFirst() )

                               .ifPresentOrElse( e -> System.out.println( "Durch j.u.c gelaufen" ),

                                                 () -> System.out.println( "Nicht durch j.u.c gelaufen" ) );

};

Stream.of( "Hallo" ).forEach( walkStack );            // Nicht durch j.u.c gelaufen

Stream.of( "Hallo" ).parallel().forEach( walkStack ); // Durch j.u.c gelaufen

 

ProcessHandle und Prozess-IDs

Ein ProcessHandle ist ein neuer Typ in Java 9, der native Prozesse identifiziert. Wir bekommen Exemplare entweder über

  • die Process-Objektmethode toHandle(),
  • die statische Methodecurrent(),
  • allProcesses(), die alle Prozesse über einen Stream<ProcessHandle> liefert,
  • die statische ProcessHandle-Methode of(long pid), die uns das ProcessHandle in ein Optional verpackt,
  • mit einem vorhandenen ProcessHandle können wir weiterhin mit children() und descendants() einen Stream<ProcessHandle> erfragen und mit parent() auf die Eltern zugreifen.

Jeder Prozess verfügt über eine identifizierende long-Ganzahl, die getPid() auf dem ProcessHandle liefert. Weitere Details zu den Startparametern offenbare ProcessHandle.Info-Ojekte.

Beispiel: Gib alle vorhanden Informationen über alle Prozesse aus:

Consumer<ProcessHandle> log = handle ->

  System.out.printf( "PID=%s, Root?=%s, Info=%s%n",

                     handle.getPid(), !handle.parent().isPresent(), handle.info() );

ProcessHandle.allProcesses().forEach( log );

Die Ausgabe kann so aussehen:

PID=0, Root?=true, Info=[]

PID=4, Root?=true, Info=[]

...

PID=4368, Root?=true, Info=[]

PID=4568, Root?=true, Info=[user: Optional[Yoga\Christian], cmd: C:\Windows\System32\sihost.exe, startTime: Optional[2017-02-04T20:54:07.601Z], totalTime: Optional[PT3M39.703125S]]

PID=4592, Root?=true, Info=[user: Optional[Yoga\Christian], cmd: C:\Windows\System32\svchost.exe, startTime: Optional[2017-02-04T20:54:07.621Z], totalTime: Optional[PT14.9375S]]

PID=4628, Root?=true, Info=[]

...

ProcessHandle implementiert vernünftig equals(…) und auch Comparable<ProcessHandle>; die Sortierung ist nach der Prozess-ID.

Methoden-Delegation

Einige Methoden aus Process delegieren an den assoziierten ProcessHandle. Die Methoden heißen gleich.

Process-Methoden Implementierung
long getPid() return toHandle().getPid();
ProcessHandle.Info info() return toHandle().info();
Stream<ProcessHandle> children() return toHandle().children();
Stream<ProcessHandle> descendants() return toHandle().descendants();

Weiterhin gibt es onExit(), supportsNormalTermination(), isAlive(), destroy() und destroyForcibly() auf beiden Typen Process und ProcessHandle.

 

Über Objekte vom Typ ProcessHandle.Info lassen sich weitere Details zum Prozess erfragen; die Rückgaben sind Optional, weil die Informationen vielleicht nicht vorliegen.

  • static interface java.lang.Info
  • Optional<String[]> arguments()
    Programmargumente beim Start.
  • Optional<String> command()
    Ausführbarer Pfadname vom Prozess.
  • Optional<String> commandLine()
    Konkatenation von command() und arguments() beste Repräsentation des Programmaufrufs.
  • Optional<Instant> startInstant()
    Startzeit des Prozesses.
  • Optional<Duration> totalCpuDuration()
    Bisher verbrauchte CPU-Zeit.
  • Optional<String> user()
    Benutzer dieses Prozesses.

 

Prozess-Status erfragen und das Ende einleiten

Mit Methoden von Process lässt sich der Status des externen Programms erfragen und verändern. Die Methode waitFor(…) lässt den eigenen Thread so lange warten, bis das externe Programm zu Ende ist, oder löst eine InterruptedException aus, wenn das gestartete Programm unterbrochen wurde. Der Rückgabewert von waitFor() ist der Rückgabecode des externen Programms, eine zweite Variante von waitFor(…) wartet eine gegebene Zeit. Wurde das Programm schon beendet, liefert auch exitValue() den Rückgabewert. Soll das externe Programm (vorzeitig) beendet werden, lässt sich die Methode destroyXXX() verwenden; das eigene Java-Programm kann nicht beendet werden.

abstract class java.lang.Process

  • abstractintexitValue()
    Wenn das externe Programm beendet wurde, liefert exitValue() die Rückgabe des gestarteten Programms. Ist die Rückgabe 0, deutet das auf ein normales Ende hin. Läuft das Programm noch, gibt es eine IllegalThreadStateException.
  • booleanisAlive()
    Lebt der von der JVM gestartete Unterprozess noch? Ruft intern exitValue() auf und prüft auf IllegalThreadStateException.
  • abstractvoiddestroy()
    Beendet das externe Programm.
  • ProcessdestroyForcibly()
    Standardmäßig wie destroy(), sollte aber von Unterklassen anders implementiert werden. Das brutale Beenden dauert etwas, sodass isAlive() noch eine kurze Zeit true zurückgeben kann.
  • boolean supportsNormalTermination()
    Liefert true, wenn das Programm mit destroy() ohne Probleme beendet werden kann. Unterklassen müssen die Methode überschreiben, sie löst standardmäßig eine UnsupportedOperationException Neue Methode in Java 9.
  • abstractvoidwaitFor()throwsInterruptedException
    Wartet auf das Ende des externen Programms (ist es schon beendet, muss nicht gewartet werden), sonst blockiert die Methode, und liefert dann abschließend den exitValue().
  • booleanwaitFor(longtimeout,TimeUnitunit)throwsInterruptedException
    Wartet die angegebene Zeit auf das Ende des gestarteten Programms. Wurde das externe Programm schon beendet, kehrt die Methode sofort zurück und liefert true; den Exit-Code liefert exitValue() weil hier, anders als bei waitFor() der Rückgabecode ein boolean Läuft das Programm noch, und ist es nicht nach timeout Zeiteinheiten beendet, kehrt die Methode mit false zurück. Die Rückgabe ist true, wenn das gestartete Programm in dem Zeitfenster beendet wurde. Hinweis: Die Methode bricht das externe Programm nicht ab, wenn es nach Überschreiten der Zeit noch läuft. Diese Logik muss ein Programmierer übernehmen und if ( ! waitFor(…) ) mit destroy() kombinieren.
  • CompletableFuture<Process> onExit()
    Kehrt nicht-blockierend direkt zurück und erlaubt später über das CompletableFuture Zugriff auf den Process. CompletableFuture ermöglicht die einfache Verkettung der Art onExit().thenApply( … ) oder process.onExit().whenComplete( (p, ex) -> System.out.printf(„Prozess %d beendet%n“, p.getPid())). Neu in Java 9.

Stream vom Scanner-Tokens generieren

Die in Java 9 eingeführte Objektmethode stream() ist eine sehr gute Ergänzung, denn sie liefert einen Stream<String> von zerlegten Strings.

Beispiel: Durch Komma getrennte String sollen durch ein Zeilenumbruch wieder zusammengefügt werden:

String s = "CNN, Politico, LA Times, New York Times";

System.out.println( new Scanner(s).useDelimiter( "\\s*,\\s*" ).tokens()

                                  .collect( Collectors.joining("\n") ) );

null-Prüfungen mit eingebauter Ausnahmebehandlung

Traditionell gilt es, null als Argument und in den Rückgaben zu vermeiden. Es ist daher gut, als Erstes in einem Methodenrumpf zu testen, ob die Argumente ungleich null sind – es sei denn, das ist unbedingt gewünscht.

Für diese Tests, dass Referenzen ungleich null sind, bietet Objects ein paar requireNonNullXXX(…)-Methoden, die null-Prüfungen übernehmen und im Fehlerfall eine NullPointerException auslösen. Diese Tests sind praktisch bei Konstruktoren oder Settern, die Werte initialisieren sollen, aber verhindern möchten, dass null durchgeleitet wird.

Beispiel: Die Methode setName(…) soll kein name-Argument gleich null erlauben:

public void setName( String name ) {
  this.name = Objects.requireNonNull( name );
 }

Alternativ ist eine Fehlermeldung möglich:

public void setName( String name ) {
  this.name = Objects.requireNonNull( name, "Name darf nicht null sein!" );
 }

class java.util.Objects

  • static<T>TrequireNonNull(Tobj)
    Löst eine NullPointerException aus, wenn obj gleich null Sonst liefert sie obj als Rückgabe. Die Deklaration ist generisch und so zu verstehen, dass der Parametertyp gleich dem Rückgabetyp ist.
  • static<T>TrequireNonNull(Tobj,Stringmessage)
    Wie requireNonNull(obj), nur dass die Meldung der NullPointerException bestimmt wird.
  • static<T>TrequireNonNull(Tobj,Supplier<String>messageSupplier)
    Wie requireNonNull(obj, message), nur kommt die Meldung aus dem messageSupplier. Das ist praktisch für Nachrichten, deren Aufbau teurer ist, denn der Supplier schiebt die Kosten für die Erstellung des Strings so lange hinaus, bis es wirklich zu einer NullPointerException kommt, denn erst dann ist die Meldung nötig.
  • static <T> T requireNonNullElse(T obj, T defaultObj)
    Liefert das erste Objekte, was nicht null defaultObj nicht null sein darf, sonst folgt eine NullPointerException. Implementiert als return (obj != null) ? obj : requireNonNull(defaultObj, „defaultObj“); Neu in Java 9.
  • static <T> T requireNonNullElseGet(T obj, Supplier<? extends T> supplier)
    Liefert das erste Objekt, was nicht null Ist obj gleich null, holt sich die Mehode die Referenz aus dem Supplier, der dann kein null liefern darf, sonst folgt eine NullPointerException. Neu in Java 9.

Statische ofXXX(…)-Methoden zum Aufbau unveränderbarer Set-, List-, Map-Datenstrukturen

In Java 9 sind echte immutable Datenstrukturen dazugekommen, die sich über statische ofXXX(…)-Methoden der Schnittstellen List, Set und Map aufbauen lassen. Jede versuchte Änderung an den Datenstrukturen führt zu einer UnsupportedOperationException. Damit eigenen sie sich hervorragend für konstante Sammlungen, die problemlos herumgereicht können.

Aus Performance-Gründen sind die of(…)-Methoden überladen, das ändert aber nichts an ihrem Aufrufvarianten. null-Elemente sind grundsätzlich verboten und führen zu einer NullPointerException.

interface java.util.List<E>
extends Collection<E>

  • static <E> List<E> of(E… elements)
    Erzeugt eine neue immutable Liste aus den Elementen. Vor dem praktischen of(…) wurden Listen in der Regel mit Array.asList(…) aufgebaut. Doch die sind nicht immutable und schreiben auf das Feld durch.

interface java.util.Set<E>
extends Collection<E>

  • static <E> Set<E> of(E… elements)
    Erzeugt eine Menge aus den gegebenen Elementen. Doppelte Einträge sind verboten und führen zu einer IllegalArgumentException. Der Versuch, schon vorhandene Elemente in eine „normale“ HashSet oder TreeSet hinzuzufügen, ist aber völlig legitim. Wie die Implementierung der Menge genau ist, ist verborgen.

Beispiel

Zeige an, welche Superhelden in einem String Liste vorkommen:

Set<String> heros = Set.of( „Batman“, „Spider-Man“, „Hellboy“ );

new Scanner( „Batman trifft auf Superman“ )

.tokens().filter( heros::contains )

.forEach( System.out::println );    // Batman

 

Zum Aufbau von Assoziationsspeichern gibt es zwei Varianten. Einmal über die of(…)-Methode, die Schlüssel und Wert einfach hintereinander aufnimmt und einmal mit ofEntries(…) über ein Vararg von Entry-Objekten. Eine neue statische Methode hilft, diese einfach aufzubauen:

interface java.util.Map<K,V>

  • static <K, V> Map<K, V> of() {
  • static <K, V> Map<K, V> of(K k1, V v1)
  • static <K, V> Map<K, V> of(K k1, V v1 … )
  • static <K, V> Map<K, V> of(K k1, V v1, K k2, V v2, K k3, V v3, K k4, V v4, K k5, V v5, K k6, V v6, K k7, V v7, K k8, V v8, K k9, V v9, K k10, V v10)
  • static <K, V> Map<K, V> ofEntries(Entry<? extends K, ? extends V>… entries)
  • static <K, V> Entry<K, V> entry(K k, V v)

Beispiel

Baue eine Map mit Java-Versionen und deren Erscheinungsdaten auf und gib sie aus:

Map<String, LocalDate> map =

Map.ofEntries( Map.entry( „JDK 1.0“, LocalDate.of( 1996, Month.JANUARY, 23 ) ),

Map.entry( „JDK 1.1“, LocalDate.of( 1997, Month.FEBRUARY, 19 ) ) );

map.forEach( (k, v) -> System.out.println( k + „=“ + v ) );

Best-Practise und Weise Worte

Die neuen ofXXX(…)-Methoden sind eine Bereicherung, aber auch mit Vorsicht einzusetzen – die alten API-Methoden werden dadurch nicht langweilig:

  • Da die of(…)-Methoden überladen sind lässt sich prinzipiell auch emptyXXX() durch of() und Collections.singleon() durch of(element) ersetzen – allerdings sagen die Collections-Methodennamen gut aus, was hier passiert und sind vielleicht expliziter.
  • Auf einem existierenen Array hat Arrays.asList(…) zwar den Nachteil, dass die Array-Elemente ausgetauscht werden können, allerdings ist der Speicherbedarf minimal, da der Adapter asList(…) keine Kopie anlegt, wohingegen List.of(…) zum Aufbau einer neuen internen Datenstruktur führt, die Speicher kostet.
  • Falls null-Einträge in der Sammlung sein sollen, dürfen keine ofXXX(…)-Methoden verwendet werden.
  • Beim Refactoring könnten Entwickler geneigt sein, existierenden Code mit den Collections-Methode durch die ofXXX(…)-Methoden zu ersetzen. Das kann zum Problem mit serialisierten Daten werden, denn das Serialisierungsformat ist ein anders.
  • Bei Set und Map wird ein künstlicher SALT eingesetzt, der die Reihenfolge der Elemente bei jedem JVM-Start immer ändert. Das heißt, der Iterator von of(„a“, „b“, „c“) kann einmal „a“, „b“, „c“ liefern, dann beim nächsten Programmstart „b“, „c“, „a“.