Klassenname für Logger unter Java automatisch ermitteln

Vor einiger Zeit schrieb ich einen Artikel darüber, wie der Klassenname für einen Logger ermittelt werden kann. Im Endergebnis sah die damalige Lösung, unter Nutzung der Simple Logging Facade for Java kurz SLF4J, wie folgt aus:

Logger log = LoggerFactory.getLogger(new Exception().fillInStackTrace().getStackTrace()[0].getClassName());

Damit wird der gesamte Stacktrace zusammengesammelt und entsprechend der Klassenname extrahiert. Das Problem an dieser Variante ist das der gesamte Stack dafür ausgewertet wird und für jede Nutzung eines Logs eine relativ unintuitive und lange Zeile von A nach B kopiert werden muss. Anders sieht es mit folgender Lösung aus:

package net.seeseekey.example;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * Utility class to get logger
 */
public final class Logging {

    private Logging() {
    }

    public static Logger getLogger() {

        StackWalker.StackFrame frame = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE)
                .walk(stream -> stream.skip(1)
                        .findFirst()
                        .orElse(null));

        if (frame == null) {
            return LoggerFactory.getLogger("Common");
        }

        return LoggerFactory.getLogger(frame.getClassName());
    }
}

Bei dieser Utility-Klasse wird der entsprechende Klassenname dynamisch über einen StackWalker ermittelt. Zurückgegeben wird hierbei der Klassenname des Aufrufers. Konnte kein Klassenname ermittelt werden, so wird stattdessen ein Logger mit dem Namen Common zurückgegeben. Damit kann der eigentliche Logger nun wie folgt angelegt werden:

Logger log = Logging.getLogger();

Der StackWalker ist ab Java 9 verfügbar und kann somit in neueren Projekten problemlos genutzt werden. Im Gegensatz zu den bisherigen Methoden Teile des Stacktrace zu erhalten, ist der StackWalker aus Performancesicht zu bevorzugen. Definiert wurde diese API in der JEP 259.

Was steckt hinter Stadia?

Der Spielestreaming-Dienst Stadia versteht sich als neue Plattform. Wer für diese Plattform entwickeln möchte, kann sich unter stadia.dev dafür bewerben. Auf der Seite erhält der Leser daneben weitere Informationen über die Plattform.

stadia.dev

Auf der Hardwareseite wird aktuell eine 2,7-GHz-Hyperthread-x86-CPU mit AVX2 SIMD und 9,5 MB L2- und L3-Cache, eine AMD-GPU mit HBM2-Speicher und 56 Recheneinheiten mit einer Leistung von 10,7 Teraflops, 16 GB RAM mit einer Bandbreite von bis zu 484 Gbit/s und SSD-Speicher in der Cloud genutzt.

Auf Softwareseite wird Linux genutzt. Google nutzt hierbei die Linux-Distribution Debian als Grundlage. Als Grafikschnittstelle müssen die Spiele Vulkan benutzen. Dazu wird eine API bzw. ein SDK mitgeliefert, welches Funktionalitäten für die Verwaltung von Spielständen, die Nutzung der Multiplayer-Modi und der Funktionen für die Unterstützung der Unterbrechung und Fortsetzung des Spieles liefert.

Zurzeit unterstützen das Entwicklerwerkzeug Unity und die Unreal Engine den Spielestreaming-Dienst. Daneben existieren weitere Werkzeuge von Google, welche bei der Entwicklung von Spielen für Stadia helfen.

Ideentool wird zu Wryte

2014 veröffentlichte ich die erste Version meines Ideentools. Dabei handelte es sich um ein Werkzeug für Autoren welches unterschiedlichste Generatoren für Namen, Charaktere und ähnliches anbot. Im Laufe der Jahre kamen viele Generatoren hinzu, allerdings wirkte die Technik hinter dem Ideentool mittlerweile etwas angestaubt.

Das alte Ideentool

