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

Inselraus: JDBC Treibertypen

Oracle definiert vier Treiberkategorien, die wir im Folgenden beschreiben. Sie unterscheiden sich im Wesentlichen darin, ob sie über einen nativen Anteil verfügen oder nicht.

Typ 1: JDBC-ODBC-Brücke (JDBC-ODBC Bridge driver)

ODBC (Open Database Connectivity Standard) ist ein Standard von Microsoft, der den Zugriff auf Datenbanken über eine genormte Schnittstelle möglich macht. ODBC ist insbesondere in der Windows-Welt weit verbreitet, und für jede ernst zu nehmende Datenbank gibt es einen Treiber.

Da es am Anfang der JDBC-Entwicklung keine Treiber gab, haben sich JavaSoft und Intersolv (seit 2000 Merant) etwas ausgedacht: eine JDBC-ODBC-Brücke, die die Aufrufe von JDBC in ODBC-Aufrufe der Client-Seite umwandelt. Da die Performance oft nicht optimal und die Brücke nicht auf jeder Plattform verfügbar ist, stellt diese JDBC-Anbindung häufig eine Notlösung dar. Und weil ODBC eine systembezogene Lösung ist, hat der Typ-1-Treiber native Methoden, was die Portierung und seinen Einsatz – etwa über das Netz – erschwert. Die JDBC-ODBC-Brücke implementiert seit Version 1.4 den JDBC 2-Standard. In Java 8 wurde die Brücke entfernt, ist also kein Teil mehr vom JDK. Es gibt existierende Lösungen auf dem Markt, allerdings gibt es keine wirkliche Notwendigkeit mehr dafür, da es für jede bedeutende Datenbank einen direkten JDBC-Treiber gibt.

Typ 2: Native plattformeigene JDBC-Treiber (Native-API Java driver)

Diese Treiber übersetzen die JDBC-Aufrufe direkt in Aufrufe der Datenbank-API. Dazu enthält der Treiber Programmcode, der native Methoden aufruft.

Treiber vom Typ 1 oder 2 sind nicht portabel auf jeder Plattform, da sie zum einen für die JDBC-ODBC-Brücke auf die Plattform-Bibliothek für ODBC zurückgreifen müssen und zum anderen auf plattformspezifische Zugriffsmöglichkeiten für die Datenbank angewiesen sind. Den Treiber auf einen anderen Computer zu übertragen funktioniert in der Regel nicht, da sie eng mit der Datenbank verbunden sind. Läuft auf einem Server etwa eine alte dBASE-Datenbank und ein nativer Typ-2-Treiber greift direkt auf die lokale Datenbank zu, dann kann dieser JDBC-Treiber nicht einfach auf einen Tablet-PC mit ARM-Prozessor kopiert werden – zum einen würde er dort wegen der anderen Hardware-Architektur nicht laufen, und zum anderen würde der Treiber dann wohl kaum über das Netzwerk auf die Datenbank zugreifen können.

Typ 3: Universeller JDBC-Treiber (Native-protocol all Java driver)

Der universelle JDBC-Treiber ist ein in Java programmierter Treiber, der beim Datenbankzugriff auf den Client geladen wird. Der Treiber kommuniziert mit der Datenbank nicht direkt, sondern über eine Softwareschicht, die zwischen der Anwendung und der Datenbank sitzt: der Middleware. Damit erfüllen Typ-3-Treiber eine Vermittlerrolle, denn erst die Middleware leitet die Anweisungen an die Datenbank weiter. Für Applets und Internetdienste hat ein Typ-3-Treiber den großen Vorteil, dass seine Klassendateien oft kleiner als Typ-4-Treiber sind, da ein komprimiertes Protokoll eingesetzt werden kann. Über das spezielle Protokoll zur Middleware ist auch eine Verschlüsselung der Verbindung möglich. Kaum eine Datenbank unterstützt verschlüsselte Datenbankverbindungen. Da zudem das Middleware-Protokoll unabhängig von der Datenbank ist, müssen auf der Client-Seite für einen Datenbankzugriff auf mehrere Datenbanken auch nicht mehr alle Treiber installiert werden, sondern im günstigsten Fall nur noch ein Typ-3-Treiber von einem Anbieter. Die Ladezeiten sind damit deutlich geringer.

Typ 4: Direkte Netzwerktreiber (Net-protocol all Java driver)

