Optimale Java-Performance durch einfaches Design und klare Logik

Die Prämisse all dieser Diskussionen: Java ist langsam. Viele Entwickler belassen es bei dieser Feststellung und sind der Auffassung, dass Java eine vorgegebene Aufgabe nur dann zufriedenstellend erledigen kann, wenn man sich intensiv mit den technischen Interna befasst.

Der eine oder andere wird sicher schon einmal einen Blick auf all die Tools geworfen haben, mit denen sich angeblich die Computer-Performance drastisch erhöhen lässt. Ich durchforste jedenfalls regelmäßig Download.com und ähnliche Websites, um jedes dieser Wundermittel auszuprobieren, das mir in die Finger kommt. Aber ohne den Schöpfern dieser Tools zu nahe treten zu wollen, erweist sich dies stets als vergebliches Unterfangen, das nur meine Geduld auf die Probe stellt. Doch schon wenige Monate später bin ich wieder auf der Jagd nach solchen Tools. Ich kann mich einfach nicht damit abfinden, dass mein Computer langsam ist und ich nichts dagegen tun kann. Die einzige Lösung, die wirklich funktioniert, ist die Neuformatierung der Festplatte, das Löschen von unnötigem Datenmüll und eine wohlüberlegte Installation. Alle oberflächlichen Methoden bringen dagegen keinen Erfolg.

Genau so verlief auch meine Erfahrung mit Java. Wenn man sich die Optimierung der Performance erst für das Ende der eigentlichen Programmierung, also kurz vor der Auslieferung vornimmt, kann man es auch gleich ganz sein lassen. Der Zugewinn an Performance dürfte nur in den seltensten Fällen den Aufwand an Zeit und Mühe lohnen.

Die Performance ignorieren?

Sollte man also die Frage der Performance einfach ignorieren und hoffen, dass die Anwendung ihre Aufgabe in angemessenem Maße erfüllt? Auf keinen Fall! Anwendungen sollten so geplant werden, dass nicht unnötig viele Ebenen von Klassen eingeführt werden müssen, von denen jede nur in geringem Maße zur Erledigung einer bestimmten Aufgabe beiträgt. Es mag zwar wie ein Klischee klingen, doch stellt der technische Overkill von Seiten der Entwickler in der Tat ein großes Problem dar. Vermutlich wollen viele Software-Designer eben einfach zeigen, was sie alles wissen oder welche Tricks sie draufhaben.

Meiner Meinung nach wird ein Entwickler, der keine Verantwortung für seinen Code übernehmen muss oder nur den ersten Entwurf des Designs übernimmt, seine Arbeit kaum ordentlich erledigen. Sobald man einem Entwickler die Aufgabe überträgt, die auf seinem Design basierende Anwendung auch zu programmieren, wird das Design einfacher ausfallen und kein überflüssiges Beiwerk enthalten.

Obwohl ich mich in Extreme Programming (XP) nicht allzu gut auskenne, gefällt mir dennoch, was ich bislang darüber in Erfahrung gebracht habe. Der Schwerpunkt liegt hierbei auf dem Ansatz, das System flexibel zu halten und erforderlichenfalls ein Refactoring durchzuführen, was gegenüber der Erzeugung gigantischer Systeme, die auf alle Eventualitäten vorbereitet sein sollen, eine erfrischende Abwechslung darstellt.

---

Definition von Refactoring
Für Anwender, die mit dem Begriff Refactoring nichts anfangen können, hier seine Definition gemäß dem Buch „Extreme Programming Explored“: „Refactoring ist der Prozess, mit dem das Design von Programmcode verbessert wird, ohne sein externes Verhalten zu beeinflussen. Es wird so refaktoriert, dass der Code möglichst einfach bleibt und dadurch für alle möglichen Änderungen offen ist.“

---

Ich bin der Überzeugung, dass ein schlankes Design unter Verwendung von einfachen technischen Lösungen immer leistungsfähiger sein wird als ein sperriges Design, das brandneue Technologien einsetzt. Oft werden Projekte kompliziert, weil man unnötigerweise Dinge wie Enterprise JavaBeans (EJB) einsetzt. EJB sind sicher ein nützliches Verfahren, doch nur in wenigen, ausgesuchten Fällen. Die große Mehrzahl von J2EE-Projekten ließe sich wesentlich besser mit bewährten Methoden wie JSP, Servlets, Java-Klassen und eventuell einem Framework wie Struts realisieren.