Entwicklungsumgebungen im Vergleich

Neue Tools erschließen Java für Enterprise-Anwendungen

31.10.1997

Berücksichtigt werden im folgenden die Großen der Tool-Branche, die ein JDK-1.1-kompatibles Produkt anbieten: Borland mit "Jbuilder 1.0", IBM mit "Visual Age for Java 1.0", Sun mit "Java Workshop 2.0", Sybase mit "Power J 2.0" und Symantec mit "Visual Café 2.0". Nicht mit dabei ist Microsofts "J++ 2.0", das noch nicht erhältlich ist und zudem von den Sun-Spezifikationen abweichen soll.

Unübersichtliche Versionspolitik

Den Produktvergleich erschwert die Versionspolitik der Hersteller: Die jeweiligen Varianten der Tools lassen sich nicht ohne weiteres gegenüberstellen. Einige Firmen wie Borland oder Symantec vertreiben ihre Java-Software in drei Ausgaben: Standard, Professional und Enterprise. Sie unterscheiden sich durch Klassen- und Komponentenbibliotheken sowie Zusatzprogramme, die zur Basisversion hinzukommen. Auf der anderen Seite bieten Sybase Power J und Sun Java Workshop nur in einer Ausführung an.

So ressourcenschonend Java-Programme sind, weil die gesamten API-Klassen bereits am Client vorliegen, sowenig gilt dies für die hier untersuchten Werkzeuge. Selbst in der Einsteigerversion benötigen sie mindestens 48 MB RAM und könnten trotzdem noch etwas mehr Speicher gebrauchen. Auch mit Festplattenplatz sollte man nicht geizen. Zwischen 150 und 500 MB sollten frei sein, da nicht nur das Integrated Development Environment (IDE) selbst, sondern auch Zusatzklassen, Hilfedateien und teilweise JDBC-zu-ODBC-Brücken installiert werden.

Bis vor kurzem mußten sich Java-Entwickler mit dem spartanischen JDK oder hastig umgestrickten C++-Umgebungen begnügen. Die vorliegenden Produkte der zweiten Generation beweisen, daß Java in puncto Funktionsumfang und Flexibilität der Werkzeuge gegenüber anderen Sprachen aufgeholt hat. Zur Ausstattung gehören mittlerweile komfortable Editoren, grafische GUI-Designer, teilweise inkrementelle Compiler, Class Browser, mächtige Debugger, sogenannte Wizards, die Arbeitsschritte wie das Erstellen einer Klasse oder einer Bean vereinfachen sollen, Projektverwaltungen und Klassenbibliotheken.

Ihrem Anspruch nach befinden sich alle fünf Kandidaten auf dem Stand des JDK 1.1. Spätestens seit dem Streit zwischen Microsoft und Sun wissen die meisten, daß sich der Neuling unter den Programmiersprachen zwischen der Version 1.02 und 1.1 ganz erheblich verändert hat. Vor allem ist Javas API-Bibliothek gewachsen. Zusätzliche Neuerungen sind das Komponentenmodell Javabeans, der Mechanismus zur Kommunikation zwischen verteilten Objekten Remote Method Invocation (RMI), ein neues Ereignismodell für grafische Komponenten und innere Klassen.

Der rasche Wandel hat zur Folge - wie ein Blick auf den Kasten mit den unterstützten 1.1-Features zeigt -, daß die Konformität mit dem JDK 1.1 oft nur oberflächlich gelungen ist. Bei der Wahl des Werkzeugs ist es daher durchaus ein Kriterium, wie stark es durch das JDK 1.1 geprägt ist. Ein positives Beispiel stellt Borlands Jbuilder mit seiner herausragenden Unterstützung von Javabeans dar. Auf der anderen Seite generiert Visual Café von Symantec zwar Code entsprechend dem neuen Event-Modell, kehrt aber innerhalb der Listener-Klassen dann doch wieder zu den ungeliebten If-else-Kaskaden der ersten JDK-Generation zurück.

