IntelliJ IDEA kompiliert über Maven

Normalerweise kompiliert die Java-IDE IntelliJ IDEA den Quelltext sobald, der Build-Vorgang gestartet wird. Allerdings kann es vorkommen das stattdessen jedes Mal der Kompiliervorgang über Maven angestoßen wird. Verantwortlich hierfür ist eine Einstellung der IDE.

Nachdem die Option deaktiviert wurde, kompilierte die IDE den Quellcode wieder

Zu finden ist diese Einstellung im Einstellungsdialog unter dem Punkt Build, Execution, Deployment -> Build Tools -> Maven- Runner. Dort existiert der Punkt Delegate IDE build/run actions to Maven. Wird dieser Punkt deaktiviert, ist die IDE wieder für die Kompilierung und den Build-Prozess verantwortlich.

Schriftgröße unter IntelliJ IDEA dynamisch anpassen

In der IDE IntelliJ IDEA von JetBrains kann die Schriftgröße für den Editor, wie gewünscht eingestellt werden. In manchen Fällen soll die Schriftgröße allerdings dynamisch eingestellt werden. Ein solcher Fall ist z.B. der Präsentationsmodus. In diesem Modus wird der Editor im Vollbild-Modus dargestellt und dient so der Präsentation des Quellcodes.

Das Einstellungsfenster von IntelliJ IDEA

Sollen hier die Zeilen, je nach Anforderung, nun größer oder kleiner dargestellt werden, kann dies über eine Option in den Einstellungen erreicht werden. In den Einstellungen findet sich unter Editor -> General der Punkt Change font size (Zoom) with Command+Mouse Wheel. Auf anderen Betriebssystemen wird statt der Command-Taste die Ctrl-Taste genutzt. Wird diese Option aktiviert, kann die Größe der Schriftart, in Verbindung mit der Command-Taste, dynamisch über das Mausrad eingestellt werden.

ExecutorService unter Java nutzen

Wenn unter Java die Ausführung von Quelltext parallelisiert werden soll, so können hierfür Threads genutzt werden:

Thread thread = new Thread(new TestRunnable());
thread.start();

In diesem Beispiel wird für eine auszuführende Aufgabe ein Thread erstellt und dieser anschließend gestartet. Nun kann es Fälle geben, in welchem mehrere Threads die gleiche Aufgabe ausführen sollen, allerdings nicht unbedingt die entsprechende Anzahl von Threads angelegt werden soll. Für eine solche Aufgabe eignet sich ein ExecutorService. Im ersten Schritt sollte ein Runnable definiert werden. In diesem Interface wird eine run-Methode definiert, die den auszuführenden Quellcode enthält:

public static class TestRunnable implements Runnable {

    @Override
    public void run() {
        // Do something
    }
}

Nun kann der ExecutorService angelegt werden und mit einem Threadpool ausgestattet werden. Anschließend werden die neuen Instanzen des Runnable, mittels der execute-Methode, an den ExecutorService übergeben.

// Executor service
ExecutorService executorService = Executors.newCachedThreadPool();

// Add jobs to executor service
for (int i = 0; i < 100; i++) {
    executorService.execute(new TestRunnable());
}

// Shutdown executor service
executorService.shutdown();
executorService.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS);

Damit würden die Aufgaben abgearbeitet. Allerdings würde der ExecutorService nun bis zu einem Timeout noch bestehen bleiben. Stattdessen wird er im Beispiel kontrolliert heruntergefahren. Nach der Ausführung der shutdown-Methode nimmt der ExecutorService keine neuen Aufträge mehr an; bestehende Aufträge werden allerdings noch abgearbeitet. Über die Methode awaitTermination wird sichergestellt das der Service wartet, bis alle Aufgaben abgearbeitet sind. Bei der Methode wird ein Timeout angegeben, nach welchem der Service zwangsweise abgeschaltet wird. Damit werden die Aufgaben Stück für Stück abgearbeitet, ohne entsprechende viele Threads zu öffnen. Stattdessen werden Threads aus dem Threadpool wiederverwendet.

