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.

Standardeditor für die Z shell einstellen

In der neuen macOS-Version Catalina wurde die Standardshell seitens Apple gewechselt. Statt der Bourne-again shell, kurz Bash, wird nun die Z shell, kurz zsh, genutzt. Grund hierfür ist, dass die Lizenz, welche von Bash genutzt wird, aus Sicht von Apple zu restriktiv ist. Aus diesem Grund wurde zur Z shell gewechselt. In dieser ist, unter macOS, standardmäßig vi als Editor eingestellt. Soll der Standardeditor geändert werden so muss die entsprechen Konfigurationsdatei der Z shell im Terminal bearbeitet werden:

nano ~/.zshrc

In diese Datei muss nun folgende Zeile eingetragen werden:

export EDITOR=nano

Damit wird, nachdem die Konfiguration gespeichert wurde und die Shell neu geöffnet wurde, nano als Standardeditor genutzt.

Convert2Markdown

Anfang des Jahres schrieb ich ein Tool, mit welchem WordPress-Dumps in Markdown umgewandelt werden können. In den letzten Tagen habe ich das Tool erweitert, sodass es nun auch mit MediaWiki-Dumps umgehen kann und diese ebenfalls nutzen und in Markdown konvertieren kann:

java -jar Convert2Markdown.jar -i mediawiki-dump.xml

Im Zuge dessen wurde das Tool umbenannt, statt WordPress2Markdown trägt es nun den Namen Convert2Markdown. Die Erkennung welche Art Dump genutzt wird, wird von Convert2Markdown automatisch vorgenommen und der entsprechende Konverter genutzt. Daneben wurden weitere Kleinigkeiten überarbeitet; so ist es nun unter anderem möglich Artikel nach Autorenschaft zu filtern. Zu finden ist das Werkzeug auf GitHub. Dort kann auch das Release bezogen werden. Convert2Markdown ist unter der GPL3 lizenziert und damit freie Software.

Bibliothek zum Einlesen von MediaWiki-Dump-Dateien

Für ein Projekt war ich auf der Suche nach einer Java-Bibliothek um die Dumps einer MediaWiki-Installation auszuwerten. Fündig geworden bin ich bei der Bibliothek WikiXMLJ, welche allerdings mittlerweile einige Jahre auf dem Buckel hat. Auf Basis dieser Bibliothek habe ich die Bibliothek mediawikixml erstellt. Um die Bibliothek zu nutzen, muss im ersten Schritt eine neue Paketquelle in der pom.xml definiert werden.

<repositories>
 <repository>
 	<id>github</id>
 	<url>https://maven.pkg.github.com/seeseekey/mediawikixml</url>
 </repository>
</repositories>

Anschließend kann die Abhängigkeit eingebunden werden:

<dependency>
    <groupId>net.seeseekey</groupId>
    <artifactId>mediawikixml</artifactId>
    <version>1.0.1</version>
</dependency>

Damit kann die Bibliothek zur Auswertung von MediaWiki-Dumps genutzt werden:

WikiXMLParser wikiXMLParser = WikiXMLParserFactory.getParser("dump-current.xml");

try {

    wikiXMLParser.setPageCallback(new PageCallbackHandler() {
        public void process(WikiPage page) {
            System.out.println(page.getId());
            System.out.println(page.getRevisionId());
            System.out.println(page.getTimestamp());
            System.out.println(page.getTitle());
            System.out.println(page.getWikiText());
        }
    });

    wikiXMLParser.parse();
} catch (Exception e) {
    e.printStackTrace();
}

Für jede MediaWiki-Seite wird unter anderem die ID, die Revision, der Timestamp, der Titel und der eigentliche Inhalt der Seite geparst. Die Bibliothek setzt mindestens Java 8 voraus. Zu finden ist das Repository mit der Bibliothek auf GitHub. Die Bibliothek ist unter der Apache License in Version 2 lizenziert und damit freie Software.

GitHub Package Registry für Maven Packages nutzen

Vor einigen Wochen hat GitHub die GitHub Package Registry vorgestellt. Mit dieser ist es möglich fertige Packages direkt beim Projekt auf GitHub zu hosten. Aktuell unterstützt werden, neben Maven-Packages, unter anderem die Paketsysteme von NPM, Ruby, und NuGet. GitHub selbst definiert den Zweck der Registry wie folgt:

GitHub Package Registry allows you to develop your code and host your packages in one place. You can use packages from GitHub Package Registry as a dependency in your source code on GitHub.

Nach einer Registrierung unter github.com/features/package-registry kann das erste Paket für die Package Registry erstellt werden. Dazu muss im entsprechenden Java-Projekt in der pom.xml folgender Block hinzugefügt werden:

<!-- Definition for uploading artifact to custom repository -->
<distributionManagement>
    <repository>
        <id>github</id>
        <name>GitHub OWNER Apache Maven Packages</name>
        <url>https://maven.pkg.github.com/OWNER/mediawikixml</url>
    </repository>
</distributionManagement>

Das Wort OWNER muss dabei durch den eigenen GitHub-Nutzernamen ausgetauscht werden. Anschließend müssen die Zugangsdaten für GitHub hinterlegt werden. Dazu wird die Maven settings.xml geöffnet:

nano ~/.m2/settings.xml

Zu der Einstellungsdatei wird nun folgender Block hinzugefügt:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      http://maven.apache.org/xsd/settings-1.0.0.xsd">

  <activeProfiles>
    <activeProfile>github</activeProfile>
  </activeProfiles>

  <profiles>
    <profile>
      <id>github</id>
      <repositories>
        <repository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </repository>
        <repository>
          <id>github</id>
          <name>GitHub OWNER Apache Maven Packages</name>
          <url>https://maven.pkg.github.com/OWNER</url>
        </repository>
      </repositories>
    </profile>
  </profiles>

  <servers>
    <server>
      <id>github</id>
      <username>USERNAME</username>
      <password>TOKEN</password>
    </server>
  </servers>
</settings>

Auch hier muss OWNER wieder durch den eigenen Nutzernamen ersetzt werden. Bei der Konfiguration müssen daneben die Felder USERNAME und TOKEN gefüllt werden. Das Token wird in den Einstellungen von GitHub unter Settings – Developer settings – Personal access tokens erzeugt.

Ein Personal Access Token muss für die Package Registry erzeugt werden

Nachdem das Token erzeugt wurde und die Konfiguration für Maven entsprechend hinterlegt wurde, kann das Package mittels:

mvn deploy

deployed werden und erscheint somit in der Package Registry. Angesehen werden kann das Paket nun mittels der URL:

https://github.com/OWNER/REPOSITORY/packages/

Zur Einbindung des neuen Paketes in einem anderes Projekt muss der pom.xml des anderen Projektes folgender Block hinzugefügt werden:

<!-- External non standard repositories -->
<repositories>
    <repository>
        <id>github</id>
        <url>https://maven.pkg.github.com/OWNER/REPOSITORY</url>
    </repository>
</repositories>

Anschließend kann das neue Paket ganz normal als Dependency hinzugefügt werden:

<dependency>
    <groupId>org.example</groupId>
    <artifactId>libtest</artifactId>
    <version>1.0.1</version>
</dependency>

Damit können schnell Pakete über die GitHub Package Registry bereitgestellt werden.