Nach mehr als zwei Jahren gibt es ein Update der Insel: https://www.galileo-press.de/java-ist-auch-eine-insel_3606/. Aktualisiert auf Java 8, 1306 Seiten, ISBN 978-3-8362-2873-2, E-Book-Formate: PDF, EPUB, MOBI, Online.

Online ist das Buch nicht mehr, da es zu juristischen Auseinandersetzungen mit Mitbewerben kommen könnte. Vereinfacht ausgedrückt: Etwas verkaufen, was gleichzeitig frei ist, macht den Verlag verletzbar gegenüber Abmahnungen. Online bleibt aber weiterhin die jeweils letzte Version, also komplett wie üblich Auflage 10: http://www.tutego.de/javabuch/; das gilt auch für den 2. Band, den es ebenfalls bald im Handel geben wird.

Weiterhin ist eine PDF mit Kapitel 2 und 3 mit nahezu 300 Seiten vom 1. Band, 11. Auflage, online.

Funktionen realisieren Abbildungen und da es verschiedene Arten von Abbildungen geben kann, bietet die Java Standardbibliothek im Paket java.util.function für die häufigsten Fälle funktionale Schnittstellen an. Ein erster Überblick:

Schnittstelle	Abbildung
Consumer<T>	(T) → void
DoubleConsumer	(double) → void
BiConsumer<T, U>	(T, U) → void
Supplier<T>	() → T
BooleanSupplier	() → boolean
Predicate<T>	(T) → boolean
LongPredicate	(long) → boolean
BiPredicate<T, U>	(T, U) → boolean
Function<T, R>	(T) → R
LongToDoubleFunction	(long) → double
BiFunction<T, U, R>	(T, U) → R
UnaryOperator<T>	(T) → T
DoubleBinaryOperator	(double) → boolean

Beispiele einiger vordefinierter funktionaler Schnittstellen

Weiterlesen →

Das JDK bringt mit jdeps ein kleines statisches Analysewerkzeug mit, welches die statischen Abhängigkeiten eines Java-Programms aufzeigt. Dabei listet es alle referenzierten Pakete auf und optional noch die Profile.

 

$ jdeps

Usage: jdeps <options> <classes…>

where <classes> can be a pathname to a .class file, a directory, a JAR file,

or a fully-qualified class name. Possible options include:

-dotoutput <dir> Destination directory for DOT file output

-s -summary Print dependency summary only

-v -verbose Print all class level dependencies

-verbose:package Print package-level dependencies excluding

dependencies within the same archive

-verbose:class Print class-level dependencies excluding

dependencies within the same archive

-cp <path> -classpath <path> Specify where to find class files

-p <pkgname> -package <pkgname> Finds dependences in the given package

(may be given multiple times)

-e <regex> -regex <regex> Finds dependences in packages matching pattern

(-p and -e are exclusive)

-include <regex> Restrict analysis to classes matching pattern

This option filters the list of classes to

be analyzed. It can be used together with

-p and -e which apply pattern to the dependences

-P -profile Show profile or the file containing a package

-apionly Restrict analysis to APIs i.e. dependences

from the signature of public and protected

members of public classes including field

type, method parameter types, returned type,

checked exception types etc

-R -recursive Recursively traverse all dependencies

-jdkinternals Finds class-level dependences on JDK internal APIs.

By default, it analyzes all classes on -classpath

and input files unless -include option is specified.

This option cannot be used with -p, -e and -s options.

WARNING: JDK internal APIs may not be accessible in

the next release.

-version Version information

 

Ein Beispiel:

 

$ jdeps "c:\Program Files\Java\jdk1.8.0\lib\ant-javafx.jar"

c:\Program Files\Java\jdk1.8.0\lib\ant-javafx.jar -> c:\Program Files\Java\jdk1.8.0\jre\lib\rt.jar

c:\Program Files\Java\jdk1.8.0\lib\ant-javafx.jar -> not found

com.javafx.main (ant-javafx.jar)

-> java.applet

-> java.awt

-> java.awt.event

