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.

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

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:

In Java 9 wurde der Annotationstyp @Deprecated um zwei Eigenschaften erweitert:

• String since() default „“. Dokumentiert die Version, seit der das Element veraltet ist
• boolean forRemoval() default false. Zeigt an, dass das Element in Zukunft gelöscht werden soll.

Beispiel

Ein Beispiel aus der Thread-Klasse:

@Deprecated(since="1.2", forRemoval=true)

public final synchronized void stop(Throwable obj) {

  throw new UnsupportedOperationException();

}

Wenn es der Sicherheitsmanager zulässt, kann ein Programm auch private- oder protected-Attribute ändern und Methoden/Konstruktoren eingeschränkter Sichtbarkeit aufrufen. Die Schlüsselfigur in diesem Spiel ist die Oberklasse java.lang.reflect.AccessibleObject, die den Klassen Field und Excecutable (und damit Constructor und Method) die Methode setAccessible(boolean) vererbt. Ist das Argument true und lässt der Sicherheitsmanager die Operation zu, lässt sich auf jedes Element (also Konstruktor, Attribut oder Methode) ungleich der Sichtbarkeitseinstellungen zugreifen:

public class ReadPrivate {
 
   @SuppressWarnings( "unused" )
   private String privateKey = "Schnuppelhase";
 
   public static void main( String[] args ) throws Exception {
     ReadPrivate key = new ReadPrivate();
     Class<?> c = key.getClass();
     java.lang.reflect.Field field = c.getDeclaredField( "privateKey" );
     field.setAccessible( true );
     System.out.println( field.get(key) ); // Schnuppelhase
     field.set( key, "Schnuckibutzihasidrachelchen");
     System.out.println( field.get(key) ); // Schnuckibutzihasidrachelchen
   }
 }

class java.lang.reflect.AccessibleObject
implements AnnotatedElement

• void setAccessible(boolean flag)
  Nachfolgede Abfragen sollten die Java-Sichtbarkeiten ignorieren. Falls das nicht erlaubt ist, gibt es eine InaccessibleObjectException.
• final boolean trySetAccessible()
  Wie setAccessible(true), nur löst die Methode beim nicht gewährten Zugriff keine InaccessibleObjectException aus, sondern liefert false. Neu in Java 9.

Warnung: Mit dieser Technik lässt sich viel Unsinn anrichten. Es gibt Dinge, die in der Laufzeitumgebung einfach fest sein müssen. Dazu zählen einmal angelegte Strings oder Wrapper-Objekte. Strings sind immutable, weil sie intern in einem privaten char-Feld gehalten werden und es keine Modifikationsmöglichkeiten gibt. Auch Wrapper-Objekte sind, wenn sie einmal mit einem Konstruktor angelegt wurden, nicht über öffentliche Methoden veränderbar. Sie anschließend per Reflection zu modifizieren, bringt große Unordnung, insbesondere bei den gecachten Integer/Long-Wrapper-Objekten, die die statischen valueOf(…)-Methoden liefern.

Die Referenzen auf Objekte, die wir im Alltag um uns herum haben, heißen starke Referenzen, weil die automatische Speicherbereinigung niemals ein benutztes Objekt freigeben würde. Neben den starken Referenzen gibt es jedoch auch schwache Referenzen, die es dem GC erlaubt, die Objekte zu entfernen. Was erst einmal verrückt klingt wird dann interessant, wenn es um die Implementierung von Caching-Datenstrukturen geht; ist das Objekt im Cache, ist das schön und der Zugriff schnell – ist das Objekt nicht im Cache, dann ist das auch in Ordnung, und der Zugriff dauert etwas länger. Wir können schwache Referenzen also gut verwenden, um im Cache liegende Objekte aufzubauen, die die automatische Speicherbereinigung wegräumen darf, wenn es im Speicher knapp wird.

Schwache Referenzen interagieren also in einer einfachen Weise mit der automatischen Speicherbereinigung und dafür gibt es im java.base-Modul im Paket java.lang.ref ein paar Typen. Am Wichtigsten sind die Behälter (engl. reference object gennant), die wie ein Optional ein Objekt referenzieren, das aber plötzlich verschwunden sein kann:

• SoftReference<T>. Ein Behälter für softly reachable Objekte. Die Objekte werden vom GC spät freigegeben, wenn es kurz vor einem OutOutMemoryError
• WeakReference<T>. Ein Behälter für weakly reachable Objekte. Die Objekte werden vom GC schon relativ früh beim ersten GC freigegeben.
• PhantomReference<T>. Ein Behälter, der immer leer ist, aber dazu dient mitzubekommen, wenn der GC sich von einem Objekt trennt.
• Reference<T>. Abstakte Basisklasse von PhantomReference, SoftReference, WeakReference.

Die Behälter selbst werden vom GC nicht entfernt, sodass eine ReferenceQueue<T> ein Abfragen erlaubt, um festzustellen, welche Reference-Behälter leer sind und z. B. aus einer Datenstruktur entfernt werden können – leere Behälter sind nutzlos und können nicht wieder recycelt werden.

Ein neuer Typ ab Java 9 im Paket ist Cleaner, der eine Alternative zur Finalizierung ist. Beim Cleaner lässt sich eine Operation (vom Typ Cleaner.Cleanable) anmelden, die immer dann aufgerufen wird, wenn die automatische Speicherbereinigung zuschlägt und das Objekt nicht mehr erreichbar ist. Intern greift die Klasse auf PhantomReference zurück.

Beispiel: Lege einen Punkt an, registriere einen Cleaner und rege danach den GC an. Eine Konsolenausgabe „Punkt ist weg!“ ist wahrscheinlich:

Point p = new Point( 1, 2 );

Cleaner.create().register( p, () -> System.out.println( "Punkt ist weg!" ) );

p = null;

byte[] bytes = new byte[ (int) Runtime.getRuntime().freeMemory() ];

Auf keinen Fall darf die Aufräumoperation p wieder referenzieren.