Deeplearning4j

Bibliotheken für die Entwicklung von Deep Learning-Anwendungen bzw. zur Nutzung von maschinellem Lernen, sind meistens für Python verfügbar. Entsprechende Bibliotheken für Java sind dagegen spärlich gesät. Eine dieser Bibliotheken für Java ist Deeplearning4j. Neben der klassischen Kost, wie der Unterstützung unterschiedlicher neuronaler Netze, verfügt Deeplearning4j über eine Schnittstelle zu Python, mit deren Hilfe die entsprechenden Bibliotheken aus der Python-Welt angebunden werden können.

deeplearning4j.org

Der Quelltext der Bibliothek ist auf GitHub zu finden. Lizenziert ist die Bibliothek unter der Apache License in der Version 2 und damit freie Software. Die offizielle Projektseite kann unter deeplearning4j.org besucht werden.

Exception-Hierarchie unter Java

Java nutzt, wie viele andere Sprachen, Exceptions zur Fehlersignalisierung und Fehlerbehandlung. Folgender Code würde hierbei dem Anschein nach alle Exceptions fangen:

try {
  // Do something wrong
} catch(Exception e) {
  // Gotta Catch 'Em All
}

An dieser Stelle trügt der Schein nicht. Allerdings werden nur einige Fehlerklassen gefangen, nämlich nur solche vom Typ Exception. Die Hierarchie der Fehlerklassen ist unter Java ein wenig differenzierter. In Java erbt jede Klasse implizit von der Klasse Object und so erbt auch die Klasse Throwable von dieser und implementiert das Interface Serializable.

Die Hierarchie der Klassen, welche für Fehlersignalisierung zuständig sind

Von der Klasse Throwable wiederum erben die Klassen Error und Exception. Fehler vom Typ Error stellen laut Definition immer Fehler innerhalb der JVM da, während Exceptions gewöhnliche Fehler des Programmes bzw. des Entwicklers sind. Sollen nun alle Fehlerklassen gefangen werden, so müsste der Quellcode wie folgt aussehen:

try {
  // Do something wrong
} catch(Throwable t) {
  // Gotta Catch 'Em All
}

Das Beispiel sollte nur als solches betrachtet werden, da es sich immer empfiehlt spezielle Fehler zu fangen und zu behandeln. Ein solch allgemeiner Fehlerhandler eignet sich nur für Spezialfälle wie z.B. das Logging nicht behandelter Fehler. Die Hierarchie verästelt sich anschließend noch weiter, so erben unterschiedlichste Klassen von der Klasse Error. Bei der Klasse Exception sieht dies ähnlich aus, allerdings existiert hier eine Besonderheit, die Klasse RuntimeException. Normalerweise muss eine Methode Exceptions, die sie wirft im Methodenkopf bekannt geben, wenn sie nicht in der Methode behandelt werden:

public static void example() throws Exception {
  throw new Exception();
}

Bei Klassen die von der Klasse RuntimeException erben muss diese Bekanntmachung im Methodenkopf nicht erfolgen. Sie werden trotzdem nach oben durchgereicht bis sie gefangen werden oder sich das Programm beendet, wenn die Behandlung der Exception nicht durchgeführt wurde.

Hello, World!

Wer mit einer neuen Programmiersprache anfängt, der schreibt in den meisten Fällen ein sogenanntes Hello, World!-Programm. Ziel eines solchen Programmes ist es einfach folgende Zeile auszugeben:

Hello, World!

Nun sehen diese Programme in den gebräuchlichen Sprachen meist recht ähnlich aus, aber es geht durchaus auch anders, wie die The Hello World Collection zeigt.

helloworldcollection.de

Begonnen wurde diese Kollektion 1994 und ist mittlerweile wahrscheinlich das Verzeichnis mit den meisten Hello, World!-Programmen auf der Welt. Im Moment umfasst die Kollektion 592 dieser Programme in unterschiedlichen Sprachen. Zu finden ist die Seite unter helloworldcollection.de.