-> java.io

-> java.lang

-> java.lang.reflect

-> java.net

-> java.security

-> java.util

-> java.util.jar

-> javax.swing

-> sun.misc JDK internal API (rt.jar)

com.sun.javafx.tools.ant (ant-javafx.jar)

-> java.io

-> java.lang

-> java.security.cert

-> java.util

-> java.util.jar

-> java.util.zip

-> org.apache.tools.ant not found

-> org.apache.tools.ant.taskdefs not found

-> org.apache.tools.ant.types not found

-> org.apache.tools.ant.types.resources not found

-> sun.misc JDK internal API (rt.jar)

com.sun.javafx.tools.packager (ant-javafx.jar)

-> java.io

-> java.lang

-> java.lang.reflect

-> java.math

-> java.net

-> java.nio.file

-> java.security

-> java.security.cert

-> java.text

-> java.util

-> java.util.jar

-> java.util.regex

-> java.util.zip

-> sun.misc JDK internal API (rt.jar)

-> sun.security.pkcs JDK internal API (rt.jar)

-> sun.security.timestamp JDK internal API (rt.jar)

-> sun.security.util JDK internal API (rt.jar)

-> sun.security.x509 JDK internal API (rt.jar)

com.sun.javafx.tools.packager.bundlers (ant-javafx.jar)

-> java.io

…

Programmierparadigmen: imperativ oder deklarativ

In irgendeiner Weise muss ein Entwickler sein Problem in Programmform beschreiben, damit der Computer es letztendlich ausführen kann. Hier gibt es verschiedene Beschreibungsformen, die wir Programmierparadigmen nennen. Bisher haben wir uns immer mit der imperativen Programmierung beschäftigt, bei der Anweisungen im  Mittelpunkt stehen. Wir haben im Deutschen den Imperativ, also die Befehlsform, die sehr gut mit dem Programmierstil vergleichbar ist, denn es handelt sich in beiden Fällen um Anweisungen der Art „tue dies, tue das“. Diese „Befehle“ mit Variablen, Fallunterscheidungen, Sprüngen beschreiben das Programm und den Lösungsweg.

Zwar ist imperative Programmierung die technisch älteste, aber nicht die einzige Form Programme zu beschreiben; es gibt daneben die deklarative Programmierung, die nicht das „wie“ zur Problemlösung beschreibt, sondern das „was“, also was eigentlich gefordert ist ohne sich in genauen Abläufen zu verstricken. Auf den ersten Blick klingt das abstrakt, aber für jeden, der schon einmal

• einen Selektion wie *.html auf der Kommandozeile/im Explorer-Suchefeld getätigt,
• eine Datenbankanfrage mit SQL geschrieben,
• eine XML-Selektion mit XQuery genutzt,
• ein Build-Skript mit Ant oder make formuliert,
• eine XML-Transformation mit XSLT beschrieben hat

wird das Prinzip kennen.

Bleiben wir kurz bei SQL, um einen Punkt deutlich zu machen. Natürlich ist im Endeffekt die Abarbeitung der Tabellen und Auswertungen der Ergebnisse von der CPU rein imperativ, doch es geht um die Programmbeschreibung auf einem höheren Abstraktionsniveau. Deklarative Programme sind üblicherweise wesentlicher kürzer und damit kommen weitere Vorteile wie leichtere Erweiterbarkeit, Verständlichkeit ins Spiel. Da deklarative Programme oftmals einen mathematischen Hintergrund haben, lassen sich die Beschreibungen leichter formal in ihrer Korrektheit beweisen.

Deklarative Programmierung ist ein Programmierstil, und eine deklarative Beschreibung braucht eine Art „Ablaufumgebung“, denn SQL kann zum Beispiel keine CPU direkt ausführen. Aber statt nur spezielle Anwendungsfälle wie Datenbank- oder XML-Abfragen zu behandeln, können auch typische Algorithmen deklarativ formuliert werden, und zwar mit funktionaler Programmierung. Damit sind imperative Programme und funktionale Programme gleich mächtig in ihren Möglichkeiten.

