Blog

EJAPP Top 10 Countdown: #8 - Falsche Verwendung von Java EE

Vincent Partington

Aktualisiert Oktober 23, 2025

3 Minuten

In Fortsetzung des JAPP Top 10 Countdowns ist es an der Zeit, über die Nummer 8 zu sprechen. Die falsche Verwendung von Java EE kann nicht nur zu schlecht architektierten Anwendungen führen, sondern auch zu einer schlechten Leistung Ihrer Anwendung. Dieses Problem tritt vor allem bei älteren Anwendungen auf, die vor der POJO/Lightweight-Revolution vor einigen Jahren entwickelt wurden. Leichtgewichtige Frameworks wie Spring ermöglichen es dem Entwickler, die benötigten Infrastrukturdienste (Transaktionen, Sicherheit, verteilte Objekte) auszuwählen. Java EE (oder J2EE, wie wir es früher nannten) bietet alle diese Dienste die ganze Zeit über. Die Anwendungsserver sind so eingestellt, dass sie nicht viele CPU-Zyklen für nicht benötigte Infrastrukturdienste verbrauchen, aber einige Entwickler erliegen der Versuchung, diese Funktionen zu nutzen, wenn sie nicht benötigt werden. Nicht gerade hilfreich sind die "Best Practices", die mit den ersten J2EE-Versionen entstanden sind, z.B. die J2EE-Patterns von Sun.

Einige der Arten, wie Java EE falsch verwendet wird, sind:

Verwendung von entfernten EJBs, wenn lokale EJBs ausreichen würden. Seit EJB 2.0 ist es möglich, einer EJB eine lokale Schnittstelle zu geben und damit den Aufruf per Referenz einzuführen. Die meisten Anwendungsserver (BEA Welogic 9.2, IBM WebSphere 6 und Oracle OC4J) können so konfiguriert werden, dass sie auch call by reference für entfernte Objekte verwenden. Dies verbessert die Leistung, ändert aber die Semantik des Methodenaufrufs.
Falsche Verwendung des Session Facade-Musters. Dieses Muster wurde eingeführt, um die Latenz von Remote-Methodenaufrufen zu umgehen. Bei unsachgemäßer Implementierung (z.B. durch genau eine Session-Fassade für den Zugriff auf alle EJBs) wird diese Session-Bean zu einem Flaschenhals, wenn die Anzahl der Session-Beans begrenzt ist.
Das EJB n+1 Problem. Beim Verfolgen von Beziehungen litt EJB vor 2.0 unter dem Problem, dass zum Laden einer Tabelle n+1 Abfragen verwendet wurden: 1, um die IDs für die zu ladenden Objekte zu erhalten, und dann eine weitere Abfrage für jedes dieser Objekte, um die Daten zu laden. Das hat natürlich enorme negative Auswirkungen auf die Leistung Ihrer Anwendung!
Selbstentwickelte Frameworks. Da Java EE, und insbesondere die ältere Version, ein so schlechtes Programmiermodell bot, wurden viele selbst entwickelte Frameworks geschrieben. Obwohl diese einen zentralen Teil der Anwendung bilden, werden nicht alle von ihnen auf ihre Leistung getestet.

Es gibt zwei Möglichkeiten, dieses Problem zu lösen:

Wenn Sie Java EE als Programmiermodell verwenden, nutzen Sie nur die Teile, die Sie wirklich benötigen, und vermeiden Sie die oben genannten (und viele andere) Antipatterns.
Noch besser ist es, ein leichtgewichtiges Framework wie das Spring-Framework zu verwenden und Java EE nur als Anwendungsserver-Schnittstelle einzusetzen. Das hat den Vorteil, dass Sie sich vieler anderer veralteter Muster entledigen können:
- Service Locator und Business Delegate sind bei der Verwendung von Dependency Injection obsolet.
- Fast Lane Reader und Transfer Object können zugunsten einer richtigen ORM-Schicht wie Hibernate oder der Java Persistence API weggelassen werden.
- Front Controller, denn das Spring-Framework hat seinen eigenen.
- Das Abfangen von Filtern ist für Servlets sinnvoll, aber für die meisten anderen Dinge können Sie AOP verwenden.