Probleme bei der Testausführung unter IntelliJ IDEA

Bei der Ausführung bestimmer Testfälle mittels JUnit kann es unter IntelliJ IDEA zu folgender Fehlermeldung kommen:

Error running ‚ConverterTest‘: Command line is too long. Shorten command line for ConverterTestor also for JUnit default configuration.

Hintergrund für diesen Fehler ist das Problem, das die Kommandozeile zur Ausführung des Tests zu lang wird. Dies kann durch Beschränkungen des Betriebssystems passiere. IntelliJ IDEA versucht nun die Kommandozeile zu kürzen, um eine Ausführung zu ermöglichen.

Über die Konfiguration kann der Fehler behoben werden

Behoben werden kann das Problem über die Konfiguration des Testes. Dazu sollte der Run/Debug Configuration-Dialog geöffnet werden. Dort sollte im Tab Configuration unter dem Punkt Shorten command line der Punkt JAR manifest ausgewählt werden. Anschließend sollte der Test ohne Probleme durchgeführt werden können.

Terminal-Bibliothek für Java

Für ein kleines Projekt wollte ich eine Visualisierung in der Konsole bzw. im Terminal unter Java realisieren. Das Problem ist das bei der Visualisierung, je nach verwendetem Terminal, bestimmte Operationen nicht verfügbar sind. Dies fängt schon beim Löschen des Bildschirmes an. Je nach Art des Terminals bzw. Betriebssystem kann es hier unterschiedliche Ansätze geben, um dieses Problem zu lösen. Abhilfe bei diesen Problemen schafft die Bibliothek Lanterna.

Lanterna in Aktion

Laterna liefert die Möglichkeit Text-Schnittstellen und GUIs zu bauen, unabhängig vom verwendeten Terminal. Damit ähnelt sie der C-Bibliothek ncurses. Die Bibliothek ist in der Lage festzustellen, auf welcher Art Terminal sie läuft und kann somit die Ausgabe entsprechend anpassen. So werden z.B. Unix-Steuercodes genutzt, wenn das Terminal diese unterstützt. Nach der Einbindung per Maven:

<dependency>
    <groupId>com.googlecode.lanterna</groupId>
    <artifactId>lanterna</artifactId>
    <version>3.0.1</version>
</dependency>

kann die Nutzung der Bibliothek beginnen. Im ersten Schritt sollte eine Instanz der Klasse Terminal angelegt werden:

Terminal terminal = new DefaultTerminalFactory().createTerminal();

Dies übernimmt die DefaultTerminalFactory. Sie sorgt dafür, dass das passende Terminal ausgewählt wird. Nun können Zeichen auf das Terminal geschrieben werden:

terminal.clearScreen();
terminal.putCharacter('a');

Hier wird das Terminal erst bereinigt und anschließend das Zeichen a auf das Terminal geschrieben. Neben der direkten Arbeit mit dem Terminal, liefert Lanterna eine Abstraktionsschicht namens Screen mit, mit welcher das Terminal wie ein pixelbasiertes Gerät angesprochen werden kann. Neben der Ausgabe beherrscht die Bibliothek die Eingabe. Mittels:

KeyStroke keyStroke = terminal.pollInput();

wird die aktuelle gedrückte Taste abgefragt. Diese Methode arbeitet nicht-blockierend. Für den Fall das eine blockierende Methode benötigt wird, eignet sich die Methode:

KeyStroke keyStroke = terminal.readInput();

Damit lassen sich mithilfe der Bibliothek komplexe Anwendungen auf dem Terminal umsetzen. Wenn die Anwendung beendet werden soll, muss das Terminal mittels:

terminal.close();

geschlossen werden. Der Quelltext der Bibliothek ist auf GitHub zu finden. Er ist unter der LGPL lizenziert und damit freie Software.