17. Februar 2024
Vielleicht kehre ich ja doch noch irgendwann zu C zurück, dann wären sehr wahrscheinlich microhttpd oder gatling mein Server der Wahl. Seit ich mich allerdings vor mehr als zwanzig Jahren von C zu Java begab, möchte ich die Annehmlichkeiten der Java-Technologie nicht mehr missen.
Das hält mich zwar nicht ab, als Reverse Proxy weiterhin gerne Caddy und Lighttpd zu verwenden. Für meinen eigenen Server allerdings möchte ich nichts anderes als die Java-Plattform.
Wobei sehr vieles in der Java-Welt überhaupt nicht das ist, was ich suche. Webanwendungen in Java beruhen beispielsweise in aller Regel auf der Servlet-Spezifikation. Während mit Spezifikationen wie JAX-RS auch modernere Zusätze bestehen, ist allen diesen Spezifikationen gemeinsam, dass deren Implementierung ziemlich umfänglich ausfällt und obendrein noch stets einen Servlet Container als Ablaufumgebung erfordert.
Es ist keine Implementierung erhältlich, die eine Art Basisversion ohne alles bereitstellt, von der sich aus dem überbordenden Angebot die gewünschten Funktionen zusammenstellen lassen. Eine individuelle Zusammenstellung einzelner Funktionen ist zwar möglich, aber das so erreichbare Minimalergebnis ist noch immer um Größenordnungen größer als eine Minimalversion es sein müsste.
Aus dieser Situation heraus war Neon entstanden.
Ein HTTP-Server mit dem Zweck, in andere Anwendungen eingebettet zu werden, der nicht auf Spezifikationen wie Servlets, Server Pages, Server Faces, JAX-RS usw. beruht. Neon ist nur auf das Modul jdk.httpserver aufgesetzt, das vielleicht minimalistischste HTTP-Konstrukt, das sich für Java denken lässt.
Ersteinmal der ganzen Dinge entledigt, die so ziemlich die ganze Java-Gemeinde zu benötigen glaubt, funktionieren Anwendungen, die einen Neon-Server einbetten, seither nicht nur wie geschmiert, sie sind auch endlich bei dem Schlankheitsgrad angelangt, der mit den eingangs genannten C-Pendants vergleichbar ist, was für Java ziemlich bemerkenswert ist.
Von Neon gibt es nun eine neue Fassung.
Als wesentliche Neuerung erspart die neue Version jede Menge Boilerplate-Code für individuelle Handler-Klassen, so dass damit nicht nur schlankere Anwendungen herauskommen sondern zugleich auch bedeutend mehr Flexibilität in der Anwendung.
Zudem wurde noch konsequenter auf den Ansatz geachtet, Objekte nur zu instanziieren, wenn sie gebraucht werden. Das typische 'Objektgeflecht' großer Java-Anwendungen sucht man bei Neon vergebens. Flache Strukturen. Das Laden von Klassen und das Erzeugen von Objekten erfolgt noch stärker 'on demand' und Actor-Objekte werden sofort nach der Ausführung ihrer Methoden wieder freigegeben.
Die Module der ersten Version von Neon passen dazu nicht mehr, sind aber größtenteils wiederverwendbar und werden demnächst in der benötigten Form neu entstehen.
Neon 2 ist ab sofort mit wenig Aufwand in eigene Apps einbaubar und an der gewohnten Stelle abrufbar: Link.
Copyright © Ulrich Hilger, alle Rechte vorbehalten.