Ist man bei Apache noch bei Trost?

20. Februar 2026

Bei einem Besuch der Homepage des Apache Db Projekts fiel mir heute auf, dass das relationale Datenbankmanagementsystem (RDBMS) »Derby« offenbar nicht mehr weiterentwickelt wird.

On 2025-10-10, the Derby developers voted to retire the project into a read-only state. Derby development and bug-fixing have ended. No further releases will be published.

Ich hatte das gar nicht mitbekommen und bin angesichts der Bedeutung von Derby schockiert.

Geschichte von Derby

Ein Blick auf die Geschichte von Derby bei Wikipedia fasst wie folgt zusammen:

Die Software wurde ursprünglich von der Firma Cloudscape Inc., in Oakland (Kalifornien) unter dem Namen JBMS entwickelt. Die erste Version kam 1997 heraus. Das Produkt wurde später in „Cloudscape“ umbenannt.

1999 wurde Cloudscape von der Firma Informix Software Inc. gekauft, deren Datenbanksparte 2001 von IBM übernommen wurde. 2004 übereignete IBM die Cloudscape-Software der Apache Software Foundation unter dem Namen „Derby“ als Freie Software.

Ab Anfang 2005 beteiligte sich auch Sun Microsystems an Derby. 2006 wurde Derby als Java DB im Java Development Kit ab Java 6 integriert.

Ich hatte Derby schon eingesetzt, als es noch Cloudscape hieß und war begeistert von einem RDBMS, dessen Kern nur 600 kB klein ist. Trotz dieser geringen Größe ist Derby kompatibel mit »DB2«, dem Standard-Datenbankprodukt von IBM, das selbst auf Großrechnern läuft.

Man kann Datenbanken auf einem 600 kB kleinen Derby betreiben und mit wenigen Handgriffen 1:1 nach DB2 umziehen und umgekehrt. Im Grunde reicht ein SQL-Dump. Wenn das kein Industriestandard ist, weiß ich nicht, was sonst als solcher gelten sollte.

Apache Db Projekt

Umso irritierender ist, dass die Produkte, die von Apache »dazuerfunden« wurden, nicht in diese Größenordnung passen. So bringt zum Beispiel das Apache-Produkt »Torque« für das objekt-relationale Mapping 251 kB auf die Waage und erfordert obendrein Abhängigkeiten in Form zusätzlicher Bibliotheken einer Größe von sage und schreibe 6,1 MB.

Im Vergleich dazu: Meine eigene Klassenbibliothek für das objekt-relationale Mapping »BaseLink« bringt es gerade einmal auf 67 kB und erfordert Null Abhängigkeiten.

An der geringen Größe von Derby selbst hat Apache zum Glück nichts geändert sondern sich stattdessen auf die Pflege der Software beschränkt so wie sie ist. Warum also nun die Einstellung dieser notwendigen Pflege-Tätigkeit? Apache schweigt sich über die Gründe aus.

Einschätzung, Bewertung

Es könnte gesagt werden, dass Derby derart ausentwickelt ist, dass es keine Weiterentwicklung braucht. Dennoch wäre eine Fortführung von Bug Fixes und Sicherheitsupdates wichtig, insbesondere, wenn man bedenkt, dass Derby im Grunde seit jeher die Referenz-Implementierung eines RDBMS in Java darstellt.

Das schickt man nicht stillschweigend in Rente, Derby ist von anhaltender Bedeutung und Notwendigkeit. So drängt sich die Frage auf:

Ist man bei Apache noch bei Trost?

Die Apache Stiftung bekommt Software zur Pflege und Weiterführung überlassen, nicht, um die Software zu Grabe zu tragen.

Wenigstens gibt es mit H2 ein vergleichbares Produkt, das Derby würdig ersetzen könnte. Ich habe H2 noch nicht eingesetzt, werde das aber ausprobieren, sobald es die Zeit erlaubt. Möglicherweise ist es ja auch das Kalkül von Apache, dass Nutzer auf H2 umschwenken.

Ausblick

Als Java-Nutzer der ersten Stunde muss ich wohl zur Kenntnis nehmen, dass womöglich ebenso, wie auch ich inzwischen in Rente bin, peu à peu Teile des Java-Kosmos sich ebenfalls in die Rente verabschieden. Derby könnte erst der Anfang sein.

Im Unterschied zu Apache fühle ich mich allerdings noch nicht müde, Java und auf Java beruhende Produkte einzusetzen, im Gegenteil. Für mich ist Java eine fantastische Technologie, die hoffentlich noch lange fortbesteht.

Etwas, das für meinen Geschmack von so gut wie keiner Apache Software gesagt werden konnte. Schon der Apache Webserver fand nie meine Wertschätzung. Dasselbe gilt für Dinge wie Apache Commons oder sogar Apache Tomcat. Alles viel zu überdimensioniert und monströs. Keine Schlankheit, keine Eleganz.

Als ich das bei Tomcat schließlich nicht mehr mitansehen konnte, war es Zeit für mich, dem etwas eigenes entgegenzusetzen. neon war »geboren« und tut seither in vielen meiner eigenen Apps als Kern ebenso klaglos wie unbemerkt seinen Dienst, z.B. auch hier im Journal oder auf den Fotoseiten. Beides seit der Umstellung auf neon winzige, schlanke, schnelle Web Apps ohne den ganzen Ballast von Tomcat und Java EE.

Das interessiert vermutlich niemanden sonderlich, aber mir ist das wichtig.

Derby ging von Anfang an in eine ähnliche Richtung und war für mich daher immer das leuchtende Gegenbeispiel für fast alle Apache Projekte und einiges mehr aus dem Java-Kosmos, vermutlich, weil die Datenbank ursprünglich nicht von Akteuren aus dem etablierten Java-Kosmos stammte.

Aus meiner Sicht ist es ebenso tragisch wie unverdient, dass Apache Derby auf diese Weise ein Ende macht. Vielleicht findet sich ja noch ein Maintainer, der die Software übernehmen will. Meinetwegen darf Apache lieber gestern als heute als Relikt einer überflüssigen Art der Java-Software-Entwicklung Derby nachfolgen und gern ebenfalls aufs Altenteil gehen.

Ich wünsche mir stattdessen mehr frische Java-Entwicklung, die all den Ballast alter Java-Zeiten über Bord wirft.

‹ geschriebene worte