Als ich zum ersten mal als erfahrener Window-RAD-Entwickler mit dem JBuilder-GUI-Designer auf echte Tuchfühlung ging - sprich : richtig damit arbeiten wollte - wurde ich fast vom Schlag getroffen. So verhält sich das Ding anfangs recht normal und verspricht angenehmes Arbeiten, so wird es mit der Zeit zunehmend störrischer und beginnt mit einer nahezu unbegreiflichen Eigendynamik GUI-Designs zu zersetzen. Gewisse Effekte sind dabei durchaus interessant, haben aber meist wenig etwas mit dem zu tun, was man eigentlich umsetzen wollte. Aufgrund dieser negativen Erfahrung hatte ich mich dann an die Newsgroup de.comp.lang.java gewannt, wo ich einerseits Erfuhr, dass ich nicht der einzige bin, der Probleme mit der künstlichen Intelligenz von JBuilder hat, sondern das dies offenbar vielen so geht und das auch mit anderen Java-GUI-Designern. Was jedoch viel wichtiger ist : ich erfuhr etwas über die Ursache dieser Probleme (siehe Usenet-Posting Message-ID : <cne2ni$t38$1@online.de>).

Exceptions im Konstruktor

Da der GUI-Designer den Code zur Designzeit kompiliert und die entsprechende Klasse auch instanziert, um den Dialog oder das Dialogelement anzuzeigen, dürfen im Konstruktor keinerlei Exceptions geworfen werden. Problematisch sind vor allem Zugriffe auf statische Klassen, die zur Designzeit nicht zu Verfügung stehen. Das führt unweigerlich zu Problemen. Der GUI-Designer kann im besten Fall nicht alle Dialogelemente instantiieren und zeigt stattdessen rote Rechtecke an den betreffenden Stellen. Schlimmer ist jedoch, wenn bestimmte Teile nicht richtig initialisiert werden und zu Darstellungsfehlern führen. Manchmal geht das Problem so weit, dass der Dialog im Designer gar nicht mehr angezeigt werden kann. Man sollte also immer dafür sorgen, dass der Konstruktor ohne Zugriffe auf statische Resourcen und ohne Exceptions ablaufen kann. Das kann beispielsweise dadurch erreicht werden, dass man Zugriffe auf bestimmte Resourcen (z.B. statische Klassen) nicht im Konstruktor od. vom Konstruktor aufgerufenen Routinen, macht, sondern beispielsweise erst dann, wenn der Dialog angezeigt wird. Auch anderen kritischen Initialisierungscode sollte man aus dem Aufrufpfad des Konstruktors verschieben.

JBuilder zersetzt den generierten Code

Eine andere ärgerliche Angewohnheit des JBuilder-GUI-Designers ist die schrittweise Zersetzung des generierten Codes. Greift man zwischendurch auch von Hand ein, wird das Ganze nur noch schlimmer. Die Lösung für das Problem ist, den korrekt funktionierenden Code in eine eigene Init-Routine zu verschieben; ihn quasi vor den künstlichen Intelligenz von JBuilder zu retten. So fügt man z.B. mittels des GUI-Designer Swing-Elemente hinzu und bearbeitet bequem die Eigenschaften. Sobald jedoch das gewünschte Etappenziel erreicht ist, verschiebt man den Code in die andere, sichere Init-Routine, wo der JBuilder dann nicht mehr eingreifen kann. Dadurch hat man immer sicheren Boden unter den Füssen und JBuilder kann bereits bestehenden un funktionierenden Code nicht mehr zerstören. Das Ganze funktioniert recht gut, solange man in der sicheren Initialisierungsroutine etwas Ordnung hält und immer wieder den generierten Code in die Routine verschiebt.

Das sieht dann beispielsweise so aus...

public class JExample extends JFrame {
  public JExample() throws HeadlessException {
    super();
    try {
      jbInit();
    } catch (Exception ex) {
      ex.printStackTrace();
    }

    private void jbInit() throws Exception {
      jbSafeInit();

      // hier generiert JBuilder den neuen GUI-Code
    }

    private void jbSafeInit() throws Exception {

      // den finalen GUI-Code aus jbInit hier hin verschieben
      // und am besten gleich etwas ordnen

    }
  }