Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Java 9: Ein erster Blick

Reactive Streams im JDK

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
In diesem Film erklärt Ihnen Christopher Janietz die konkrete Nutzung von reaktiven Streams im Java Development Kit 9.

Transkript

Die Konzepte, wie Reactive-Streams im Java-Developpement-Kit implementiert sind, entsprechen im Wesentlichen der Idee von reactive-streams.org. Die einzige wesentliche Änderung ist, dass das Java-Developpement-Kit einen solchen Reactive-Stream als Flow bezeichnet. Flow wird innerhalb des Java.util.concurrent Pakets definiert. Das heißt also auch, dass die Basisimplementierung vor allem mit Threads arbeitet. Ein solches Flow hat das Interface Flow.Publisher. Dafür gibt es eine Implementierung, die standardmäßig im JDK enthalten ist, den SubmissionPublisher. Alle anderen Modelle sind lediglich Interfaces. Dazu gehört der FlowSubscriber, die FlowSubscription und der FlowProcessor. Als Nächstes zeige ich Ihnen nun Live, wie ein SubmissionPublisher funktioniert. An der Stelle habe ich nun bereits ein Projekt auf Basis des Java-Developpment-Kit 9 angelegt. Hier habe ich eine Klasse definiert mit der Bezeichnung Reactive-Streams und einen Einstiegspunkt für mein Java-Anwendung. Zunächst einmal erzeuge ich nun einen SubmissionPublisher. Dafür verwende ich also SubmissionPublisher vom Typ String gebe diesem den Namen "logPublisher" (Tippen) und initialisiere ihn mit dem "New keyword". (Tippen) Die einfachste Art und Weise nun Daten zu empfangen für einen solchen Publisher, ist mit der "consume" -Methode. Ich verwende also "logPublisher. consume" und kann hier einen Lambda-Ausdruck verwenden. Beispielsweise "System. aut (Tippen) println". Damit werden also alle Nachrichten, die an diesen LogPublisher gesendet werden, an die Kommandozeile gesendet. Um nun Daten an einen Publisher zu senden, kann ich die "publisher. submit" -Methode verwenden. (Tippen) Diese nimmt also nun ein Objekt vom Typ des Submission Publishers entgegen in dem Fall also String. (Tippen) In dem Moment, wo ich die Applikation nun starte, erhalte ich nicht die erwartetet Logausgabe. Das liegt daran, dass ein Publisher parallelisiert läuft. Das heißt also, ich sollte zunächst einmal warten, ob tatsächlich der Inhalt an meine Kommandozeile gesendet wird. Hierfür verwende ich kurze Hand eine Instruktion "thread. sleep" und warte an der Stelle für 10 Sekunden. In dem Fall sehe ich also nun, dass der Text an die Kommandozeile über den Lambda-Ausdruck gesendet wurde. Alternativ dazu kann ich auch einen Subscriber implementieren. (Tippen) Hierfür definiere ich also eine eigene Klasse. (Tippen) in dem Fall statisch mit der Bezeichnung (Tippen) "logSubscriber". Diese implementiert das Interface "Flow-subscriber" (Tippen) für String-Daten. (Tippen) Als Nächstes muss ich nun die folgenden Daten implementieren. "on subscribe, on next, on error" und "on completed". "On completed" wird also immer dann ausgelöst, wenn meine Subscription geschlossen wird soweit der Publisher auch keine Daten mehr hat. Ich verwende also hier "System.aut.println" (Tippen) "completed". Des weiteren erhalte ich hier einen Stack-Trace, falls ein Fehler auftritt. (Tippen) Meine Ausgabe in dem Fall ist "error occured" (Tippen) (Tippen) (Tippen) und "print Stack traces" Immer dann wenn tatsächlich ein Element empfangen wird, wird die Methode "on next" ausgelöst. (Tippen) Hier kann ich also beispielsweise diese dann, wie im vorherigen Beispiel, auf die Konsole ausgeben. Sobald ich meine Subscription erhalte, kann ich auf der Subscription nun signalisieren, wie viele Daten ich entgegen nehmen kann. (Tippen) beispielsweise "Long. MAX VALUE". Damit kann ich also unendlich viele Daten entgegen nehmen. Als Nächstes kann ich einen solche Subscriber erzeugen. (Tippen) (Tippen) (Tippen) Und statt der "consume" -Methode, verwende ich nun "LogPublischer. subscribe" (Tippen) mit meinem LogSubscriber. Nach dem Senden des Textes, kann ich meine LogPublisher auch schließen. In dem Fall erhalte ich also den Text und dann den Abschluss mit "completed" innerhalb meines Subscribers. Eine Information, die mir verloren geht, falls ich lediglich die "consume" -Methode verwende. Alternativ kann ich einen SubmissionPublisher auch mit einigen Parametern erzeugen. Dazu gehört ein "executors", also ein "thread Pool", beispielsweise erzeugt über "executors" (Tippen) ".newCachedThreadPool" (Tippen) und einer Buffer-Kapazität. Dieser Buffer-Kapazität ist die Menge an Daten, die vorgehalten werden für einen Subscriber, falls dieser aktuell keine Daten entgegen nehmen kann. Es ist also ein Limit an Daten, das aufgehoben wird. Falls zusätzliche Daten kommen, werden diese ignoriert. Der Standardwert liegt hier bei 256. Im Zusammenhang damit steht auch die "submit" -Methode. Denn aktuell blockiert sie so lange, bis tatsächlich Kapazitäten zur Verfügung stehen, um die Daten an jeden Subscriber zu übertragen. Alternativ kann ich neben "submit" auch "offer" verwenden. In dem Fall wird also ein Element angeboten und ich kann zusätzlich einen Timeout definieren. Dieser Timeout definiert dann, wie viel Zeit maximal gewartet wird, um dieses Element an alle Subscriber zu schicken. (Tippen) Ich kann nun also beispielsweise 5000 (Tippen) mit der Timeunit milliseconds angeben, für fünf Sekunden. Außerdem muss ich noch einen Ausdruck definieren, der aussagt, was passiert falls ein Subscriber dieses Element nicht entgegen nehmen kann. (Tippen) (Tippen) (Tippen) In diesem Fall könnte ich das Element also nun beispielsweise auf der Konsole ausgeben oder aufheben. (Tippen) Falls mir das Ganze völlig egal ist, kann ich auch einfach (Tippen) mit "true" bestätigen. In dem Fall signalisiere ich also, meiner "offer" -Funktion, dass das Element ignoriert werden kann. Sie haben also gesehen, dass der SubmissionPublisher die tatsächlich einzige Implementierung im Java-Developpement-Kit ist. Alle anderen Konzept von reactive-Streams sind Interfaces. Ein SubmissionPublisher wird auf Basis eines Thread-Pools erzeugt und eines Buffers. Die Buffer-Kapazität gilt dann pro Subscriber. Kann ein Subscriber also aktuell keine Daten entgegen nehmen und ist die Buffer-Kapazität erreicht, so werden die Objekte dann ignoriert. Das Bereitstellen von Daten auf einem solchen Publisher kann entweder mit dem blockierenden Aufruf von "submit" erfolgen oder alternativ mit dem Aufruf von "offer". Beim Aufruf von "offer" kann man einen Timeout definieren, als auch eine Aktion, die dann ausgelöst wird, falls ein Subscriber gerade diese Daten nicht entgegen nehmen kann.

Java 9: Ein erster Blick

Entdecken Sie die Highlights der aktuellen Java-Version.

2 Std. 14 min (21 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:22.08.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!