Funktionale Programmierung und funktionale Programmiersprachen

Bei der funktionalen Programmierung stehen Funktionen im Mittelpunkt und ein im Idealfall zustandsloses Verhalten, in dem viel mit Rekursion gearbeitet wird. Ein typisches Beispiel ist die Berechung der Fakultät. Es ist n! = 1 · 2 · 3 · … · n, und mit Schleifen und Variablen, dem imperativen Weg, sieht sie so aus:

public static int factorial( int n ) {
  int result = 1;
  for ( int i = 1; i <= n; i++ )
    result *= i;
  return result;
}

Deutlich sind die vielen Zuweisungen und die Fallunterscheidung durch die Schleife abzulesen; die typischen Indikatoren für imperative Programme. Der Schleifenzähler erhöht sich, damit kommt Zustand in das Programm, denn der aktuelle Index muss ja irgendwo im Speicher gehalten werden. Bei der rekursiven Variante ist das ganz anders, hier gibt es keine Zuweisungen im Programm und die Schreibweise erinnert an die mathematische Definition:

public static int factorial( int n ) {
  return n == 0 ? 1 : n * factorial( n - 1 );
}

Mit der funktionalen Programmierung haben wir eine echte Alternative zur imperativen Programmierung. Die Frage ist nur: Mit welcher Programmiersprache lassen sich funktionale Programme schreiben? Im Grunde mit jeder höheren Programmiersprache! Denn funktional zu programmieren ist ja ein Programmierstil, und Java unterstützt funktionale Programmierung, wie wir am Beispiel mit der Fakultät ablesen können. Da das im Prinzip schon alles ist, stellt sich die Frage, warum funktionale Programmierung einen so schweren Stand hat und bei den Entwicklern gefürchtet ist. Das hat mehrere Gründe:

Lesbarkeit. Am Anfang der funktionalen Programmiersprachen steht historisch LISP aus dem Jahr 1958, eine sehr flexible, aber ungewohnt zu lesende Programmiersprache. Unsere Fakultät sieht in LISP so aus:

(defun factorial (n) (if (= n 1) 1 (* n (factorial (- n 1)))))

Die ganzen Klammern machen die Programme nicht einfach lesbar und die Ausdrücke stehen in der Präfix-Notation – n 1 statt der üblichen Infix-Notation n – 1. Bei anderen funktionalen Programmiersprachen ist es anders, dennoch führt das zu einem gewissen Vorurteil, dass alle funktionalen Programmiersprachen schlecht lesbar sind.

Performance und Speicherverbrauch. Ohne clevere Optimierungen von Seiten des Compilers und der Laufzeitumgebung führen insbesondere rekursive Aufrufe zu prall gefüllten Stacks und schlechter Laufzeit.

Rein funktional. Es gibt funktionale Programmiersprachen, die als „rein“ oder „pur“ bezeichnet werden und keine Zustandsänderungen erlauben. Die Entwicklung von Ein-/Ausgabeoperationen oder simplen Zufallszahlen ist ein großer Akt, der für normale Entwickler nicht mehr nachvollziehbar ist. Die Konzepte sind kompliziert, doch zum Glück sind die meisten funktionalen Sprachen nicht so rein und erlauben Zustandsänderungen, nur Programmierer versuchen genau diese Zustandänderungen zu vermeiden, um sich nicht die Nachteile damit einzuhandeln.

Funktional mit Java. Wenn es darum geht nur mit Funktionen zu arbeiten, kommen Entwickler schnell zu einem Punkt, an dem Funktionen andere Funktionen als Argumente übergeben oder Funktionen zurückgeben. So etwas lässt sich in Java in der traditionellen Syntax nur sehr umständlich schreiben. Dies führt dazu, dass alles so unlesbar wird, dass der ganze Vorteil der kompakten deklarativen Schreibweise verloren geht.

