seeseekey.net - Invictus Deus Ex Machina

Wenn man Java-Keystore-Dateien bearbeiten möchte, so kann man dies natürlich mit dem im Java SDK mitgelieferten Kommandozeilentool keytool tun. Einfacher ist es mit der grafischen Anwendung KeyStore Explorer zu arbeiten.

KeyStore Explorer

Mit dem KeyStore Explorer können unter anderem Keystore-Dateien bearbeitet, Zertifikate unterschiedlicher Formate geöffnet und analysiert werden. Zu finden ist das Tool unter keystore-explorer.org. Der KeyStore Explorer ist freie Software und unter der GPL in Version 3 lizenziert. Der Quelltext kann über GitHub bezogen werden.

Unter Java ist es möglich mit sogenannten Keystores zu arbeiten. Dabei handelt es sich um Containerdateien in welchen Zertifikate gespeichert werden können. Diese können dann z.B. beim Start eines Tomcat mit übergeben werden. Damit sind die Zertifikate der Java-Applikation bekannt. Möchte man ein solches Zertifikat in einen Keystore importieren, so nutzt man das Tool keytool:

keytool -importcert -file server-ca-web.pem -keystore store.jks -alias "server-ca-web"

Das Tool ist im Java SDK enthalten und wird für die Verwaltung der Keystores genutzt. In diesem Fall wird das Zertifikat server-ca-web.pem in den Keystore store.jks geschrieben.

Wenn man unter IntelliJ IDEA eine Java-Projekt ohne Maven-Unterstützung geladen hat und eine solche benötigt, so kann man diese manuell hinzufügen. Dazu reicht es eine pom.xml Datei dem Projekt hinzuzufügen:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>groupId</groupId>
    <artifactId>TestProject</artifactId>
    <version>1.0-SNAPSHOT</version>

</project>

Einfacher und schneller kann das ganze allerdings mit den Bordmitteln von IntelliJ IDEA gelöst werden.

Die Unterstützung für Maven kann einfach hinzugefügt werden

Die Unterstützung für Maven kann einfach hinzugefügt werden

Dazu muss mit der rechten Maustaste auf das Projekt geklickt werden. Dort wird der Punkt Add Framework support… ausgewählt. Anschließend öffnet sich ein Fenster in dem das gewünschte Framework ausgewählt werden kann. Wählt man hier Maven aus und bestätigt das ganze mit dem OK-Button wird eine pom.xml Datei für das Projekt erzeugt und die IDE erkennt automatisch, das es sich nun um ein Maven-Projekt handelt.

Für das Build-Management-Tool Maven gibt es eine große Anzahl an Plugins mit welchen die Funktionalität von Maven erweitert werden kann. Eines dieses Plugins ist das Maven Enforcer Plugin. Dieses Plugin überprüft ob die Abhängigkeiten zwischen JDK, Bibliotheken und vielem mehr gegeben sind. Ist dies nicht der Fall wird der Kompiliervorgang abgebrochen. Möchte man diese Überprüfung temporär deaktivieren muss die Kommandozeile um den Parameter -Denforcer.fail=false erweitert werden:

mvn clean compile -Denforcer.fail=false

Damit wird die Funktionalität des Enforcer Plugins für den Vorgang deaktiviert. Mittelfristig sollen natürlich die Abhängigkeiten korrigiert werden, so dass der Vorgang mit aktiviertem Plugin erfolgreich durchlaufen werden kann.

Möchte man in einer Android-App einen Alert (in etwa das Äquivalent zu einer MessageBox) erzeugen, so kann der AlertDialog dafür genutzt werden. Dieser stellt dabei einen Builder zur Verfügung mit welchem der Dialog schnell erstellt ist:

AlertDialog dialog = new AlertDialog.Builder(view.getContext()).create();

dialog.setTitle("Warnung");
dialog.setMessage("Bild konnte nicht gesendet werden.");

dialog.setButton(AlertDialog.BUTTON_NEUTRAL, "OK",
    new DialogInterface.OnClickListener() {
        public void onClick(DialogInterface dialog, int which) {
            dialog.dismiss();
        }
    });

dialog.show();

In dem Quelltext wird eine neue Instanz des AlertDialog-Builders mit dem Kontext des aktuellen View angelegt. Mit Hilfe des Builders wird der Titel und die Nachricht des Dialogs festgelegt. Anschließend wird ein OK-Button definiert und dieser mit einer Funktionalität versehen. Danach wird der Dialog mittels der show()-Methode angezeigt.

