Klassen sind tot, lang leben die Interfaces!

Das ist neu in Apache Polygene 3.0 & ein Ausblick auf die Zukunft

Dominik Mohilo

© Shutterstock.com / Vilaiporn Chatchawal

Erinnern Sie sich an Qi4j? Das Projekt startete im Jahr 2007 und wurde mit dem Eintritt in die Apache Software Foundation in Apache Polygene umbenannt. Version 3.0 des Java Application Frameworks ist nun verfügbar, wir haben uns angesehen, welche Verbesserungen das Major Release mit sich bringt.

Eigentlich wird Apache Polygene der Begriff „Framework“ nicht ganz gerecht. Hinter dem Projektnamen verbirgt sich nämlich eine entwurfsmusterorientierte Entwicklungsplattform für Java, die für das Programmieren von Anwendungen genutzt wird, deren Fokus auf der Persistenz liegt. Das Framework, das modular aufgebaut ist, beinhaltet zudem Lösungen für das Erstellen von Business-Anwendungen mit Dependency Injection, aspektorientierter Programmierung, einem Persistenzsystem, Metriken und Serialisierung. Für Polygene existieren außerdem zahlreiche Erweiterungen.

Der Slogan von Apache Polygene, ‘New Energy for Java – Klassen sind tot, lang leben die Interfaces‘, fasst so ziemlich zusammen, worum es bei Apache Polygene eigentlich geht: Software effizienter zu designen. Viel zu viele Frameworks haben zu viel Boilerplate-Code und zu viele Konfigurationen, die schlicht nicht benötigt werden – das bremst viele Entwickler aus. Zudem suchen etliche Coder nach einer Alternative für das JPA (Java Persistence API). Polygene hat nicht nur dafür eine Lösung parat, sondern noch viel mehr im Gepäck. Um es einfach zu sagen, Polygene ist ein Anwendungs-Framework, wie man es richtig macht.

Niclas Hedhman, Co-Founder des Projektes und Mitglied des Apache Polygene Project Management Committees

Apache Polygene 3.0

In Sachen Funktionalität

Mit Apache Polygene 3.0 führt das Team eine neue Restlet-Bibliothek ein, mit der es sehr einfach sein soll, CRUD-Abläufe im Stile von HATEOAS zu erstellen bzw. Methods in Ressourcen aufzurufen. Sämtliche Ressourcen sind Composites und deren Vorteile sind automatisch auch im Rest API enthalten. Die neue Library wird dabei zudem vollständig vom Codegenerator unterstützt.

Ein weiterer Punkt, an dem das Team gearbeitet hat, war die Unterstützung des Java Scripting APIs, das nun vollständig – inklusive der entsprechend kompatiblen Sprachen – supportet werden sollte. Damit werden in Polygene 3.0 auch Sprachen wie JavaScript (Nashorn), Groovy, Kotlin, JRuby, Jython und Lua verfügbar. Innerhalb eines Composites mit sieben Methods können damit zum Beispiel sieben verschiedene Sprachen zum Einsatz kommen (eine pro Method).

Zwei neue EntityStores haben es ebenfalls ins Update geschafft. Apache Polygene hat jeweils einen für Apache Cassandra und Apache Geode an Bord, ersterer nutzt allerdings nicht das JsonMapEntityStore API.

In Sachen Kompatibilität

Für Nutzer von älteren Java-Versionen gibt es schlechte Nachrichten: Apache Polygene 3.0 setzt Java 8 voraus, da man sich entschieden hat, org.qi4j.core.functional und org.qi4j.core.io auszubauen und vollständig auf das Java Functional API und das Java Streaming API umzustellen. Und wo man gerade dabei ist, Breaking Changes einzuführen, wird auch der Namespace org.qi4j durch org.apache.polygene ersetzt.

Das Serialization SPI wurde überarbeitet und für Polygene 3.0 setzt man nun auf die javax.json-Erweiterungen. Empfohlen wird vom Team Apache Johnzon, allerdings können alle Erweiterungen genutzt werden, die mit javax.json kompatibel sind. In Sachen SPI gibt es allerdings noch weitere Neuerungen: Das EntityStore SPI wurde ebenfalls aufgebohrt und das Storage-Format für den JsonEntityStore wurde verändert. Achtung! Existierende Daten sind nicht mehr kompatibel.

