Eclipse aufgeziegelt

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.

XEmacs als Java-IDE reaktiviert.

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.

Hibernate ist ebenfalls ziemlich kühl.

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 doch wieder Eclipse.

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.

Zurück zu Netbeans

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.

Eclipse

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.