Da Javaslang an vielen Stellen seinen eigenen Weg geht, wird es notwendig Konvertierung von und nach Java anzubieten. Solange es sich nur um skalare Werte handelt ist das einfach, für andere, komplexere Objekte bietet es Konvertierungsfunktionen wie toJavaArray|List|Set|Map|Optional|Stream() oder geeignete Konstruktoren an.

Javaslang macht Konstrukte verfügbar, die das Fundament funktionaler Sprachen bilden: Tuples, Container als unveränderliche Datenstrukturen, monadische Typen, Pattern Matching, Currying, Memoization und mehr.

Ein wichtiger Grundansatz funktionaler Programmierung ist die Kapselung und Kontrolle von Seiteneffekten von Funktionen. Das heisst, alle Effekte die nicht mit der direkten Transformation von Parametern zu Rückgabewerten zu tun haben.

Damit sind nicht nur die Veränderung von Zuständen, Ausgabe und Eingabe von Informationen gemeint, sondern auch Effekte wie Exceptions die einen abnormale Unterbrechung des Programmflusses darstellen.

In funktionalen Sprachen wird explizit mit solchen Aspekten umgegangen, genau wie mit NULL. Statt Verhaltens dass den Programmablauf verändert, werden diese Fakten in Datenstrukturen festgehalten.

Funktionale Programmierung liegt viel näher am mathematischen Konzept einer Funktion f(x) = y also einer Abbildung von Eingabe auf Ausgabe.

Wenn Funktionen keine Seiteneffekte haben und nur auf ihren Eingabeparametern beruhen (und nicht auf zusätzlichen Informationen oder Zufallswerten) und damit eine direkte Abbildung oder explizite Transformation darstellen, werden sie als "pure Funktionen" bezeichnet.

Sofern man darauf achtet, kleine, überschaubare und generalisierte Funktionen zu entwickeln, die zu komplexeren Aufgaben und Algorithmen komponiert werden können, ist man bei den kindlichen Freuden eines Lego Projekts angekommen. Jeder relevante Aspekt ist in einer eigenen, benannten und wiederverwendbaren Funktion gekapselt die in sich verständlich und zugleich leicht zu testen ist.

Für die Konstruktion komplexerer funktionaler Systeme, ist es natürlich notwendig, höherwertige Funktionen zu unterstützen, d.h. Funktionen, die Funktionen erzeugen und auch entgegennehmen, was ja glücklicherweise mit Lambdas heutzutage viel einfacher zu realisieren ist.

Pure Funktionen können auch bei Bedarf direkt durch ihren Ergebniswert ersetzt werden. Diese Optimierung ist ein Inlining zur Laufzeit und wird als Memoization bezeichnet.

Es ist für Menschen und Compiler viel leichter nachzuweisen, dass Funktionen keine Seiteneffekte haben, wenn diese nur mit unveränderlichen (immutable) Objekten arbeiten. Natürlich kann man auch veränderliche Objekte diszipliniert benutzen, aber das ist ungleich schwerer, als einfach keine Möglichkeit zu haben, den Zustand einer Instanz direkt zu ändern.

Aus Performancegründen kann es jedoch notendig sein, veränderliche Objekte innerhalb einer Funktion zu verwenden. Meist ist dies aber nur für bibliotheksinterne Mechanismen notwendig. Dann dürfen diese veränderlichen Objekte aber nie die Funktion verlassen, sondern müssen vorher in unveränderliche Objekte umgeformt werden.

Unveränderliche Objekte haben noch die nette Eigenschaft keine Synchronization bei der Nutzung durch mehrere Threads zu benötigen, was uns bei der Entwicklung parallelverarbeitender Systeme unterstützt. In Scala werden diese Konzepte mit dem val Schlüsselwort für Attribute und Case-Klassen unterstützt. Objekte können in Java leicht unveränderlich gemacht werden, indem all ihre Felder als final deklariert sind, und die Werte, die sie speichern ebenfalls unveränderlich sind. Für Container-Klassen ist das schon schwieriger, da die Java-Klassenbibliotheken in java.util darauf keinen Wert legen, und nur vereinzelte Vertreter wie java.util.concurrent.CopyOnWriteArrayList so ein Verhalten zeigen.

Effekte, wie das Nichtvorhandensein von Werten (entsprechend null), der Fehlschlag von Operationen, Seiteneffekte oder zukünftig ausgeführte Operationen, werden funktional in Datenstrukturen gekapselt die "Monade" genannt werden. Ich möchte hier nicht wie so viele Autoren mich in Erklärungen verstricken, sondern eher die Anwendbarkeit zeigen.

In Javaslang sind solche Datentypen von Value abgeleitet, worin Funktionalitäten rund um die Kapselung eines Wertes schon implementiert sind.

