Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

25.11.1998 - 

Nach Einführung der Swing-Klassen

Die GUI-Entwicklung stellt Java-Tools vor Probleme

Von Fotis Jannidis* Dank Javasofts neuer Bibliothek zur Programmierung von grafischen Benutzeroberflächen, kurz "Swing" genannt, soll Java endgültig mit etablierten GUIs wie Windows oder dem Macintosh gleichziehen. Die Implementierung von Swing als Javabeans sollte ihre Integration in die neueren Entwicklungsumgebungen (IDE) eigentlich zu einem Kinderspiel machen. Tatsächlich aber zeigt ein Blick auf die fünf wichtigsten Java-IDEs, daß eine ernsthafte Unterstützung von Swing erhebliche Anpassungen erfordert.

Javas alte Bibliothek zur Konstruktion grafischer Benutzeroberflächen, das AWT, war schnell ins Gerede gekommen. Die enge Anlehnung an das jeweilige Betriebssystem ("Peer-Konzept") erschwerte das Programmieren einer wirklich plattformunabhängigen Oberfläche und drohte somit, den wichtigsten Pluspunkt von Java ernsthaft in Frage zu stellen. Zudem konnte es nur relativ wenige Bildschirmelemente für das Programmieren von GUIs vorweisen.

Diese Mängel soll Javasofts neue Komponentenbibliothek Swing beheben. Sie liegt aktuell in Version 1.0.3 vor, das Beta-Release 1.1 läßt sich bereits aus dem Internet beziehen. Die Bibliothek umfaßt sogenannte Leichtbausteine, die eine plattformunabhängige Erstellung von grafischen Benutzer-Schnittstellen erlauben sollen. Die GUI-Bibliothek wuchs außerdem durch zahlreiche Komponenten, die Entwickler bislang schmerzlich vermißt hatten, auf das Doppelte an. Zugleich haben sich die Sun-Ingenieure die Chance zu weiteren Verbesserungen nicht entgehen lassen. Daten und Darstellung werden nun durch die "Modell-View"-Technik getrennt, und es gibt ein schnell verstellbares Look and feel für die Oberflächen: Mit einem Befehl kann man zwischen einem Windows-95-, einem Motif- und einem Java-eigenen Aussehen der Benutzer-Schnittstelle umschalten.

Die Komponenten der Swing-Bibliothek wurden als Javabeans implementiert - scheinbar eine erfreuliche Angelegenheit, da theoretisch alle Entwicklungsumgebungen, die Javabeans unterstützen, direkt mit Swing arbeiten können. In der Praxis zeigt sich jedoch, daß die Java-Architekten auf diesen Punkt keinen großen Wert gelegt haben. Das beginnt damit, daß eine wesentliche Methode geändert wurde, nämlich der Funktionsaufruf, mit dem eine Komponente in einen Container aufgenommen wird. Dadurch ist eine automatische Codegenerierung für diesen, bei jeder Oberflächenprogrammierung notwendigen Schritt unmöglich geworden - alle IDEs mußten dem erst angepaßt werden.

Die hier besprochenen IDEs "Borland Jbuilder 2", Symantecs "Visual Café 2.5", "Sybase Power-J 2.5", IBMs "Visual Age for Java 2.0" (VAJ) und "Supercede 2.0" vom gleichnamigen Hersteller haben das inzwischen hinter sich. Ähnlich verfuhr Sun auch bei einigen anderen Containern, die ebenfalls spezielle Methoden beziehungsweise Funktionsaufrufe als Erweiterung erhalten haben (beispielsweise J Tabbed Pane) - an dieser Hürde scheitert Sy- mantecs Visual Cafe 2.5. Power J und Supercede führen diese Komponente gar nicht erst auf ihrer Swing-Palette.

Ein weiteres Zeichen für die geringe Rolle, die Javasoft der Abwärtskompatibilität beimißt, ist der Umgang mit der Package-Bezeichnung für Swing. Sie wurde in der jetzt verfügbaren Betaversion 1.1 geändert. Dadurch sind alle Projekte, die bislang mit Swing entwickelt wurden, inkompatibel zur aktuellen Ausführung. Da diese Änderung erst vor sehr kurzer Zeit erfolgte, beherrscht bis jetzt noch keine der Entwicklungsumgebungen das Problem - entsprechende Updates sind für die meisten IDEs allerdings schon angekündigt.

Die Swing-Bibliothek besteht aus zwei Gruppen: den Containern und den Bausteinen. Da auch das erste Fenster einer grafischen Benutzeroberfläche ein Container ist, muß der Anwender noch vor dem eigentlichen Start des GUI-Designs die Möglichkeit haben, seinen Basis-Container auszusuchen. Vorbildlich gelöst hat das Sybase bei Power J. Dort läßt sich auswählen, ob man für das Java Development Kit (JDK) 1.0.2 oder 1.1 und mit Hilfe von Swing entwickeln möchte. Jbuilder erlaubt eine projektspezifische Festlegung der Komponentenpalette und sogar des gewünschten JDK. Auf diese Weise kann man mit der neuesten Betaversion des JDK 1.2 arbeiten, wenn auch nicht debuggen. Ein gezielter Zugriff auf die Swing-Container ist in der einen oder anderen Weise aber auch mit den anderen hier getesteten IDEs möglich.

