Well, the Swing book is a really thick book. I’ll see, if can I make it the whole way through. I’ve decided to use Eclipse as my IDE after having mostly worked with Netbeans 3.6 until now. I will also type all of the examples myself in to the IDE and not use the downloadable source code, at least for the shorter examples. I feel, that although this is a somewhat tedious task, it helps to get certain idioms and expression into your head just as it helps to memorize some vocabulary if you copy from the book by hand.

Now, since my desktop PC is only an elderly 500MHz PIII, I decided to try how Eclipse and Netbeans would feel over the network and installed both IDE’s on a 2.4GHz P4. I ssh’ed into the system, set DISPLAY to my PC and started Eclipse and Netbeans in turn and loaded some simple Java code.

The result is, that Netbeans is practically unusable. Even the simple redraws of the IDE screen after it was hidden by another window takes seconds. Also paging in the code is veryyyy slow. The Netbeans installation on my local PC is definitely preferable. Eclipse on the other hand felt quite snappy over the network probably due to the underlying GTK+ implementation of SWT. The processing advantage of the 2.4GHz P4 compared to my 500MHz PC really comes through. I don’t know how it would be with a serious project, but since I’m not a professional programmer and therefore the programming project are quite small, I think it’s really a workable setup for me.

I used this command for tracing:

strace -f -o /tmp/trace -e trace=open /opt/eclipse/eclipse

And a "grep colore /tmp/trace" showed me this (slightly formatted):

open("/opt/eclipse/plugins/net.sf.colorer_0.6.0/colorer.jar",
     O_RDONLY|O_LARGEFILE) = 6
open("/opt/eclipse/plugins/net.sf.colorer_0.6.0/os/linux/x86/libnet_sf_colorer.so",
     O_RDONLY) = 6
open("opt/eclipse/plugins/net.sf.colorer_0.6.0/colorer/catalog.xml",
      ^ 
      O_RDONLY) = -1 ENOENT (No such file or directory)
open("/root/.colorer5catalog", O_RDONLY) = 6
open("/usr/share/colorer/catalog.xml", O_RDONLY) = -1 ENOENT
     (No such file or directory)
open("/usr/local/share/colorer/catalog.xml", O_RDONLY) = -1 ENOENT 
     (No such file or directory)
...

There’s a missing "/" before the "opt" in the third line and this is, what’s causing the problem. Once I changed my working directory to "/" it worked perfectly. In the end I symlinked colorer-directory from inside the Eclipse colorer-plugin directory to /usr/share.

Ich habe jetzt folgendes Snippet im Start-Script des Servlet-Containers Jetty gefunden:

ls -1 /usr/local/java/lib/*.jar|paste -s -d:

Und das im Zusammenhang mit einem entsprechenden Java-Aufruf:

java -cp $(ls -1 /usr/local/java/lib/*.jar|paste -s -d:) class

Diese Anwendung des paste-Kommandos war mir bisher noch nicht bekannt. Der ":" kann auch für Windows leicht mit einem ";" ausgetauscht werden. Oder in die Pipeline kann auch noch ein egrep -v eingeflochten werden, um bestimmte Dateien zu entfernen.

Na, der Knoten ist jetzt jedenfalls gelöst und damit sollte es jetzt zügiger voran gehen.

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.

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!!

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.