Das sind Funktionen zur Inspektion und Verarbeitung des Wertes wie isDefined, getOrElse oder map, Konversion in andere Javaslang oder Java Container, Vergleiche und Prädikate auf dem Wert, sowie explizite Ausgabe des Wertes. Value selbst ist auch ein java.lang.Iterable auf seinem Wert.

Konkrete Suklassen von Value decken dann spezifische Anwendungsfälle ab.

Tuples sind wie in der Mathematik einer der Basisbausteine funktionaler Sprachen. Diese kompakten, streng getypten Strukturen (ähnlich zu structs) von n Elementen existieren meist für viele Kardinalitäten von 2 bis n und sind dank generischer Typparameter für die Elemente leicht nutzbar. Javaslang bietet Tupel mit Kardinalitäten bis zu 8 Elementen.

Dass Tupel zu vollwertigen Bestandteilen einer funktionalen Implementierung gehören, wird an ihren Eigenschaften deutlich, sie sind unveränderlich, vergleichbar, serialisierbar und können mit vielen Funktionen wie map und transform umgewandelt werden. Wie in Scala nutzt Javaslang tuple._X als Zugriffsmechanismus für die Elemente des Tupels.

Tupels werden zum Beispiel genutzt, um Schlüssel-Wert-Paare oder komplexere Strukturen zu repräsentieren, oder um eine Funktion mit mehreren Rückgabewerten zu realisieren.

In Java 8 ist es leichter, Implentationslogik in kleinen, wiederverwendbaren, funktionalen Einheiten zu kapseln, ohne diese an Objektinstanzen zu binden. Besonders die Nutzung von Lambdas überall dort, wo passende Interfaces und Klassen mit einer einzigen abstrakten Methode (SAM - single abstract method) verwendet werden, ermöglicht existierende APIs ohne Änderung modern und funktional zu integrieren.

Mit Functional Interfaces wie Supplier, Consumer, Predicate, Function, BiFunction usw. hat Java 8 schon den ersten Schritt gemacht, Funktionen mit höherer Parameterzahl sucht man aber im JDK noch vergeblich. Auch höherlevelige Operationen auf diesen Funktionen, zur Komposition, Reduktion und Transformation fehlen noch.

Diese rüstet Javaslang nach, dabei sind Funktionen als Interfaces verschiedener Kardinalitäten mit vielen default Methoden implementiert. Z.B. arity,apply,curried,reversed,memoized, die aus dem schickerweise λ genannten Grundinterface kommen.

