Mein Java Hacking tätige ich in letzter Zeit in Eclipse. Da ich die GTK-Eclipse-Variante verwende und ich letztens die neuste GTK Version 2.2.4 für GIMP übersetzt hatte, kam mir jetzt der Gedanke, ob ich nicht Eclipse überreden könnte, mit dieser neuen GTK-Version zusammenzuarbeiten. Also habe ich Eclipse mit LD_LIBRARY_PATH=/usr/local/lib /opt/eclipse/eclipse gestartet. Ergebnis ist ein deutlich besser aussehendes Eclipse. Insbesondere wird für die Fonts jetzt Antialiasing verwendet, was nach meinem Geschmack ein viel besseres Schriftbild ergibt. Einziges kleine Manko ist noch die standardmäßig eingestellt Größe der Fonts für die Menüs, die etwas kleiner sein könnte. Hier habe ich aber noch nicht die globale Einstellmöglichkeit gefunden, um hier etwas zu ändern.

Mein Java-Hacking bestreite ich zwar inzwischen zum größten Teil mit Eclipse, aber weil ich letztens nur eine kleine Änderung an einer Java-Quelle vornehmen und ich nicht extra Eclipse starten wollte, habe ich die Quelle halt in den sowieso gestarteten XEmacs geladen.

Mit der notwendigen Fummelei mit dem Customizing des XEmacs Java-IDE wäre ich zwar mit Eclipse letzendlich doch schneller gewesen, aber ich habe zumindestens einen Weg gefunden, wie die Definition des CLASSPATH unter XEmacs dann doch etwas einfacher geht.

Die Definition des CLASSPATH hat mich am XEmacs Java-IDE immer am meisten gestört. Das war immer so eine Cut’n Paste Orgie von Dateinamen.

Es geht jedoch etwas einfacher. Man holt sich das Verzeichnis, das die benötigten Jar-Archive enthält in einen dired-Buffer. Dann positioniert man den Cursor auf den entsprechenden Dateinamen. Mit der Tastenkombination Ctrl-u W holt man sich dann den absoluten Pfadnamen aus dem dired-Buffer in den Kill-Buffer. Dann wechselt man in den Customization-Buffer und kann dann einfach mit Ctrl-y den Pfadnamen eintragen. Das alles geht dannn letztendlich genauso einfach vonstatten, wie mit der grafischen Oberfläche.

Also, ich als Amateur Java und Datenbank Programmierer bin von Hibernate immer mehr begeistert.

Nachdem ich erst mal die Geschichte mit den JOINS einigermaßen verstanden hatte, war es mir dann fast im ersten Versuch möglich, den richtigen Query zu definieren.

Auf SQL Ebene würde die Abfrage in etwa so aussehen (als Eingabedaten sind die GP7*, PW0* und PP0* Produkt-IDs vorhanden):

 select distinct pf.*
   from parts p,  rlist_to_part rp, platform_to_rlist pr, platform pf
  where p.name in ('GP7B0C1RS', 'GP7E0B1RS', 'GP7E0B1S', 'PP020AP1S',
                   'PP020BP1S', 'PW020CP1S', 'PW020CR1S', 'PW040CS1S',
                   'PW040DR1S', 'PW060CR1S')
        and p.id=rp.part_id
        and rp.rlist_id=pr.rlist_id
        and pr.platform_id=pf.id;

Es werden vier verschiedene Tabellen miteinander verknüpft, die alle vorhanden Daten auf verschiedene Arten miteinander semantisch verknüpfen. Auf JDBC/SQL Ebene müsste ich mich außerdem noch darum kümmern, die Eingabe Daten entsprechend vorzubereiten und das Ergebnis aus dem ResultSet wieder abholen.

Mit Hibernate sieht die analoge Abfrage dann so aus (parts enthält bereits die Liste der Produkt-IDs)

Query query = session.createQuery("select distinct pf "
                                  + "from net.ridderbusch.RLISTManagement.Platform pf "
                                  + "join pf.rlists as rl "
                                  + "join rl.parts as part "
                                  + "where part.name in (:parts)");