Für das Drag-and-drop-Design verfügen die IDEs - mit der Ausnahme von Supercede 2.0 - über eigene Swing-Abteilungen in ihren Komponenten-Paletten. Allerdings finden sich dort keineswegs bei allen Entwicklungsumgebungen sämtliche Komponenten der neuen Bibliothek. Die Gründe für die Unterschiede sind eigentlich nicht verständlich, da die meisten auf denselben Swing-Versionen - 1.0.1 oder 1.0.2 - basieren. IBMs VAJ zeigt sich hier von der besten Seite - fast alle Komponenten können direkt von der Palette weg verarbeitet werden. Swing ist dort die voreingestellte Bibliothek zur Erstellung grafischer Benutzeroberflächen, und es unterstützt sogar die Erstellung von Exe-Dateien mit Swing-Komponenten. Jbuilder und Visual Café stehen in ihrem Palettenumfang allerdings nur wenig zurück. Zudem verfügen beide über eine einfache Update-Möglichkeit für die Palette, so daß sich auch die Bibliotheken der neueren Swing-Versionen einbinden lassen.

Visual Café erlaubt allerdings keine Kompilierung zu nativen Windows-Programmen, die Swing benutzen. Supercede, das Swing in erster Linie als großen Haufen Javabeans behandelt, hat Probleme mit der verwendeten Version 1.0.1. Nach Auskunft des Herstellers ist ein Fehler des Serialisierungsmechanismus von Javasoft dafür verantwortlich. Inzwischen ist ein Update auf der Supercede-Web-Site erschienen, das neben der fehlerbereinigten Swing-Version auch eine Win- dows-DLL-Ausführung dieser Klassen enthält. Auf der Palette von Sybase Power J fehlen eigentümlicherweise einige der wichtigeren neuen Container, beispielsweise J Splitpane oder J Tabbed Pane.

Doch die Integration von Swing-Komponenten in die Arbeitspalette sowie die Anpassung der automatischen Codegenerierung an die neuen Methoden und die neuen Swing-Events sind lediglich ein erster Schritt. Der zweite Schritt besteht aus einer aktiven Unterstützung der Designprinzipien von Swing. Einen Anfang hat Jbuilder im GUI-Designer gemacht: Mit einem Mausklick kann man zwischen verschiedenen Erscheinungsweisen wechseln - den Look and feel von Motif, MS-Windows und einem Java-eigenen namens "Metal".

Ein weiterer Schritt besteht in der Unterstützung des Anwenders in der Verwendung der komplexeren Klassengruppen, etwa derjenigen, mit denen Tabellen oder Editorenfenster gestaltet werden. Solche Komponenten lassen sich nicht mehr über das einfache Einstellen einiger Eigenschaften im dafür vorgesehenen Editor kontrollieren, sondern verlangen nach extra für sie gestalteten Assistenten.

Derartige Hilfsmittel, etwa zur Datenbankanbindung, finden sich bereits in einigen der IDEs (Visual Café, Jbuilder). Sie basieren aber eben nicht auf Swing, sondern generieren Code aus Komponentenbibliotheken, die die Hersteller vor der Einführung der neuen API selbst entwickelt hatten.

Die Anpassung der IDE an die Besonderheiten von Swing ist dabei wohl schwerer als gedacht. Ihren Entwicklern wurde auch vorgeworfen, sie hätten bei ihrem Design nicht sonderlich auf dessen Eignung für das Rapid Application Development (RAD) geachtet. Wer sich etwa die Codebeispiele für das Gestalten eines Datenblatts aus den Tabellen einer Datenbank ansieht, ist versucht, ihnen recht zu geben. Im Jbuilder kann der Anwender innerhalb der IDE-eigenen Komponentenbibliothek "JBCL" den Datenbankzugriff mittels der Einstellung einer einzigen Eigenschaft festlegen. Das erschien den Entwicklern von Jbuilder eine so gelungene Möglichkeit, GUI-Bausteine mit Daten zu verbinden, daß sie für diesen Zweck von Swing die "db-Swing"-Bibliothek ableiteten.

Wer einen Blick auf die ausgesprochen komplexen Klassen zur Erstellung von Editoren und die Darstellungsfenster für HTML- oder RTF-Dateien in Swing geworfen hat, wird sich auch für diese Komponenten möglichst intelligente Assistenten wünschen. Vielleicht würde aber auch schon eine gute Hilfefunktion reichen. Doch daran mangelt es noch erheblich. Die Hilfefunktion von Visual Café und Supercede bietet nur wenige Seiten über Swing. Jbuilder, Power J und Visual Age for Java enthalten immerhin die Java-Dokumentation zu Swing. Sie ist allerdings, wie alle Java-Dokumentationen von Sun, äußerst spartanisch.

Swing

Suns neue GUI-Bibliothek "Swing" soll das alte "Abstract Windowing Toolkit" (AWT) ablösen. Swing ist Teil der Java Foundation Classes (JFC), die Sun aufgrund der lauten Kritik am AWT entwickelt hat. Die JFC ihrerseits sollen Bestandteil der gesamten Java-Klassenbibliothek (JDK) werden. Geplant ist diese Integration mit dem JDK-Update 1.2, das in den nächsten Wochen ausgeliefert werden soll. Damit aber auch diejenigen Anwender, die noch mit JDK 1.1 arbeiten, Zugriff auf die neuen GUI-Komponenten haben, bietet Sun die JFC, also auch Swing, als eigenes Paket an. Die JFC liegen aktuell in Version 1.0.3 vor, das Beta-Release 1.1 stellt Sun mittlerweile im Internet zur Verfügung.

*Fotis Jannidis arbeitet als freier Autor in München.