Diese Treiber sind vollständig in Java programmiert und kommunizieren direkt mit dem Datenbankserver. Sie sprechen mithilfe des datenbankspezifischen Protokolls direkt mit der Datenbank über einen offenen IP-Port. Dies ist in einer Direktverbindung die performanteste Lösung. Sie ist jedoch nicht immer realisierbar, etwa bei Datenbanken wie MS Access, dBase oder Paradox, die kein Netzwerkprotokoll definieren.

Schneller aufrufen mit MethodType und MethodHandle

Um dynamische Programmiersprachen wie JavaScript performant auf die JVM zu bringen wurde in Java 7 der neue Bytecode invokedynamic eingeführt und das Paket lang.invoke. Java8 greift zur Umsetzung der Lambda-Ausdrücke massiv auf invokedynamic zurück.

Aufgabe des Pakets ist es, dynamisch Methoden schnell aufzurufen, und zwar deutlich schneller als Reflection das kann, weil in der JVM der Methodenaufruf so optimiert wird wie ein ganz normaler Methodenaufruf auf ein Zielobjekt. Dazu müssen aber die Typen exakt vorliegen, sodass es schärfere Anforderungen gibt als bei Reflection, dort ist z. B. der Rückgabetyp beim Aufruf irrelevant.

Um einen dynamischen Methodenaufruf zu starten ist zunächst eine exakte Beschreibung der Rückgabe- und Parametertypen nötig – das übernimmt ein MethodType-Objekt. Ist das aufgebaut, wird ein MethodHandle erfragt, ein getypter, direkt ausführbarer Verweis auf die repräsentierte Methode. Die MethodHandle-Methode invoke(…) führt dann den Aufruf mit gegebenen Argumente auf.

Dazu ein Beispiel. Wir möchten auf einem Rectangle-Objekt die Methode union(Rectangle) aufrufen, um als Ergebnis ein neues Rectangle zu bekommen, was die beiden Rechtecke vereinigt.

Object rect1 = new Rectangle( 10, 10, 10, 10 );

String methodName = "union"; 

Class<?> resultType = Rectangle.class;

Object rect2 = new Rectangle( 20, 20, 100, 100 );

Class<? > parameterType = rect2.getClass();

rect1 ist das eigentliche Objekt auf dem die methodName aufgerufen werden soll. resultType ist der Ergebnistyp den wir von der Methode erwarten, als Class-Objekt. rect2 ist das Argument für union(…). Der parameterType für die union(…)-Methode ergibt sich aus dem Class-Objekt vom rect2.

MethodType mt = MethodType.methodType( resultType, parameterType );

MethodHandle methodHandle = MethodHandles.lookup().findVirtual(

                              rect1.getClass(), methodName, mt );

System.out.println( methodHandle.invoke( rect1, rect2 ) );

Als erstes erfragen wir MethodType und geben Ergebnis- und Parametertyp an; noch nicht den Methodennamen, hier geht es nur um die Typen. Der MethodHandle verheiratet den Methodennamen und die Typangaben mit einer Klasse, die so eine Methode anbietet. invoke(…) führt letztendlich den Aufruf aus; das erste Argument ist das „this“-Objekt, also das Objekt auf dem die Methode aufgerufen werden soll, als nächstes folgenden die Argumente von union(…), also das zweite Rechteck. Als Ergebnis bekommen wir das Rectangle-Objekt, was genau der Vereinigung entspricht.

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.

Insel Java 9 Update; Statusbericht 1

Wie man an den Beiträgen hier im Blog erkennen kann, sind viele Absätze aktualisiert worden mit den Methoden aus Java 9. Der Kleinkram ist komplett beschrieben, was jetzt noch fehlt:

  • Modulsystem natürlich, größter neu zu schreibender Text
  • Reactive Programming mit  java.util.concurrent.Flow.*, allerdings überlege ich noch, wie tief ich das beschreiben möchte

Im Allgemeinen war das Update auf Java 9 in Ordnung, newInstance() auf Class habe ich öfters gebraucht, das ist jetzt deprecated. Mein Bsp. mit der Javadoc API funktioniert nicht mehr, das Modulsystem macht mir einen Strich durch das Programm.