In der Typsignatur folgt der Rückgabewert, den Parametertypen, z.b. Function2<P1,P2,R>. Die Java-Nomenklatur wird, wo es möglich istm integriert - Function2 erweitert BiFunction, Function1` ist eine Function und Function0 ein Supplier.

Memoization wird genutzt um Ergebnisse häufig genutzer (teurer) Funktionsaufrufe zu cachen und da die Funktionen ja seiteneffektfrei sein müssen, direkt durch ihre Ergebnisse zu ersetzen. Dabei wird das erste Ergebnis noch berechnet, aber alle folgenden Aufrufe aus dem Cache bedient.

Um die Kompaktheit funktionaler Sprachen zu demonstrieren, dienen meist kleine Beispiele, die auf einem Strom oder Listen von Daten mehrere Operationen hintereinander ausführen. Statt expliziter externer Iteration wie mit Iterator`en oder `for-Schleifen, wird interne Iteration genutzt.

Dabei werden auf Operationen wie map, reduce, filter auf dem Datenstrom aufgerufen, und ggf. eigene (anonyme) Funktionen als Parameter übergeben. Das ist der Code, der sonst den Schleifenkörper ausmachen würde. Damit hat die Datenstruktur und die Sprache eine viel größere Kontrolle über die Ausführung von Operationen. Sie können entweder sofort oder später (lazy) evaluiert werden, oder viel später zusammengefasst mit weiteren Operationen. Ein weiterer Vorteil ist die verzögerte Ausführung, die es ermöglicht, Operationen auf unendlichen Datenstrukturen vorzunehmen, die erst beim schlussendlichen Konsumieren der Ergebnisse ausgeführt werden, und zwar nur so weit wie nötig.

In Javaslang basieren alle Container-Datentypen ählich wie in Scala auf der Basisklasse Traversable das von Value und damit java.lang.Iterable und von Foldable mit Faltungsoperationen wie foldLeft() oder reduce() erbt. Wie üblich ist Traversable ein sehr breites Interface mit Operationen aller Coleur von average() über empty() und map() bis zu zip(). Subklassen von Traversable sind z.B. Iterator, Seq, Set, List, Map, Tree und viele mehr.

Die gerade genannten Interfaces stellen die API für die Javaslang Containerklassen dar. Anders als in den Java-Collections sind die Javaslang Container aber unveränderlich (immutable). Sie können nach ihrer Erzeugung nicht mehr verändert werden. Jedenfalls nicht die konkrete Instanz. Jede Änderungsoperation hat eine "neue" Kopie zur Folge, die die Veränderungen geeignet in sich trägt.

Wie bekannt bietet auch Java mit den Collections.unmodifiableXxx() Methoden an, um unveränderliche Container zu erzeugen. Dies sind aber nur Wrapper, die für alle Modifikationsmethoden der API Laufzeitfehler (RuntimeExceptions) erzeugen.

Korrekte unveränderliche Container bieten auch funktionierende Modifikationsmethoden an, nur erzeugen diese eine schlanke, minimale Kopie der Originalinformationen in der der neue Zustand durch Überlagerung erzeugt wird. Dieses Konzept schreibt noch keine Implementierung vor, es gibt verschiedene Ansätze es umzusetzen.

Ich habe in der Vergangenheit die Persistent Datastructures von Clojure beschrieben [Hunger-JS-04-12], die auf `HashTrie`s, effektiven Baumstrukturen, die nur die veränderten Teilbäume mit einem neuen Wurzelknoten verlinken und alle anderen Teilbäume der Originalstruktur beibehalten.

Javaslang liefert eine Containerbibliothek mit, die als sicherer, aber effizienter Ersatz für die Java-Collections für die funktionale Programmierung dienen soll. Mit ihnen gemeinsam hat sie über Traversable nur die Iterable und Iterator Interfaces. Die anderen Collection-Interfaces waren leider nicht nachnutzbar, da Methoden, die den Container veränderten, nicht die veränderte Instanz zurückgeben.

Sortierte Sets werden durch balancierte (Red-Black) Binärbäume abgebildet. Wie üblich haben rekursive Operationen auf solchen Bäumen eine Komplexität abhängig von der Baumtiefe, also O(log2(n)). Bei der Modifikation wird wie bei den im früheren Artikel beschriebenen Persistent Data Structures ein neues Wurzelelement mit dem minimal notwendige Teilbaum für die Modifkation erzeugt und mit den vorher existierenden Bäumen verknüpft.

Resultieren in einer Struktur wie in folgender Abbildung gezeigt. Deutlich kann man die 2 Wurzelelemente und die neuen und verlinkten Teilbäume erkennen.

Maps werden als Sequenzen von zweielementigen Tuplen representiert. Sortierte Maps werden durch die gerade beschriebenen Binärbäume von Tupeln mit Sortierung nach Schlüsseln repräsentiert.

Und wie in den Persistent Data Structures erwähnt werden HashMaps und HashSets als Trie [Hash Array Mapped Trie - HAMT] implementiert.

In Java 8 sind Streams unabhängig von der Collections API, so dass sie erst über Umwege wie StreamSupport.stream(spliterator, false) oder die Collector-API zusammengebracht werden müssen.

In Javaslang ist das deutlich besser integriert, und dank der Unterstützung von Iterable, kann man die Container und Javaslang Streams auch in foreach-Schleifen benutzen. Intern wird ein (potentiell unendlicher) Strom von Daten durch eine verzögert verlinkte Struktur aus aktuellem Kopfelement und einem Supplier von weiteren Elementen repräsentiert aus der bei jedem Fortschritt ein weiteres Element gezogen wird.

Pattern Matching ist eine mächtige, funktionale Variante von switch, die viel mehr Möglichkeiten zur Entscheidung über Werte bietet, aber gleichzeitig die Extraktion von gekapselten Informationen aus unveränderlichen Strukturen erlaubt (Dekonstruktion). Ein Pattern Match ist auch wieder ein Ausdruck, d.h. es gibt in jedem Fall ein Ergebnis.

Javaslang versucht so nah wie möglich an der Mächtigkeit des Pattern Matching in Scala heranzukommen. Dazu gibt es eine eigene API in javaslang.API. Folgende Features werden unterstützt.

Prinzipiell wird ein Zweig mittels Case( $(wert|prädikat|), wert | funktion) ausgedrückt. Durch eine run Operation können auch Seiteneffekte ausgeführt werden.

Dekonstruktion von Objekten erfolgt durch unapply, die inverse Operation zu apply zur Konstruktion und Funktionsaufruf.

Interessanterweise nutzt Javaslang [Project Euler] um seine Implementierung auf Herz und Nieren zu testen.

Es gibt schon diverse Erweiterungen für Javaslang, die als Module vorliegen, z.B.

Bilder: (c) Daniel Dietrich aus dem Javaslang User Guide