Das Laden einer visuellen Klasse geschieht über OPEN WITH > VISUAL EDITOR. Mit diesem Menübefehl lassen sich auch vorhandene Oberflächen einlesen. Der Visual Editor kann so konfiguriert werden, dass er automatisch GUIs erkennt, die von Borlands Jbuilder und IBMs Visual Age stammen. Über WINDOW > PREFERENCES > JAVA > VISUAL EDITOR gelangt man an weitere Einstellungen zum Erscheinungsbild, zur Codegenerierung und zum Reverse Engineering. Das Reverse Engineering vorhandener Oberflächen funktioniert bis zu einer gewissen Komplexität eines Layouts ausreichend gut. Will man auch komplexe Layouts einlesen, sind Umstrukturierungen notwendig.
Ist eine visuelle Klasse erst einmal im Editor geladen, erscheint auch eine Palette mit Javabeans, aus denen die benötigten Widgets ausgewählt und zu einer Oberfläche arrangiert werden können. Zu diesem Zweck sollte man die neue Javabeans-View verwenden. Sie präsentiert den Aufbau des Widgets beziehungsweise Fensters, das im Editor markiert ist.
Widgets arrangieren
Neue Widgets zieht man vorzugsweise auf diese View und arrangiert das neue Element erst später in der Voransicht. Mehrere Elemente lassen sich über den Befehl CUSTOMIZE LAYOUT eines Kontextmenüs nach verschiedenen Kriterien ausrichten und in der Größe und im Abstand abgleichen.
Das Arrangieren der Widgets lässt durch seine vielfältigen Möglichkeiten kaum Wünsche offen und geht mit einem schnellen Rechner und ausreichend Hauptspeicher auch einigermaßen leicht von der Hand. Der generierte Code ist übersichtlich, frei von proprietären Bestandteilen und angenehm leicht zu lesen. Die Synchronisation zwischen Quelltext und der GUI-Darstellung funktioniert in der Regel gut. Ist der Quelltext aber durch Umstrukturierungen oder gelöschte Elemente kurzzeitig inkonsistent geworden, kommt die Synchronisation des Editors schnell ins Straucheln. Hier hilft nur, entweder die Synchronisation abzuschalten oder den Schwellenwert stark herabzusetzen.
Der Visual Editor hat leider diverse gravierende Mängel. Die Wysiwyg-Ansicht gehört nicht zu den Highlights des Produkts. Aber am ärgerlichsten sind die unzähligen Abstürze, die der GUI-Builder während des Tests verursachte. Sie passieren zum Beispiel im Zusammenhang mit dem Anlegen neuer Swing-Menüs. Hier produzierte der Visual Editor anscheinend Deadlocks bei der Synchronisation. Sie führten dazu, dass die gesamte Entwicklungsumgebung mit "Out of Sync" hängen blieb und nur noch über den Task-Manager gewaltsam beendet werden konnte.
Weiterhin hinterlässt der Visual Editor hin und wieder auch nach ausreichender Synchronisationsphase inkonsistenten Code. Das passiert zum Beispiel beim Löschen nicht mehr benötigter Widgets. Während er für neu angelegte Widgets automatisch die nötigen Importanweisungen ergänzt, funktioniert der umgekehrte Vorgang nicht immer zuverlässig. Entfernt man ein nicht benötigtes Widget, so löscht er die dazu gehörenden Importanweisungen des Öfteren nicht. Das Ergebnis ist, dass die Workbench toten Code moniert.
Ein weiteres großes Problem des Visual Editor ist der Verbrauch an Ressourcen. Selbst mit 512 MB Hauptspeicher lässt sich manchmal nicht mehr flüssig arbeiten. Der GUI-Builder startet diverse virtuelle Maschinen als Subprozesse, die vermutlich - neben dem sicherlich nicht optimierten Code - für den Raubbau an Ressourcen verantwortlich sind. Das Plugin bremst die Leistungsfähigkeit der Eclipse-Workbench so spürbar aus, dass selbst der Start der Entwicklungsumgebung zur Geduldsprobe wird. Summa summarum erscheint die Versionsnummer 1.0, gemessen am Entwicklungsstand dieses Produkts, als stark verfrüht.