Java ist auch ein Schnellboot… inzwischen

Java ist langsam, diese Aussage treffe ich seit der Geburt von Java an…oft zu Recht, zumindest in der Retrospektive.

In den ersten Jahren bezog sich eine solche Aussage auf die Laufzeitgeschwindigkeit von Java. Diese Kritik ist inzwischen überholt, ist Java seit einer Version 5 (fast) so schnell wie C++ und definitiv schneller als PHP, Ruby, Grails und viele andere Scriptsprachen. Und das behaupte ich nicht nur so, ich habe mit vielen gearbeitet.

Aber Java war und ist auch langsam in einer/der Umsetzung von (fachlichen) Anforderungen. Auch diese Kritik war und ist auch noch berechtigt. Das schwergewichtige JEE-Framework hat aus den meisten Anwendungsentwickler der letzten Jahre in der Regel Infrastrukturentwickler und „Technikfreaks“ gemacht, die sich leider nur zu einem Bruchteil ihrer Zeit mit der Umsetzung von Anforderungen beschäftigen konnten. Nicht unberechtigt deswegen der jüngere Erfolg  diverser Scriptsprachen und CRUD-Umgebungen wie z.B. Rails, Grails u.a.

Allerdings ist diese Kritik nicht mehr bzw. nicht immer berechtigt. Gerade neuere JEE-Technologien (Version 5+) oder Frameworks wie Spring und Seam haben den Entwicklungsprozess dermaßen beschleunigt, dass ein Umstieg zu Ruby oder Grails nicht mehr und unbedingt notwendig ist. Auch die Entwicklungsumgebungen und das Zusammenspiel mit einem entsprechenden Applikationsserver sind deutlich besser geworden, so dass auch hier der Vorteil der Scriptsprachen (Save & Forget) schwindet. Die moderne IBM RAD-Entwicklungsumgebung z.B. im Zusammenspiel mit einem Websphere Appserver gibt dem Entwickler inzwischen das Gefühl, man arbeitet mit Java wie mit einer Scriptsprache. Einfach speichern und die Änderungen sind deployed. Sicherlich ist IBM hier mit ihrer Lösung am weistesten (so meine Einschätzung), aber ich kann mir auch gut vorstellen, dass die OpenSource-Konkurrenten bald nachziehen werden und wollen.

Um hier aber konkreter zu werden – wie kann ich, neben dem Einsatz moderner Entwicklungswerkzeuge, auch mit dem aktuellen JEE schneller entwickeln?

Relativ einfach – drei Regeln reichen m.E. aus:

  • Spring als ein, als der „globale Projektklebstoff“ und zwar nicht irgendein Spring, sondern das annotierte Spring. Abhängigkeiten zur Technik werden eliminiert und die Notwendigkeit „nerviger“ Konfigurationsfiles wird auf ein Minimum reduziert. Selbst JSF-Notwendigkeiten und Transaktionen lassen sich mit Spring stark vereinfachen
  • JSF im Zusammenspiel mit zusätzlichen GUI-Bibliotheken (als Frontend- und Screenflow-Framework), z.B. Richfaces oder JQuery
  • JPA als Persistenzframework, sinnervollerweise ähnlich wie Spring oder JSF in der annotierten Variante

Setzt ein Entwickler auf diesen drei Pfeilern auf, ist selbst eine JEE-Anwendung m.E. schnell erstellt. Dann aber mit dem Vorteil, auf einen umfangreichen Schatz an zusätzlichen Komponenten und Frameworks zurück greifen zu können und der Laufzeitgeschwindigkeit eines compilierten Java.

Fazit: Vor 1-2 Jahren hätte ich bedingungslos einer/der Aussage zugestimmt, für eine schnelle Anwendungsentwicklung braucht man PHP, Ruby oder Grails. Heute lässt sich auch mit JEE schnell entwickeln.

Ein Gedanke zu “Java ist auch ein Schnellboot… inzwischen

  1. stimm ich voll und ganz zu, allerdings ist die einstiegshürde so enorm groß, daß ein vergleich (zu RoR und GoR) kaum ziehbar ist. der irrsinns-aufwand den man betreiben muss um in all die oben genannten frameworks einzusteigen steht in keinem verhältnis. zu dem muss man auch noch alle frameworks in kombination orchestrieren, da ja alle hier und da ihre macken haben (zb jsf in kombination mit o/r mappern à la jpa und hibernate). abhilfe schafft da tatsächlich seam, braucht aber i.d.r. ein ejb container (ja, läuft auch im tomcat, aber man kann davon ausgehen das man über kurz oder lang nicht um den jboss herum kommt).

    ich bin ein großer fan von oben genannten kombinationen, und wenn man sich angewöhnt maven artefakte zu bauen kann man innerhalb von einem tag robuste jee anwendungen hochziehen, ähnlich wie es seam-gen baut (nur besser). allerdings hat mich das bis jetz schon einige jahre gekostet 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.