Vor einigen Tagen begegneten mir einige Dateien, deren Inhalts größtenteils aus der Zeichenfolge EF BF BD EF BF BD EF BF BD (hexadizimal) bestand. Eigentlich sollte in den entsprechenden Dateien binäre Daten enthalten sein. Damit stellte sich nun die Frage: Was war passiert?

EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD

Auf den ersten Blick sah das ganze so aus, als ob ein Großteil der Datei durch Datenmüll ersetzt wurde. Schaut man sich die Zeichenfolge allerdings genauer an, so wird man feststellen das sich die Folge EF BF BD immer und immer wieder wiederholt. Bei dieser Zeichenfolge handelt es sich um die hexadezimale Schreibweise des Unicode-Zeichens für den Replacement Character welcher meist durch eine Raute mit einem Fragezeichen (�) dargestellt wird.

Eindeutiger wäre das Problem gewesen, wenn die erzeugten Dateien mit der Zeichenfolge EF BB BF begonnen hätte. Dabei handelt es sich um das Byte Order Mark für eine UTF-8 kodierte Datei. Damit wäre gleich klar geworden, das die enthaltenen Daten nicht zu einer Datei mit binären Inhalten passen. Doch wie sind diese Dateien nun entstanden? Der Ursprung der Dateien ist in einer Java-Applikation zu finden, welche diese Dateien erstellt. Diese kopierte die Daten von A nach B, im Quelltext (man ignoriere das fehlende try with resources) könnte das so ausgesehen haben:

FileInputStream fileInputStream  = new FileInputStream("binary.dat");
FileWriter fileWriter = new FileWriter("binary-copied.dat");

int byteData;

while ((byteData = fileInputStream.read()) != -1) {
    fileWriter.write(byteData);
}

fileInputStream.close();
fileWriter.close();

Hier wird ein FileInputStream geöffnet und dieser Stück für Stück mit einem FileWriter in die Zieldatei geschrieben. Genau an dieser Stelle entsteht das Problem – der FileWriter ist nämlich ein zeichenbasierter Writer, das bedeutet das sämtliche Zeichen, die mit diesem geschrieben werden, kodiert werden. Wenn nun bei dieser Kodierung ein Zeichen gefunden wird, welches nicht im Unicode abgebildet werden kann, so erhält dieses Zeichen den Wert EF BF BD – besagter Replacement Character. Damit ist dann auch erklärt warum die binären Dateien hauptsächlich nur noch aus diesen Zeichen bestanden. Die echten Daten wurden beim Kopiervorgang größtenteils schlicht und ergreifend in den Replacement Character konvertiert, da sich für diese Daten keine Entsprechung im Unicode fand.

Den freien Suchserver Elasticsearch kann man, wie das Wort Suchserver es dezent andeutet, als Server betreiben. Allerdings ist es manchmal nicht gewünscht einen dedizierter Server zu betreiben. In einem solchen Fall kann man den Elasticsearch-Server in eine Java-Applikation einbetten. Der sicherlich häufigste Fall für eine solche Einbettung ist dabei die Nutzung zu Testzwecken (z.B. Unit-Tests zum Test der Suchergebnisse). Im ersten Schritt sollte in das Java-Projekt die entsprechende Abhängigkeit zum Projekt hinzugefügt werden. In diesem Beispiel wird dabei auf einem auf Maven basierenden Projekt ausgegangen – in diesem muss die pom.xml entsprechend erweitert werden:

<dependency>
    <groupId>org.elasticsearch</groupId>
    <artifactId>elasticsearch</artifactId>
    <version>2.3.4</version>
</dependency>

Damit wurde Elasticsearch dem Projekt hinzugefügt. Nun muss der eigentliche Server im Java-Projekt gestartet werden. Dafür werden nur wenige Zeilen Quellcode benötigt:

Settings.Builder elasticsearchSettings = Settings.settingsBuilder()
    .put("http.enabled", "true")
    .put("path.data", "data")
    .put("path.home", "home");

Node node = nodeBuilder()
    .local(true)
    .settings(elasticsearchSettings.build())
    .node();

In diesem Beispiel werden im ersten Schritt die Einstellungen für Elasticsearch definiert. Dabei wird unter anderem der HTTP-Modus aktiviert. Wenn dieser deaktiviert ist, ist die Kommunikation per HTTP nicht mehr möglich. Stattdessen kann dann nur noch die Kommunikation über das Transport-Interface genutzt werden. Dieses Interface wird im Normalfall für die interne Kommunikationen zwischen einzelnen Elasticsearch-Clustern genutzt – allerdings ist eine Nutzung mit dem Elasticsearch-Java-Client ebenfalls möglich. Mit dem aktivierten Modus, ist die Entwicklung einfacher (z.B. für den Einsatz von Analyse-Tools) und die Konfiguration näher an der Praxis. Standardmäßig horcht der Elasticsearch-Server dabei auf dem Port 9200 – in diesem Beispiel wäre er über die URL:

http://localhost:9200

erreichbar. Nachdem die Einstellungen angelegt wurden, werden diese dem NodeBuilder übergeben, welcher schlussendlich den Elasticsearch-Server hochfährt. Nachdem dieser hochgefahren wurde, kann die Nutzung des selben beginnen.

Ein REST-API von Hand entwickelt, benötigt eine Dokumentation, ein entsprechenden Server und eventuell einige Clients als Referenz. Einfacher wird es mit einem Framework wie Swagger. Unter Zuhilfenahme der Beschreibungssprache YAML können mit Hilfe des Frameworks REST-APIs, Dokumentation, Server und Clients generiert werden.

Der Swagger Editor

Der Swagger Editor

Doch Swagger versteht sich nicht nur als Framework, sondern auch als Spezifikation. Begonnen wurde mit der Entwicklung bereits im 2010; die Swagger Specification trägt seit Anfang Januar 2012 offiziell den Namen OpenAPI Specification und beschreibt eine maschinenlesbare Interfacedefinitionen einer REST-API. Ähnliches wurde unter anderem schon mit WSDL und WADL versucht – alles Konzepte bzw. Beschreibungsprachen welche an ihren eigenen Limitationen gescheitert sind und wenn überhaupt nur noch sporadisch genutzt werden.

Betreut und weiterentwickelt wird die Spezifikation nun von der Open API Initiative, zu der namenhafte Firmen wie Google, PayPal, IBM, Atlassian und Microsoft gehören. Die Spezifikation als solche ist freie Software und auf GitHub zu finden. Sie ist unter der Apache Lizenz lizenziert. Aktuell ist die Spezifikation in der Version 2.0 veröffentlicht.

Auf der offiziellen Webseite von Swagger findet sich ein Editor, mit welchem APIs definiert werden können und anschließend exportiert werden können. Der Editor kann dabei Server unter anderem in den Sprachen bzw. für die Framworks Haskel, Jax-RS, Node.js, Python, Rails und PHP erzeugen. Bei den Clients ist die Auswahl noch größer. Diese können in C#, HTML, Dart, Go, Groovy, Java, Javascript, Objective C, Perl, PHP, Ruby, Scala, Swift und vielen weiteren Sprachen erzeugt werden.

Neben dem Editor kann für die Erzeugung von Clients auch der Swagger Codegen genutzt werden. Dabei handelt es sich um eine Java-Anwendung um die Clients lokal auf dem eigenen Rechner zu erzeugen. Der Editor und viele weitere Tools rund um Swagger sind ebenfalls auf GitHub zu finden. – auch diese sind freie Software, welche unter der Apache Lizenz stehen.

Statische Codeanalyse ist eine feine Sache. Sie weißt auf Fehler und Probleme schon zur Entwicklungszeit hin. Dafür gibt es unter anderem Systeme wie SonarQube. Wem ein solchen System zu groß ist, der kann SonarLint nutzen, welches statische Codeanalyse lokal in der gewünschten IDE liefert.

sonarlint.org/intellij/

sonarlint.org/intellij/

Für IntelliJ IDEA findet man die passende Version dabei unter sonarlint.org/intellij/. Daneben gibt es auch Versionen für Eclipse und Visual Studio. SonarLint wird dabei mit einem vorgefertigtem Regelsatz geliefert und kann nach der Installation gleich genutzt werden. SonarLint ist unter der GPL in Version 3 (bzw. der LGPL) lizenziert und damit freie Software.

Unter Java ist es mögliche alle Klassen eines Packages als ganzes zu importieren. Im Quelltext sieht das dann so aus:

import com.example.project.engine.*

Viele IDEs wie auch IntelliJ IDEA fügen diese Wildcard-Imports zu einem Projekt, wenn mehr als eine Klasse (abhängig von den Einstellungen) aus dem Namespace genutzt wird. Unter Umständen ist dieses Verhalten allerdings nicht gewünscht. Möchte man das Verhalten unter IntelliJ IDEA deaktivieren, muss dies in den Einstellungen geschehen.

Die entsprechende Seite in den Einstellungen

Die entsprechende Seite in den Einstellungen

Dort gibt es unter Editor -> Code Style -> Java -> Imports die Einstellung ab wie vielen Klassen ein Wildcard-Import genutzt werden soll. Stellt man hier die Zahl entsprechend hoch ein, so werden keine Wildcards-Imports mehr genutzt.