Aus heutiger Sicht stellt sich eine Kombination aus beiden Konzepten als zukunftsweisend dar. Mit der in Java 8 eingeführten Schreibweise der Lambda-Ausdrücke sind funktionale Programme kompakt und relativ gut lesbar und die JVM hat gute Optimierungsmöglichkeiten. Java ermöglicht beide Programmierparadigmen und Entwickler können den Weg wählen, der für eine Problemlösung gerade am Besten ist. Diese Mehrdeutigkeit schafft natürlich auch Probleme, denn immer wenn es mehrere Lösungswege gibt, entstehen Auseinandersetzungen um die Beste der Varianten – und hier kann von Entwickler zu Entwickler eine konträre Meinung herrschen. Funktionale Programmierung hat unbestrittene Vorteile und das wollen wir uns genau anschauen.

Funktionale Programmierung in Java am Beispiel vom Comparator

Funktionale Programmierung hat auch daher etwas akademisches, weil in den Köpfen der Entwickler oftmals dieses Programmierparadigma nur mit mathematischen Funktionen in Verbindung gebracht wird. Und die wenigsten werden tatsächlich Fakultät oder Fibonacci-Zahlen in Programmen benötigen und daher schnell funktionale Programmierung beiseite legen. Doch diese Vorurteile sind unbegründet, und es ist hilfreich, funktionale Programmierung gedanklich von der Mathematik zu lösen, denn die allermeisten Programme haben nichts mit mathematischen Funktionen im eigentlichen Sinne zu tun, wohl aber viel stärker mit formal beschriebenen Methoden.

Betrachten wir erneut unser Beispiel aus der Einleitung, die Sortierung von Strings, diesmal aus der Sicht eines funktionalen Programmierers. Ein Comparator ist eine einfache „Funktion“, mit zwei Parametern und einer Rückgabe. Diese „Funktion“ (realisiert als Methode) wiederum wird an die sort(…)-Methode übergeben. Alles das ist funktionale Programmierung, denn wir programmieren Funktionen und übergeben sie. Drei Beispiele (Generics ausgelassen):

Code	Bedeutung
Comparator c = (c1, c2) -> …	Implementiert eine Funktion über Lambda-Ausdruck
Arrays.sort(T[] a, Comparator c)	Nimmt eine Funktion als Argument an
Collections.reverseOrder(Comparator cmp)	Nimmt eine Funktion an und liefert auch eine zurück

Beispiele für Funktionen in der Übergabe und als Rückgabe

Funktionen selbst können in Java nicht übergeben werden, also helfen sich Java-Entwickler mit der Möglichkeit, die Funktionalität in eine Methode zu setzen, sodass die Funktion zum Objekt mit einer Methode wird, was die Logik realisiert. Lambda-Ausdrücke bzw. Methoden/Konstruktor-Referenzen geben eine kompakte Syntax ohne den Ballast, extra eine Klasse mit einer Methoden schreiben zu müssen.

Der Typ Comparator ist eine funktionale Schnittstelle und steht für eine besondere Funktion mit zwei Parametern gleichen Typs und einer Ganzzahl-Rückgabe. Es gibt weitere funktionale Schnittstellen, die etwas flexibler sind als Comparator, in der Weise, dass etwa die Rückgabe statt int auch double oder etwas anderes sein können.

Lambda-Ausdrücke als Funktionen sehen

Wir haben gesehen, dass sich Lambda-Ausdrücke in einer Syntax formulieren lassen, die folgende allgemeine Form hat:

‚(‚ LambdaParameter ‚)‘ ‚->‘ ‚{‚ Anweisungen ‚}‘

Der Pfeil macht gut deutlich, dass wir es bei Lambda-Ausdrücken mit Funktionen zu tun haben, die etwas abbilden. Im Fall vom Comparator ist es eine Abbildung von zwei Strings auf eine Ganzzahl; in einer etwas mathematischeren Notation gepackt: (String, String) → int.

Beispiel Methoden gibt es mit und ohne Rückgabe und mit und ohne Parameter. Genauso ist das mit  Lambda-Ausdrücken. Ein paar Beispiele in Java-Code mit ihren Abbildungen.

