Retrospektive | Java Magazin 6.2005

JDO vs. Hibernate

Bernhard Löwenstein

Dieses Mal steht die Ausgabe 6.2005 im Mittelpunkt. Schwerpunktmäßig ging es damals um die unterschiedlichen Persistenztechniken und um die Frage, ob man besser auf JDO (Java Data Objects) oder Hibernate setzen sollte.

Aus heutiger Sicht ist die Antwort recht einfach: JPA ist die Standardtechnologie. Da es sich hierbei nur um eine Spezifikation handelt, bedarf es einer konkreten JPA-Implementierung, bevor man loslegen kann. Recht häufig fällt dabei die Wahl auf Hibernate – und so schließt sich der Kreis zu vorhin! In Vergessenheit geraten ist heute bereits, warum die Persistenzframeworks gerade in dieser Zeit wie die Schwammerl aus dem Boden schossen. Das lässt sich recht einfach erklären: Wenn der Standard versagt, dann beginnt das Entwicklervolk eben nach Alternativen zu suchen. Die Entity Beans als Persistenztechnologie der damaligen Java-Enterprise-Plattform waren wenig brauchbar. Um halbwegs damit zurechtzukommen, musste man auf den Bean-Persistenz-Modus und das DTO-Pattern setzen, was allerdings selbst bei kleinsten Schemaänderungen jede Menge Codeanpassungen erforderte. Eine Lösung bestand nun darin, sich einen Source-Generator zu schreiben, der anhand von ein paar Angaben alle Codekonstrukte generierte und mittels dem man solche Änderungen effizient vornehmen konnte. Zufriedenstellend war das jedoch nicht, und so kam schon bald die Idee auf, doch entsprechende Frameworks um POJOs herum zu bauen. JDO und Hibernate legten vor, JPA folgte – und (fast) alle sind mittlerweile wieder glücklich!

In einem weiteren Artikel wurde JavaDoc vorgestellt. Ohne Zweifel stellt es heute zumeist die Wahl Nummer 1 für die Dokumentation von Java-Quellcode dar. Entwicklern haftet ja das Image an, nicht unbedingt die fleißigsten Kommentarschreiber zu sein. Die Vorzüge guter Dokumentation lernt man aber spätestens dann schätzen, wenn man Klassen nutzen möchte, die nicht aus der eigenen Feder stammen. Ich persönlich halte nichts davon, alle trivialen Getter- und Setter-Methoden mit Kommentaren à la „Diese Methode liefert das Attribut . zurück“ zu versehen. Viel wichtiger ist, dass Methoden, innerhalb derer wirklich etwas passiert, entsprechend dokumentiert werden. Hier erwarte ich mir dann auch gar keine große Weltliteratur zum Lesen zu bekommen – dazu packe ich lieber die alten Mickey-Mouse-Hefte aus – aber ein bisschen hilfreicher Text sollte es schon sein.

Der ESB als Basis für eine serviceorientierte Architektur wurde ebenfalls den Lesern nähergebracht. Dieses System baut auf den vier Grundkonzepten Messaging, Web Services, Datentransformation und intelligentem Routing auf und verdient ohne Zweifel den Titel Integrationsweltmeister. Heinz Buschkowsky würde sich jedenfalls glücklich schätzen, wenn er über ein menschliches Pendant dazu für seinen Berliner Bezirk Neukölln verfügen würde. Im Grunde steckt hinter dem ESB ein geniales Konzept, doch so richtig Einzug hat es bis heute nicht in der Softwareindustrie gehalten. Warum? Auch wenn der ESB verspricht, dass er die Integration unterschiedlicher Systeme, Technologien und Formate vereinfacht, so erhöht sich durch seine Nutzung die architektonische Systemkomplexität. Das schreckt viele ab. Dazu kommt, dass der ESB zwar auf Standards setzt, es für die ESB-Implementierung selbst aber keinen Standard gibt, wodurch man schnell an ein bestimmtes System gebunden ist. Auch fehlten gerade in der Anfangsphase wesentliche Programmierwerkzeuge. So dauerte es z. B. beim Mule ESB, immerhin dem populärsten Open-Source-Vertreter seiner Zunft, fast ein halbes Jahrzehnt bis ein brauchbares Entwicklungsstudio mit graphischer Oberfläche bereitstand. Mittlerweile unterstützt jenes aber sogar beim Transformieren der Daten von einem Format in ein anderes. Es hat sich also auf diesem Gebiet einiges zum Guten gewendet. Sollten Sie vor größeren Integrationsaufgaben stehen, so probieren Sie doch einige ESB-Implementierungen in der technischen Evaluierungsphase aus. Sie müssen ja nicht unbedingt auf die Lösung aus dem Esel-Imperium setzen, wenngleich mich das als Mule-Champion natürlich freuen würde.

In weiteren interessanten Beiträgen ging es darum, wie man Contract First für Web Services umsetzen kann, Oliver Ihns stellte in seiner Kolumne die Inversion of Control und die Dependency Injection im Kontext von EJB 3.0 vor und die Neuerungen von JAXP 1.3 kamen ebenfalls nicht zu kurz.

Bernhard Löwenstein (bernhard.loewenstein [at] java.at) ist als IT-Trainer und Consultant für javatraining.at und weitere Organisationen tätig. Als Gründer und ehrenamtlicher Obmann des Instituts zur Förderung des IT-Nachwuchses führt er außerdem Roboter-Workshops für Kinder und Jugendliche durch.
Geschrieben von
Bernhard Löwenstein
Kommentare
  1. Lukas Eder2013-07-09 08:56:49

    > JPA folgte - und (fast) alle sind mittlerweile wieder glücklich!

    Ein grosser Teil der Java Entwicklungswelt bedauert den Impedanz-Mismatch von Objekt-Relationalen Mappern in der täglichen Arbeit. Es war nie das Ziel von JPA alle glücklich zu machen, doch in der Zeit als JPA und JDO um die Vorherrschaft kämpften, schien ORM der einzige Persistenzweg zu sein. Heute gibt es proprietäre Alternativen wie jOOQ (http://www.jooq.org) oder MyBatis (http://www.mybatis.org), welche andere Integrationswege für Java und SQL anstreben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.