Java-Bibliothek für HBCI

Wer elektronisch auf Konten zugreifen möchte, kann hierfür das Homebanking Computer Interface, kurz HBCI, bzw. FinTS nutzen. Soll die Nutzung der Schnittstelle in einer Anwendung passieren, wird eine Bibliothek zur Nutzung des Protokolls benötigt. Für die Entwicklung unter Java bietet sich hierbei die Bibliothek hbci4java an.

hbci4java auf GitHub

hbci4java unterstützt die neuen, durch die Richtlinie PSD2 geforderten, Mechanismen, sodass der Zugriff auf Konten auch nach der Umsetzung der Richtlinie möglich ist. Der Quelltext der Bibliothek ist auf GitHub zu finden. Lizenziert ist die Bibliothek unter der LGPL in Version 2.1. Damit ist die Bibliothek freie Software.

Maps mittels GSON deserialisieren

GSON ist eine von Google entwickelte Java-Bibliothek, welche ursprünglich für den internen Gebrauch bei Google gedacht war. Mit dieser ist, neben vielen anderen Dingen, unter anderem die Serialisierung von Java-Objekten in JSON möglich. Gegeben sei für ein kleines Beispiel die Klasse FooObject:

public class FooObject {

    private int id;
    private String key;
    private String value;

    public FooObject(int id, String key, String value) {
        this.id = id;
        this.key = key;
        this.value = value;
    }

    public int getId() {
        return id;
    }

    public String getKey() {
        return key;
    }

    public String getValue() {
        return value;
    }
}

Die Klasse besteht aus drei internen Variablen, welche eine Id, einen Key und einen Value halten. Daneben existieren ein Konstruktor und drei Getter-Methoden für die Rückgabe der internen Variablen. Mithilfe von GSON kann eine Instanz der Klasse einfach zu JSON serialisiert werden:

Gson gson = new Gson();
FooObject fooObject = new FooObject(1, "keyA", "valueA");
String jsonFooObject = gson.toJson(fooObject);

Heraus kommt bei dieser Serialisierung folgendes JSON-Objekt:

{
   "id":1,
   "key":"keyA",
   "value":"valueA"
}

Auch die Deserialisierung des Objektes mittels GSON ist kein Problem:

fooObject = gson.fromJson(jsonFooObject, FooObject.class);

Interessanter und komplizierter wird es, wenn Maps mittels GSON serialisiert werden sollen:

Map values = new HashMap<>();
values.put("A", new FooObject(1, "keyA", "valueA"));
values.put("B", new FooObject(2, "keyB", "valueB"));
values.put("C", new FooObject(3, "keyC", "valueC"));

Die Serialisierung gestaltet sich noch einfach:

String json = gson.toJson(values);

Bei der Deserialisierung mittels:

Map map = gson.fromJson(json, Map.class);

erhält der Nutzer allerdings eine LinkedTreeMap. Auf die Werte der Map kann durchaus zugegriffen werden:

String value = map.get("A").get("key");

Allerdings schlägt die Umwandlung in ein Objekt vom Typ FooObject fehl:

FooObject fooObjectB = map.get("A");

Stattdessen erhält der Nutzer eine ClassCastException:

Exception in thread "main" java.lang.ClassCastException: com.google.gson.internal.LinkedTreeMap cannot be cast to org.example.console.FooObject

Damit der Cast gelingt muss bei der Deserialisierung der Map anders gearbeitet werden:

import com.google.gson.Gson;
import com.google.gson.reflect.TypeToken;

import java.lang.reflect.Type;

...

Type type = new TypeToken>(){}.getType();
Map map = gson.fromJson(json, type);

Damit kann die Map mit dem FooObject normal genutzt werden. Mithilfe des TypeTokens kann ein generischer Typ repräsentiert und somit für die Deserialisierung mittels GSON eingesetzt werden.