Weltrekordverdächtig

24. Februar 2026

Neon ist mein eigener Webserver auf der Grundlage der Package jdk.httpserver. Die Java-Klassenbibliothek fügt Apps einen eingebetten HTTP-Server hinzu, was vielfältige Möglichkeiten eröffnet.

Um Apps jene Serverfunktion zu spendieren muss keine Zeile Code aufgewendet werden. Die Klassenbibliothek nebst einer Serverbeschreibung in Javascript Object Notation (JSON) wird einfach der App mitgegeben, den Rest erledigt Neon.

Dabei ist Neon mit 37 KB ultraklein und lässt ähnliche Produkte in diesem Punkt weit hinter sich. Man sollte nicht meinen, dass ein HTTP-Server so wenig Platz erfordert. Das liegt daran, dass wirklich, wirklich, wirklich nur das Allernötigste für diese Funktionalität in Neon steckt.

Und doch lässt sich immer noch etwas finden, das optimiert werden kann.

Denn Neon hatte eine Abhängigkeit zu Gson, einer Klassenbibliothek zum Lesen und Schreiben von JSON sowie dem dynamischen Mapping von JSON zu Java-Objekten. Gson ist 240 KB groß. Das ist gewaltig, das Sechseinhalbfache von Neon. Krass riesig. Besonders, wenn man bedenkt, dass Gson nur zum Lesen der Serverbeschreibung in JSON gebraucht wird.

Damit ist jetzt Schluss, denn ich habe eine kleine Funktion gebaut, die die Serverbeschreibung nun mit Hilfe des winzigen nanojson Parsers liest.

Wozu dient die Serverbeschreibung in JSON?

Der große Vorteil der Serverbeschreibung ist, dass es keinerlei eigenen Codes bedarf, um einen Server »hochzuziehen«. Das macht alles die in Neon enthaltene Klasse Factory dynamisch aus der Serverbeschreibung. Auf diese Weise lassen sich sowohl einfache als auch sehr komplexe Serverstrukturen ohne eine Zeile Code erzeugen.

Die Serverbeschreibung ist in JSON abgefasst, weil dieses Format leichtgewichtig, einfach lesbar und gut mit einem einfachen Texteditor zu bearbeiten ist. Zum Lesen von JSON ist allerdings ein Parser erforderlich und Gson ist für diesen Zweck einfach zu groß.

Warum ist nanojson kleiner als Gson?

nanojson enthält nur einen Parser und einen Writer. Die Klassenbibliothek verzichtet auf jegliche Funktionen des Mappings von JSON-Inhalten zu Objekten. Ein reiner Parser ist deutlich schlanker herstellbar als derlei Objekt-Mappings.

nanojson und neon

Mit seiner Winzigkeit ist nanojson genau, was der Größenordnung von Neon entspricht. Da JSON bei Neon nur zum Einlesen der Serverbeschreibung benötigt wird, kann auf alle Funktionen außer dem Parser verzichtet werden. Trotzdem lassen sich durchaus noch viele weitere Anwendungsfälle denken, die JSON erfordern und dann hat Neon einen kleinen und leistungsfähigen Parser dafür bereits an Bord.

nanojson und Neon sind die ideale Kombination.

Eine neue Dimension

Eine minimalistische App, die beispielsweise ohne weitere Logik nur einen eingebetteten HTTP-Server für statische Inhalte mit Hilfe von Neon bereitstellt, kommt so nun auf eine Winzigkeit von sagenhaften 81 KB (Neon 37 KB, nanojson 39 KB und die App 5 KB).

In Worten: Einundachzig Kilobyte.

Das muss Weltrekord für Java sein, wo derlei Anwendungen gewöhnlich erst ab mehreren Megabyte losgehen und damit bereits als sehr schlank gelten.

(kicher)

‹ geschriebene worte