Java in Serveranwendungen: Enttäuschung ohne Ende

Hat schon mal jemand eine Java-Serveranwendung betrieben? Tomcat oder dergleichen? Wenn ja, wird derjenige mir hier bestimmt zustimmen: Java ist meiner Meinung nach kein geeignetes Paket für eine Serveranwendung. Sich allein mit der Sprache zu befassen reicht nicht aus, man muss tief in die verwinkeltsten Züge der VM absteigen, um zu begreifen, wie dieses Biest arbeitet (oder auch nicht). Und erst wenn der Anwender das verstanden hat, kann er eine Java-Serveranwendung (wahrscheinlich) einigermaßen stabil laufen lassen. Alles andere funktioniert nicht.

SnipSnap

Über die Jahre hinweg habe ich mehrere Java-Serveranwendungen eingesetzt. Angefangen mit der uralten und wirklich positiv in Erinnerung gebliebenen Wiki-Software SnipSnap. Offensichtlich wussten die Entwickler hier, was sie taten. Die Software war mehrere Jahre firmenintern im Einsatz. Aber auch deren Start war holprig. Das Speichermanagement musste genau angepasst werden.

Vielleicht mag es Anwender geben, die mit folgenden Optionen umgehen können:

Ich kann es ohne genaue Kenntnis der Anwendungsinternas nicht. Ich muss mich auf die Angaben des Herstellers zu den Systemanforderungen verlassen und stelle das dann entsprechend ein.

Freenet

Abgesehen vom wirklich positiven Eindruck von SnipSnap (Ausnahmen bestätigen die Regel), war meine nächste Java-Serveranwendung Freenet. Ein freies, unreguliertes und unzensiertes Netzwerk. Die Referenzimplementation für dieses Netzwerk ist in Java geschrieben. Ob man nun Oracles Java oder die freie Implementierung OpenJRE/JDK verwendet: es ist nicht stabil zum Laufen zu bekommen, egal, wie groß die Kiste ist.

Unter dem Motto der Portabilität waren auch noch viele Desktop-Anwendungen für dieses Netzwerk in Java geschrieben, die eher schlecht als recht funktioniert haben.

Höhepunkt war dann eine Watchdog, die aufpasste, wann Freenet wieder einmal abgestürzt war und es in diesem Falle neu startete.

JaCy

Vor Kurzem habe ich es dann wieder einmal versucht: JaCy, eine nicht zensierbare per P2P verteilte Suchmaschine, die ebenfalls in Java entwickelt wurde. Anfänglich war ich überrascht über die wenigen Abhängigkeiten (eigentlich nur Java) und der einfachen Installation mit vielleicht drei oder vier Optionen, aberundet mit einer wirklich ansprechenden Weboberfläche. Aber auch hier zeigte sich, dass Java nicht so einfach in den Griff zu bekommen ist, besser gesagt: das Speichermanagement von Java. JaCy wird mit einer Defaulteinstellung von max. 600 MB für die Java-VM ausgeliefert. Das sollte eigentlich für jeden durchschnittlichen Server mehr als ausreichend sein. Wie man aber dann nach kurzer Zeit Laufzeit sieht, pumpt sich der virtuelle Speicher des Prozesses schon mal auf gute 1,6 GB auf... Warum?

Testweise habe ich JaCy in eine VM mit 2 GB RAM eingesperrt. Sobald man die Anwendung jedoch ein paar Sachen tun lässt, sprengt nach kurzer Zeit der Speicherhunger von Java jeden Rahmen und hält sich keinesfalls an die vorkonfigurierten Maximalwerte. Zumal das Java-interne Speichermanagement diesen Schwellzustand offensichtlich mitbekommt, anschließend aber nur noch damit beschäftigt ist, Garbage Collections durchzuführen, welche anscheinend nichts bringen, und so den Prozess dauerhaft auf Maximal-CPU-Last fahren. Quasi ein Deadlock zwischen Anforderung und GC.

Desktopanwendungen

Ganz ehrlich: man kann in Java wirklich tolle Sachen programmieren. So z.B. Eclipse. Eine Anwendung, die ich wirklich sehr oft nutze und von deren Funktionsumfang ich immer wieder überwältigt bin. Daneben gibt es noch eine ganze Menge kleinerer Java-Desktopanwendungen, welche klaglos funktionieren.

Und last but not least sind ja ein Großteil der auf Smartphones eingesetzten Apps in Java geschrieben. So schlecht kann die Sprache also nicht sein.

Allein als Serveranwendung finde ich sie bisher ungeeignet.