Die letzten Tage waren mal wieder sehr anstrengend. Das Projekt, an dem ich gerade arbeite, läuft eher chaotisch, als denn geordnet ab. Zum einem leidet das Projekt darunter, dass es keinen definierten Projektleiter gibt. Alleine dieser Punkt ist schon ein K.O.-Kriterium. Dazu kommt noch, dass es keine Spezifikationen und weitesgehend keine Dokumentation gibt. Als einzige Vorlage dient ein C-Code, der dank wildester Pointer-Arithmetik und einem prozeduralen Programmierstil alles andere als einfach nachzuvollziehen ist. Dies führte dazu, dass ich wesentliche Teile der Logik reverse-engineeren musste.

Schon seit einiger Zeit wollte ich mir die objekt-orientierte Datenbank Db4o für Java ansehen, hat doch diese Datenbank vielerorts von sich reden gemacht. Angespornt durch die Ankündigung, dass die nächste anstehende Version 6.0 Verbesserungen bezüglich des Speicherverbrauchs und der Performance mitbringen soll, habe ich mir also nun endlich einmal Db4o näher angesehen.

Was ist nun der Unterschied zu einer traditionellen relationalen Datenbank, insbesondere in Verbindung mit Hibernate? Nun, der wesentliche Unterschied ist der, dass man sich keine Gedanken darüber machen muss, auf welche Art und Weise man sein Datenmodell in die Datenbank persistieren kann. Man schreibt also einfach sein Datenmodell, erzeugt eine Instanz und speichert diese in der Datenbank ab:

ObjectContainer db = ...
db.set(myObject);

Das war's. Db4o wandert automatisch alle Kind-Referenzen ab und speichert diese ebenfalls. Angenommen man hätte folgende zwei Klassen:

public class Parent {
    private String name;
    private List childs = new LinkedList();     
    public Parent(String name) { this.name = name }
    public void addChild(Child child) {
        childs.add(child);
    }
}

public class Child {
    private String name;
    ...
}

und man würde folgende Instanzen erzeugen:

Parent p = new Parent("parent");
p.addChild(new Child("child 1"));
p.addChild(new Child("child 2"));

so würde Db4o automatisch alle Childs mitabspeichern, wenn man Parent p mit db.set() speichern würde.

Doch wie schaut es mit der Abfrage aus? Db4o unterstützt verschiedene Anfrage-Sprachen (QBE, Native Queries, S.O.D.A), wobei SODA quasi die Low-Level API darstellt. Obwohl Db4o selber die Verwendung von Native Queries empfiehlt, sagt mir die Low-Level API SODA eher zu. Ein paar Beispiele:

Finde ein Parent-Objekt mit dem Namen "parent" :

query.constrain(Parent.class).descend("name").constrain("parent").equal();

Finde ein Parent-Objekt, dessen Child den Namen "child 1" hat:

query.constrain(Parent.class).descend("childs")
    .descend("name").constrain("child 1").equal();

Selbstverständlich sind auch komplexere Anfragen möglich. Sofern es meine Zeit zulässt, werde ich in den folgenden Tagen von meiner praktischen Erfahrung mit Db4o berichten. Der erste Eindruck ist auf jeden Fall schon mal ganz angenehm =)

So Charles has lots of complaints against Eclipse and SWT. He quotes several postings from Javalobby, all saying that SWT on Linux is far too slow. What if the root of the problem wasn't SWT but GTK2? I've heard several people saying that GTK2 has some known speed problems and that these issues will be addressed in the future. I would not say that SWT in general is slow for it has proven excellent speed on Win32. And regarding NetBeans: Personally I think that the UI of NetBeans on MacOS X looks clumsy. Lots of little UI bugs everywhere, wrong menubar placement, silly toolbar L&F and so on.


To me it simply doesn't feel and look like a MacOS X app at all. Eclipse on the other hand feels much more like a native app thanks to SWT. I do not deny that Eclipse has its rough edges. But NetBeans isn't perfect either.

Read this article and you will know =)

Unfortunately it is a little bit tricky to get the default welcome file index.do working with Struts and Jetty. Suppose you have th following web.xml:

...
<welcome-file-list>
  <welcome-file>index.do</welcome-file>
</welcome-file-list>
...

and you have configured the ActionServlet to listen on *.do requests. Then you would assume that

http://some.url.com/index.do

would work? Right? No! I guess the problem is that the default servlet (which handles the welcome-file stuff) looks for the file index.do on the filesystem. Unless there is no such file the ActionSerlvet will never be called.
The trick is to simply add an empty index.do file in the root directory of your WAR. That's it =)