Zur Causa OSGi ist zu sagen, dass in Apache Polygene bis aufs Weitere die Unterstützung für OSGi nicht mehr garantiert wird. Bereits seit einiger Zeit liegt dieser Teil des Frameworks brach und anstatt sich OSGi-freundlich zu nennen, erhebt Apache Polygene erst einmal keinen Anspruch darauf. Das bedeutet nicht, dass keine OSGi Bundle Manifests mehr generiert werden, es kann nur nicht mehr davon ausgegangen werden, dass sie optimal sind.

Lesen Sie auch: Advanced JPA: Persistenztricks für Fortgeschrittene

Ausblick

Apache Polygene 3.1

Die Arbeit an Polygene 3.1 hat bereits begonnen und die Entwickler arbeiten aktuell an drei großen Features. Eines davon ist ein Enterprise-freundlicher SQL EntityStore. Der derzeitige, so wird moniert, sei im Endeffekt nichts anderes als ein Key/Value Store, der den JsonMapEntityStore stützt. Das ist alles andere als gut für das SQL-Processing von Anwendungen und geradezu bedenklich in Bezug auf DBA und Datenmanager, deren Wunsch es ist, Daten möglichst lange in nutzbaren Formaten aufbewahren möchten. Anders soll es ab Apache Polygene 3.1 werden: Der neue SQL EntityStore soll dann alle Properties in ihren eigenen Spalten aufbewahren und Verbindungen zwischen ihnen nach dem De-facto-Standard zum Erstellen von SQL-Modellen herstellen.

Der Yeoman-getriebene Codegenerator ist laut eigener Aussage der Entwickler, das wohl größte Feature, dass im 3.x-Releasezyklus zu erwarten ist. Durch die einfache Beantwortung von wenigen Fragen, etwa nach dem Namen, dem Paket und den Modulen, die genutzt werden sollen, wird automatisch ein Gerüst erstellt, das unter anderem ein komplettes Gradle-Build-System beinhaltet. Erweiterungen wie ein Scripting API oder JMX sind optional. Vergleichbar soll der neue Codegenerator mit Spring Boot und Spring Initializr sein, mit dem Unterschied, dass hier eine vollständige Anwendung erstellt wird.

Die dritte Neuerung, an der aktuell gearbeitet wird, ist die Unterstützung von Kotlin. Zukünftig möchten die Entwickler, dass Anwendungsassemblies auch mit Kotlin an Stelle von Java geschrieben werden können.

Apache Polygene 3.2/3.3

Mittelfristig möchte das Team von Polygene ein neues Indexing- und Query-System etablieren, denn das alte ist derzeit noch lange nicht ausgereift. Neben einer Verbesserung des APIs steht auch auf dem Tableau, sicherzustellen, dass sämtliche Queries auf allen Implementierungen funktionieren. Die derzeitige Planung sieht vor, das bestehende System zu behalten (aus Kompatibilitätsgründen) und ein Parallelsystem einzuführen, dass stattdessen genutzt werden kann.

Die verbesserte Unterstützung für Zeitreihen (Timeseries) ist grob für Apache Polygene 3.3 geplant. Derzeit ist es so, dass Polygene-Anwendungen sehr langsam werden, wenn man Zeitreihen in ihnen hinterlegen möchte. Auch Visualisierungstools wie Grafana sollen bald unterstützt werden (Stichpunkt: REST API).

Lesen Sie auch: Java-EE-Architekturen und JPA: Verwendung des EntityManager im Java-EE-Stack

Weitere Informationen zu Apache Polygene 3.0 und den zukünftigen Plänen gibt es auf dem Blog von Apache Polygene und in der offiziellen Pressemitteilung auf dem Blog der Apache Foundation. Sämtliche Informationen zu Apache Polygene und Downloadlinks finden sich auf der Webseite des Frameworks.

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.