Lambda-Ausdruck	Abbildung
(int a, int b) -> a + b	(int, int) → int
(int a) -> Math.abs( a )	(int) → int
(String s) -> s.isEmpty()	(String) → boolean
(Collection c) -> c.size()	(Collection) → int
() -> Math.random()	() → double
(String s) -> { System.out.print( s ); }	(String) → void
() -> {}	() → void

Lambda-Ausdrücke und was sie als Funktionen abbilden

Begriff: Funktion vs. Methode. Die Java Sprachdefinition kennt den Begriff „Funktion“ nicht, sondern spricht nur von Methoden. Methoden hängen immer an Klassen und das heißt, dass Methoden immer an einem Kontext hängen. Das ist zentral bei der Objektorientierung, da Methoden auf Attribute lesend und schreibend zugreifen können. Lambda-Ausdrücke wiederum realisieren Funktion, die erst einmal ihre Arbeitswerte rein aus den Parametern beziehen, sie hängen nicht an Klassen und Objekten. Der Gedanke bei funktionalen Programmiersprachen ist der, ohne Zustände auszukommen, also Funktionen so clever anzuwenden, dass sie ein Ergebnis liefern. Funktionen geben für eine spezifische Parameterkombination immer dasselbe Ergebnis zurück, unabhängig vom Zustand des umgebenden Gesamtprogramms.

Als die Entwickler der Sprache Java die Lambda-Ausdrücke diskutierten, stand auch die Frage im Raum, ob abstrakte Klassen, die nur über eine abstrakte Methode verfügen, ebenfalls für Lambda-Ausdrücke genutzt werden können.[1] Sie entschieden sich dagegen, unter anderem deswegen, weil bei der Implementierung von Schnittstellen die JVM weitreichende Optimierungen vornehmen kann. Und bei Klassen wird das schwierig. Das liegt auch daran, dass ein Konstruktor umfangreiche Initialisierungen mit Seiteneffekten vornimmt (die Konstruktoren aller Oberklassen nicht zu vergessen), sowie Ausnahmen auslösen könnte. Gewünscht ist aber nur die Ausführung einer Implementierung der funktionalen Schnittstelle und kein anderer Code.

Es gibt nun im JDK einige abstrakte Klassen, die genau eine abstrakte Methode vorschreiben, etwa java.util.TimerTask. Solche Klassen können nicht über einen Lambda-Ausdruck realisiert werden; hier müssen Entwickler weiterhin zu Klassenimplementierungen greifen, und die kürzeste Lösung ist eine innere anonyme Klasse. Eigene Hilfsklassen können natürlich den Code etwas abkürzen, aber eben nur mit Hilfe einer eigenen Implementierung.

Wer abstrakte Methoden mit Lambda-Ausdrücken implementieren möchte, kann mit Hilfsklassen arbeiten. Denn wenn eine Hilfsklasse funktionale Schnittstellen einsetzt, so können Lambda-Ausdrücke wieder ins Spiel kommen, in dem die Implementierung der abstrakten Methode an den Lambda-Ausdruck weiterleitet. Nehmen wir das Beispiel für TimerTask und gehen zwei unterschiedliche Strategien der Implementierung durch. Mit Delegation sieht das so aus:

import java.util.*;

class TimerTaskLambda {

  public static TimerTask createTimerTask( Runnable runnable ) {
    return new TimerTask() {
        @Override public void run() { runnable.run(); }
    };
  }
 
  public static void main( String[] args ) {
    new Timer().schedule( createTimerTask( () -> System.out.println("Hi") ), 500 );
  }
}

Mit Vererbung erhalten wir:

public class LambdaTimerTask extends TimerTask {
  private final Runnable runnable;
    public LambdaTimerTask( Runnable runnable ) {
    this.runnable = runnable;
  }
   
  @Override public void run() { runnable.run(); }
}

Der Aufruf erfolgt dann statt createTimerTask(…) mit dem Konstruktor:

new Timer().schedule( new LambdaTimerTask( () -> System.out.println("Hi") ), 500 );