Im Zuge einiger Überlegungen entstand schlussendlich ein neues Projekt mit dem Namen Wryte. Der Fokus von Wryte ist ein wenig anders als der des Ideentools. So sollte Wryte internationalisierbar sein, also für unterschiedlichste Sprachen zur Verfügung stehen. Daneben sollte das Thema Schreiben etwas weiter gefasst werden, so soll es einmal um das Schreiben im Sinne eines Autoren und Schreiben im Sinne einer Entwicklers gehen.

Hintergrund hierfür war, das ich neben dem Schreiben auch entwickle und jeweils bestimmte Tools für beides immer wieder benötige. Deshalb sind die Werkzeuge in Wryte in zwei Personas unterteilt, einmal für Autoren und einmal für Entwickler.

Ein weiteres Ziel von Wryte war die Unterstützung und Integration in mobile Systeme. So kann die App unter iOS und Android auf den Homescreen gelegt werden und fühlt sich so wie eine native App an.

Wryte ersetzt das Ideentool

Technisch wurde die Architektur sinnvoller gestaltet. Während das Ideentool eine wilde Ansammlung von JavaScript– und PHP-Schnipseln war, wurde Wryte architektonisch in eine REST-API und die eigentliche Frontend-Applikation zerlegt. Die API soll in den nächsten Monaten öffentlich dokumentiert werden, sodass diese auch von anderen genutzt werden kann. Für die API wurde eine Swagger-Datei geschrieben und mittels dieser ein Server-Stub für das Slim Framework erzeugt. Die Frontendanwendung ist eine HTML5-App und kann im Gegensatz zum Ideentool auch auf mobilen Systemen sehr gut genutzt werden. Technisch basiert sie auf dem Framework 7-Framework.

Unter iOS kann die App auf den Homescreen gelegt werden

Zu finden ist Wryte unter wryte.net. Im Gegensatz zum Ideentool, fehlen noch einige Generatoren wie der Charakter- und Geheimnisgenerator, einige Fantasienamengeneratoren und die Generatoren für Titel und Verwandtschaftsverhältnisse. Die meisten dieser Generatoren sollen in den nächsten Wochen und Monaten hinzugefügt werden.

Favicon-Generator

Vor zwei Jahren schrieb ich über einen Dienst, welcher Favicons für die unterschiedlichen Systeme erzeugt. In den letzten Tagen war ich für ein Projekt wieder auf der Suche nach einem solchen Dienst. Diesmal bin ich beim Real Favicon Generator gelandet. Im Gegensatz zum damals vorgestellten Generator arbeitet der Real Favicon Generator wesentlich umfassender.

realfavicongenerator.net

Nachdem Upload einer Grafik für das Favicon, werden einige Einstellungen abgefragt und anschließend werden die entsprechenden Bilder erzeugt. Nach der Umwandlung erhält der Nutzer die entsprechenden Dateien und die Informationen zur Einbindung. Neben der Oberfläche, verfügt der Dienst über eine API, mit welcher der Dienst in eigene Projekte eingebunden werden kann. Zu finden ist der Dienst unter realfavicongenerator.net.

Slim Framework

Für wahrscheinlich jede Programmiersprache existieren mehr oder weniger viele Frameworks, welche dem Entwickler bestimmte Aufgaben abnehmen und somit die Entwicklung beschleunigen. Neben den größeren Framework existieren auch eine Reihe von Frameworks mit einem minimalistischeren Ansatz. Eines dieses sogenannten Microframeworks ist Slim. Entwickelt wird und wurde Slim für PHP.

slimframework.com

Slim eignet sich sehr gut für die Umsetzung für REST-APIs bzw. RESTful Webservices. Um ein Projekt zu erstellen, kann der Paket- bzw. Dependency-Manager Composer genutzt werden:

composer create-project slim/slim-skeleton exampleapp

Damit wird ein Grundprojekt angelegt mit welchem gearbeitet werden kann. Auch von seitens des Swagger-Toolings wird Slim unterstützt. So kann eine API über den Swagger-Editor definiert werden und anschließend für das Slim-Framework exportiert werden. Der Quelltext des Frameworks ist auf GitHub zu finden. Es ist unter MIT-Lizenz lizenziert und damit freie Software. Die offizielle Seite des Projektes ist unter slimframework.com zu finden.