Freilich reicht angesichts der vorhandenen Inkonsistenzen der Java-Plattform die JDK-1.1-Kompatibilität der Tools allein noch nicht aus. Für Anwendungen, die die neuesten Features nutzen, existiert nämlich keine populäre Ablaufumgebung. Netscapes "Navigator" ist rund acht Monate nach Freigabe des JDK 1.1 immer noch nicht auf dem neuesten Stand, und Microsoft geht bei Java sowieso eigene Wege. Wer heute ein Java-Programm schreibt, muß deshalb damit rechnen, daß zumindest im Internet nur eine kleine Zahl der Anwender das JDK 1.1 nutzen können. Von den hier angebotenen IDEs erlaubt es allerdings nur Sybase Power J, JDK-1.02-konformen Code herzustellen.

Neben der wünschenswerten Abwärtskompatibilität sollten die Entwicklungswerkzeuge auch für die vorhersehbare schnelle Weiterentwicklung der Sprache gerüstet sein. Ein wichtiger Bereich dabei ist das GUI-Design, das sich durch die Java Foundation Classes (JFC) deutlich verbessern wird. Die meisten IDEs erlauben es jetzt schon, die vorhandene Komponentenpalette beliebig zu erweitern. Einige Entwicklungsumgebungen enthalten darüber hinaus für die Oberflächengestaltung zusätzliche Klassen- und Beans-Bibliotheken. Das ist im Prinzip erfreulich, kann aber auf Kosten der Transparenz gehen. Wenn nämlich visuelle Werkzeuge solche herstellerspezifischen Klassen ohne Wissen des Entwicklers nutzen, müssen sie zusammen mit der Anwendung auf die Clients heruntergeladen werden. Dies führt beim ersten Programmstart natürlich zu längeren Download-Zeiten. Vorbildlich ist daher die saubere Trennung der Bibliotheken von Power J, die das versehentliche Schreiben von ressourcenhungrigen Anwendungen vermeiden hilft.

Probleme beim GUI-Design

Java-Tools der ersten Generation konnte man häufig ansehen, daß sie nur umgearbeitete C++-Umgebungen waren. Die vorliegenden Produkte müssen aber daran gemessen werden, wie sie für Sprachspezifika von Java optimiert wurden. Dazu gehört vor allem die Implementierung als interpretierte Sprache. Sie soll dafür sorgen, daß Anwendungen auf allen Plattformen nutzbar sind, für die eine Java Virtual Machine existiert. Die Portierbarkeit gewährleisten die Compiler zwar prinzipiell durch Erstellung von Java-Bytecode, Probleme könnten aber auch hier beim GUI-Design entstehen. Verpönt sind absolute Positionsangaben für grafische Elemente, weil sie bei verschiedenen Bildschirmgrößen und -auflösungen zu einer unbrauchbaren Darstellung der Anwendung führen können.

Java greift für die bestmögliche Portabilität von GUIs auf sogenannte Layout-Manager zurück. Der Umgang mit diesem Konzept will auch von IDE-Herstellern erst gelernt sein. Ein ausführlicher Test der CW-Schwesterpublikation "NC World" http://www.ncworldmag.com/ncworld/ncw-10-1997/ncw-10-jvtools.html kommt zum Ergebnis, daß unter diesem Gesichtspunkt nur Suns Workshop 2.0 ohne Einschränkungen zu empfehlen sei. Zwar mag der GUI-Builder von Sun plattformneutral sein, einfach zu bedienen ist er sicher nicht. Wer allerdings mit dem mächtigen, aber vollkommen unberechenbaren Gridbag-Layout-Manager von IBM, Sybase oder Symantec zu tun hatte, wird Suns Leistung zu schätzen wissen. Lediglich Borlands Jbuilder, der den Entwickler erst absolut positionieren läßt, um dann auf das relative Layout umzuschalten, kann hier mithalten. Bislang ist es also keinem der hier vertretenen Anbieter gelungen, die Erstellung von GUIs mittels Layout-Manager intuitiv einleuchtend zu machen.

Ein spezifisches Feature für interpretierte Sprachen sind sogenannte inkrementelle Debugger. Damit läßt sich Programmcode während der Fehlersuche ändern, die überarbeiteten Passagen können ohne erneuten Compiler-Lauf sofort inspiziert werden. Ein solches Tool bieten bis dato nur IBM und Symantec an.

Insgesamt zeigt sich, daß die Programmierumgebungen nicht vollständig an die besonderen Bedingungen der neuen Programmiersprache angepaßt sind. An vielen Punkten spürt man eben noch, daß diese IDE-Modelle Vorfahren haben, die zur Gestaltung von Fat-Client-Programmen auf einer einzigen Zielplattform gedacht waren.