Mit der Gewichtung Swing/Java FX bin ich nicht zufrieden. Java FX ist weiterhin kein Teil der offiziellen Java SE, sondern nur Teil vom Oracle/Open JDK. Außerdem ist die Zukunft auch hier unsicher, jetzt, wo schon so viele Entwickler vom Projekt. abgezogen wurden. Der Trend geht ganz klar Richtung Web, sodass ich eigentlich beide Kapitel massiv kürzen sollte bis nur noch eine Einleitung stehen bleibt und noch mal ein Web-Kapitel ergänzen sollte. Was ist eure Meinung?

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.

Neues findAll(…) in Scanner

Immer dann, wenn ein Scanner mit einem regulären Ausdruck konfiguriert wurde, wird intern der Zustand vom dafür zugewiesenen Matcher aktualisiert. Die Scanner-Methode match() liefert einen MatchResult der letzten Operation, allerdings folgt eine IllegalStateException, wenn es keinen Match gab oder der letzte Match nicht erfolgreich war.

Beispiel: Finde alles, was im inneren zwischen <b></b> steht:

Scanner sc = new Scanner( "Wichtig: <b>essen</b> und <b>trinken</b>!";
 while ( sc.findInLine( "<b>(.+?)</b>" ) != null )
   System.out.println( scanner.match().group( 1 ) );

Die Ausgabe ist dann „essen“ und „trinken“.

Java 9 bringt die neue Methode Stream<MatchResult> findAll(Pattern pattern)/ findAll(String patString) mit.

Beispiel: Finde alles, was im inneren zwischen <b></b> steht:

new Scanner( "<b>essen</b> und\n <b>trinken</b>" )

  .findAll( "<b>(.+?)</b>" )

  .forEach( matchresult -> System.out.println( matchresult.group( 1 ) ) );

Die Ausgabe ist ebenfalls „essen“ und „trinken“.

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") ) );

Index-bezogene Programmargumente auf Korrektheit prüfen

Im Kapitel über Ausnahmen haben wir schon auf die Notwendigkeit hingewiesen, Wertebereiche zu prüfen und im Fehlerfall Ausnahmen  wie IllegalArgumentException oder IndexOutOfBoundsException auszulösen um keine falschen Werte in das Objekt zu lassen.

In Java 9 sind drei Methoden hinzugekommen, die die gültigen Werbereiche von Index-basierten Methoden prüfen können und im Fehlerfall eine IndexOutOfBoundsException auslösen.

class java.util.Objects

  • static int checkIndex(int index, int length)
  • static int checkFromToIndex(int fromIndex, int toIndex, int length)
  • static int checkFromIndexSize(int fromIndex, int size, int length)

Beispiel: Implementierung der get(int)-Methode in ArrayList:

public E get(int index) {

  Objects.checkIndex(index, size);

  return elementData(index);

}

 

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“.

 

Geld und Währung in Java

Geldbeträge repräsentieren

Für Geldbeträge gibt es in Java keinen eigenen Datentyp und so kann eine Speicherung je nach Programm immer anders aussehen. Es bieten sich an:

  • BigDecimal: Vorteil sind die präzisen Berechungen und die wählbaren Rundungen
  • Paar von int long: Getrenntes Speichern der Vor-/Nachkommastellen

Hinweis: Die primitiven Datentypen double und float sind wegen ihrer Unfähigkeit Vielfaches von 0.01 korrekt dazustellen nicht empfohlen; Rundungsfehler treten schnell auf.

Money and Currency API

Im „JSR 354: Money and Currency API“ wird ein eigener Datentyp für Geldbeträge definiert, und die Typen sollen eigentlich in Java 9 aufgenommen werden, doch dazu kam es nicht. Dennoch sind die Typen interessant und die Referenzimplementierung Moneta ein Blick wert: http://javamoney.github.io/ri.html. Neben Geldbeträgen erlaubt die kleine Bibliothek auch Umrechungen, Formatierungen und eigene Währungen.

ISO 4217

Währungen werden durch Währungscodes beschrieben, und die Definition findet sich in der Norm ISO 4217. Einige ISO-Codes sind:

ISO 4217-Code Währung/Einheit Land
EUR Euro Länder der europäischen Währungsunion
CNY Renminbi China
DKK Krone Dänemark
GBP Pfund Vereinigtes Königreich
INR Rupie Indien
USD Dollar USA, Ecuador, …
XAU Feinunze Gold  

Einige ISO 4217-Codes

Die Tabelle lässt am letzten Eintrag erkennen, dass es auch ISO-Codes für Edelmetalle und sogar Fonds gibt. Für jedes Kürzel gibt es ebenfalls einen numerischen Code.

Währungen in Java repräsentieren

Java repräsentiert Währungen durch die Klasse java.util.Currency. Exemplare der Klasse werden durch eine Fabrikmethode getInstance(String currencyCode) erfragt, bzw. aus einer Aufzählung ausgewählt.

Beispiel: Gib alle im System angemeldeten Währungen mit ein paar Informationen aus:

Currency.getAvailableCurrencies().stream()

        .sorted( Comparator.comparing( Currency::getCurrencyCode ) )

        .forEach( c -> System.out.printf( "%s, %s, %s, %s%n",

                                          c.getCurrencyCode(), c.getSymbol(),

                                          c.getDisplayName(), c.getNumericCode() ) );

Die Ausgabe beginnt so:

ADP, ADP, Andorranische Pesete, 20

AED, AED, VAE-Dirham, 784

AFA, AFA, Afghanische Afghani (1927–2002), 4

AFN, AFN, Afghanischer Afghani, 971

ALL, ALL, Albanischer Lek, 8

Unterschiede suchen mit Arrays.mismatch (…)

Neu in Java 9 sind weiterhin diverse Methoden

  • int mismatch(XXX[] a, XXX[] b)
  • int mismatch(XXX[] a, int aFromIndex, int aToIndex, XXX[] b, int bFromIndex, int bToIndex)

Sie geben den Index auf das erste Element zurück was ungleich ist. Sind beide Felder gleich ist die Rückgabe -1.

Für Objekt-Array gibt es weiterhin:

  • int mismatch(Object[] a, Object[] b)
  • int mismatch(Object[] a, int aFromIndex, int aToIndex, Object[] b, int bFromIndex, int bToIndex)
  • <T> int mismatch(T[] a, T[] b, Comparator<? super T> cmp)
  • <T> int mismatch(T[] a, int aFromIndex, int aToIndex, T[] b, int bFromIndex, int bToIndex, Comparator<? super T> cmp)

Die erste/zweite Methode nutzt direkt equals(…), die dritte/vierte einen externen Comparator.

Lexikografische Array-Verbleiche mit compare (…) und compareUnsigned(…)

Diverse in Java 9 eingeführte int compareXXX(XXX[] a, XXX[] b)-Methoden gehen die Arrays ab und testen alle Paare auf ihre Ordnung. Es gibt die von Comparator bekannte Rückgabe: ist jedes a[i] == b[i] ist die Rückgabe 0. Ist in der Abfragefolge ein a[i] kleiner als b[i] ist, dann ist die Rückgabe negativ, ist ein a[i] größer als b[i] ist die Rückgabe positiv. Die Methode ist überladen mit einer Variante, die einen Bereich im Array auswählt: compare(XXX[] a, int aFromIndex, int aToIndex, XXX[] b, int bFromIndex, int bToIndex). Für byte, short, int und long gibt es weiterhin eine Vergleichsmethode ohne Vorzeichen über den gesamten Wertebereich:

  • int compareUnsigned(XXX[] a, XXX[] b)
  • int compareUnsigned(XXX[] a, int aFromIndex, int aToIndex, XXX[] b, int bFromIndex, int bToIndex)

Für Objekte gibt es eigene Methoden:

  • static <T extends Comparable<? super T>> int compare(T[] a, T[] b)
    Vergleiche zwei Objekt-Arrays, wobei der Comparator die Gleichheit der Objektpaare feststellt.
  • static <T extends Comparable<? super T>> int compare(T[] a, int aFromIndex, int aToIndex, T[] b, int bFromIndex, int bToIndex)
    Vergleiche von Ausschnitten.
  • static <T> int compare(T[] a, T[] b, Comparator<? super T> cmp)
  • static <T> int compare(T[] a, int aFromIndex, int aToIndex,T[] b, int bFromIndex, int bToIndex, Comparator<? super T> cmp)
    Vergleicht mit Hilfe eines externen Comparator-Objekts.

Objekt-Arrays mit Arrays.equals(…) und Arrays.deepEquals(…) vergleichen

Die Arrays.equals(…)-Methode kann auch beliebige Objektfelder vergleichen, doch nutzt sie dann nicht die Identitätsprüfung per ==, sondern die Gleichheit per equals(…). Eine seit Java 9 hinzugekommene Methode fragt einen Comparator.

Beispiel

Enthalten zwei String-Arrays die gleichen Wörter, wobei Groß-/Kleinschreibung keine Rolle spielt?

String[] words1 = { "Zufriedenheit", "übertrifft" , "Reichtum" };

String[] words2 = { "REICHTUM", "übertrifft" , "ZuFRIEDEnheit" };

Arrays.sort( words1, String.CASE_INSENSITIVE_ORDER );

Arrays.sort( words2, String.CASE_INSENSITIVE_ORDER );

System.out.println( Arrays.equals( words1, words2, String.CASE_INSENSITIVE_ORDER ) );

class java.util.Arrays

  • staticbooleanequals(Object[]a,Object[]a2)
    Vergleicht zwei Arrays mit Objektverweisen. Ein Objekt-Array darf null enthalten; dann gilt für die Gleichheit e1==null ? e2==null : equals(e2).
  • staticbooleandeepEquals(Object[]a1,Object[]a2)
    Liefert true, wenn die beiden Arrays ebenso wie alle Unter-Arrays – rekursiv im Fall von Unter-Objekt-Arrays – gleich sind.
  • static <T> boolean equals(T[] a, T[] a2, Comparator<? super T> cmp)
    Vergleicht zwei Arrays und compare(a[i], b2[i]) muss für alle Pärchen 0 sein, damit beide Elemente als gleich gelten. Neu in Java 9.
  • static <T> boolean equals(T[] a, int aFromIndex, int aToIndex, T[] b, int bFromIndex, int bToIndex, Comparator<? super T> cmp)
    Vergleiche Ausschnitte von Arrays mit einem Comparator. Neu in Java 9.

Arrays mit Arrays.equals(…) und Arrays.deepEquals(…) vergleichen

Die statischen Methoden Arrays.equals(…) vergleichen, ob zwei Arrays die gleichen Inhalte besitzen; dazu ist die überladene Methode für alle wichtigen Typen definiert. Wenn zwei Arrays tatsächlich die gleichen Inhalte besitzen, ist die Rückgabe der Methode true, sonst false. Natürlich müssen beide Arrays schon die gleiche Anzahl von Elementen besitzen, sonst ist der Test sofort vorbei und das Ergebnis false. Im Fall von Objekt-Arrays nutzt Arrays.equals(…) nicht die Identitätsprüfung per ==, sondern die Gleichheit per equals(…).

Beispiel

Vergleiche drei Arrays:

int[] array1 = { 1, 2, 3, 4 };

int[] array2 = { 1, 2, 3, 4 };

int[] array3 = { 9, 9, 2, 3, 9 };

System.out.println( Arrays.equals( array1, array2 ) );              // true

System.out.println( Arrays.equals( array2, 1, 3, array3, 2, 4 ) );  // true

Ein Vergleich von Teil-Arrays ist erst in Java 9 hinzugekommen.

Bei unterreferenzierten Arrays betrachtet Arrays.equals(…) das innere Array als einen Objektverweis und vergleicht es auch mit equals(…) – was jedoch bedeutet, dass nicht identische, aber mit gleichen Elementen referenzierte innere Arrays als ungleich betrachtet werden. Die statische Methode deepEquals(…) bezieht auch unterreferenzierte Arrays in den Vergleich ein.

Beispiel

Unterschied zwischen equals(…) und deepEquals(…):

int[][] a1 = { { 0, 1 }, { 1, 0 } };
 int[][] a2 = { { 0, 1 }, { 1, 0 } };
 System.out.println( Arrays.equals( a1, a2 ) );     // false
 System.out.println( Arrays.deepEquals( a1, a2 ) ); // true
 System.out.println( a1[0] );                       // zum Beispiel [I@10b62c9
 System.out.println( a2[0] );                       // zum Beispiel [I@82ba41

Dass die Methoden unterschiedlich arbeiten, zeigen die beiden letzten Konsolenausgaben: Die von a1 und a2 unterreferenzierten Arrays enthalten die gleichen Elemente, sind aber zwei unterschiedliche Objekte, also nicht identisch.

Hinweis

deepEquals(…) vergleicht auch eindimensionale Arrays:

Object[] b1 = { "1", "2", "3" };
 Object[] b2 = { "1", "2", "3" };
 System.out.println( Arrays.deepEquals( b1, b2 ) ); // true

class java.util.Arrays

  • staticbooleanequals(XXX[]a,XXX[]a2)
    Vergleicht zwei Arrays gleichen Typs und liefert true, wenn die Arrays gleich groß und Elemente paarweise gleich sind. XXX steht stellvertretend für boolean, byte, char, int, short, long, double, float.
  • staticbooleanequals(XXX[] a, int aFromIndex, int aToIndex, XXX[] b, int bFromIndex, int bToIndex)
    Vergleicht zwei Arrays, bleibt jedoch in den gewählten Ausschnitten. Neue Methoden in Java 9.
  • staticbooleanequals(Object[]a,Object[]a2)
    Vergleicht zwei Arrays mit Objektverweisen. Ein Objekt-Array darf null enthalten; dann gilt für die Gleichheit e1==null ? e2==null : equals(e2).
  • staticbooleandeepEquals(Object[]a1,Object[]a2)
    Liefert true, wenn die beiden Arrays ebenso wie alle Unter-Arrays – rekursiv im Fall von Unter-Objekt-Arrays – gleich sind.

Die Schnittstelle Checksum

Wir finden Zugang zur Prüfsummenberechnung über die Schnittstelle java.util.zip.Checksum, die für ganz allgemeine Prüfsummen steht. Eine Prüfsumme wird entweder für ein Feld oder ein Byte berechnet. Checksum liefert die Schnittstelle zum Initialisieren und Auslesen von Prüfsummen, die die konkreten Prüfsummen-Klassen implementieren müssen.

interface java.util.zip.Checksum

  • longgetValue()
    Liefert die aktuelle Prüfsumme.
  • voidreset()
    Setzt die aktuelle Prüfsumme auf einen Anfangswert.
  • voidupdate(intb)
    Aktualisiert die aktuelle Prüfsumme mit dem Byte in b.
  • voidupdate(byte[]b,intoff,intlen)
    Aktualisiert die aktuelle Prüfsumme mit den Bytes aus dem Array.
  • default public void update(byte[] b)
    Implementiert als update(b, 0, b.length); – neu in Java 9.
  • default public void update(ByteBuffer buffer)
    Aktualisiert die Prüfsumme mit den Bytes aus dem buffer. Neu in Java 9.

Die Standardbibliothek bietet bisher drei Klassen für die Prüfsummenberechnung als Implementierungen von Checksum:

  • util.zip.CRC32: CRC-32 basiert auf einer zyklischen Redundanzprüfung und testet etwa ZIP-Archive oder PNG-Grafiken. Nativ in C programmiert.
  • util.zip.CRC32C: CRC-32C nutzt ein anderes Polynom als CRC-32, verfolgt aber das gleiche Berechungsprinzip. Das JDK implementiert es in purem Java und nicht nativ. Die Ausführungszeit kann dennoch besser sein. Neu in Java 9.
  • util.zip.Adler32: Die Berechnung von CRC-32-Prüfsummen kostet viel Zeit. Eine Adler-32-Prüfsumme kann wesentlich schneller berechnet werden und bietet eine ebenso geringe Wahrscheinlichkeit, dass Fehler unentdeckt bleiben.

Die Klasse CRC32

Oft sind Polynome die Basis der Prüfsummenberechnung. Eine häufig für Dateien verwendete Prüfsumme ist CRC-32.

Nun lässt sich zu einer 32-Bit-Zahl eine Prüfsumme berechnen, die genau für diese 4 Byte steht. Damit bekommen wir aber noch keinen ganzen Block kodiert. Um das zu erreichen, berechnen wir den Wert eines Zeichens und XOR-verknüpfen den alten CRC-Wert mit dem neuen. Jetzt lassen sich beliebig Blöcke sichern. Die Berechnung ist insgesamt sehr zeitaufwändig, und Adler-32 stellt eine schnellere Alternative dar.

Beispiel

Die Klasse CRC32 berechnet eine Prüfsumme über alle durchlaufenden Bytes, die gereicht werden als einzelne Bytes oder Felder. In aller Kürze sieht ein Programm zur Berechnung von Prüfsummen für ein paar Eingaben folgendermaßen aus:

CRC32 crc = new CRC32();
crc.update( 1 );
crc.update( new byte[]{ 2, 3, 4, 5, 6, 7 } );
System.out.println( crc.getValue() ); // 1894017160

CRC32 implementiert nicht nur alle Methoden, sondern fügt noch zwei Methoden und natürlich einen Konstruktor hinzu: