Never Ending Baustelle

So, I have Swing, 2nd Edition sitting on my desk. After some extended period of time without any serious programming I thought it was time to start something new. The environment I’ve been working in lately at work was mostly concerned with command line tools, so I thought it would be nice, if I could whip up some small GUI front end.

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.

In my current project, I have a test configuration with about 20 Intel servers running Linux ranging from 933MHz PIII (blades) to 2.4/3 GHz P4’s. This configuration is connected to the company LAN with a IPCop router, which hides the multiple servers from the rest of the network.

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’ve just installed the latest Eclipse 3.0RC1 on my Gentoo Linux PC and apart from other plugins I also installed EclipseColorer 0.6.0 plugins. However each time I selected the Colorer preferences, I received the error dialog in the picture. Try as I might, I couldn’t get it to work. Only, when I finally straceed a Eclipse startup, that I found a hint what causes the problem.

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.

Wenn man Java hantiert, braucht man hin und wieder auch die Kommandozeile, um vielleicht etwas auf die Schnelle auszuprobieren. Allerdings ist die Konstruktion des CLASSPATH, dann schon mit etwas Mühe verbunden.

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.

Hier schien die Geschichte mit Struts ja noch so einfach zu sein, aber ausgehend von meiner konventionell implementierten Version habe ich die analoge Funktionen mit Struts in fast drei Tagen noch nicht zum Laufen gebracht. Als letzte Vermutung hoffen ich, das es daran liegt, das ich eine praktische leere Struts-Action verwende, weil ich mich zuerst auf das Formular und die zugehörige JSP-Seite konzentrieren wollte. Vielleicht habe ich da zuviel aus der Action herausgeschnitten.

Struts hat nun doch gezündet. Ich weiß auch nicht, aber bei Lesen des "Struts in Action" Buches habe ich irgend wie auf meinen Gehirnwindungen gesessen. Beim Lesen war alles irgendwie glasklar, aber beim Übertragen auf meine eigene Anwendung hat es dann an der entscheidenen Stelle ausgesetzt.

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