query.setParameterList("parts", parts);

Als Ergebnis erhalte ich direkt ein weiter verwendbares Java-Objekt.

Auch für die Migration der Daten aus dem alten System in das Neue mache ich über Hibernate. Ich hatte ursprünglich vorgehabt mittels SQL die Tabellen im neuen System zu füllen, aber dank der vielen zusätzlichen Hibernate-Utilities, die z.B. aus einer Datenbanktabelle die Hibernate-Mapping Datei bauen und aus dieser mit einem weiteren Tool die zugehörigen Java-Klassen, war es letztendlich leichter die Migration über ein eigenes Java-Programm zumachen.

Wirklich alles sehr kühl!!

Und dann bin ich ja doch wieder zu Eclipse gewechselt. Allerdings nicht zur "stabilen" Version 2.1.1, sondern zum Milestone 2 der in der Entwicklung befindlichen Version 3.0. Der Punkt, der mich bei der 2.1er Version gestört hatte, nämlich die Art wie getter/setter-Methoden generiert werden, ist mit 3.0 geändert worden.

Ansonsten waren es die schnellere Grafik, die Möglichkeit mehrere Aufruf-Szenarien für eine main-Funktion zu verwalten und das Import-Management, die mich bewogen haben, doch weiter auf Eclipse zu setzen.

Nach meinen ersten Eclipse Erfahrungen werde ich dann doch wohl bei Netbeans bleiben. Eclipse fühlt sich zwar in Beziehung grafische Oberfläche flotter an und hat aus sonst nette Kleinigkeiten zu bieten, aber Netbeans generiert die besseren Getter/Setter Methoden und hat ein sehr gutes "Autocomment-Feature", um Hilfestellungen bei der Dokumentation von Methoden zu bieten.

Während Eclipse für eine Setter-Methode folgendes Fragment generiert:

/**
 *
 * @param
 */
public void setVariable(String string) {
  variable = string;
}

erzeugt Netbeans

/** Setter for property variable.
 *
 * @param variable New value of property variable.
 */
public void setVariable(String variable) {
  this.variable = variable;
}

Gerade bei diesem kurzen Getter/Setter Methoden finde ich den Stil von Netbeans einfach besser.

Die andere große Stärke von Eclipse ist das Refaktorieren. Hierzu sind diverse Funktionen schon eingebaut, die bei Netbean fehlen. Für mich als Hobbyprogrammierer ist das allerdings keine großes Manko, da ich hier für Netbeans auf RefactorIt ausweichen kann. Bei Verwendung von weniger als 50 Java-Klassen ist dieses Tool frei. Bei mehr als 50 Klassen muß man dann eine Lizenz erwerben. Ich bezweifele, das ich jemals über 50 Klassen kommen werde.

Außerdem finde ich die Hilfe-Funktionen bei Netbeans einfach besser gelungen und es ist ein GUI-Designer vorhanden.

Also, jedes Tool hat seine Stärken. Für mich persönlich aber hat Netbeans augenblicklich mehr Stärken.

Das Eclipse-Projekt hat jetzt die Version 2.1.1 des Java-IDE freigegeben.

Diese neue Version habe ich jetzt nochmal zu Anlaß genommen, mich näher mit Eclipse zu beschäftigen. Was bei meinen allerersten Versuchen irgendwie nicht funktioniert hat, hat jetzt besser funktioniert. Irgendwo hat sich wohl ein Knoten im Gehirn gelöst, sodaß ich die zugrunde liegenden Konzepte jetzt besser verstehe.

Aber so wie ich es sehe, ist Eclipse nicht unbedingt besser als Netbeans, sondern eben anderns. Hier geht es wie bei meiner Suche nach der optimalten Digitalkamera. Manche Funktionen sind in Eclipse besser, andere in Netbeans.

Wenn man sich allerdings im Internet umschaut, scheinen die Präferenzen eher in Richtung Eclipse zu gehen. Insgesamt ist die Community hinter Eclipse stärker.

Ich werde jetzt mal versuchen, den zweiten Teil meiner ECN-Verwaltung mit Eclipse zu implementieren.