Service Geist

Yepp, ja, ich weiss, ich sollte endlich mal eine fertige Version rausbringen und dann anfangen auf jedes (exotische *duck_und_weg*) Betriebssystem zu portieren. Aber ich habe irgendwie so ein wenig rumgedaddelt vorm Rechner und dachte mir ich könnte ja mal Ubuntu runterladen für VMWare Fusion. Gesagt, getan!

Naja, Eclipse war fix installiert und iPlode lief – nach anpassen der SWT-Libraries – out of-the-box, was mich wieder zu meiner Überschrift bringt: Java ist doch was Feines.

Der Plan ist aber immer noch am Wochenende ein wenig Zeit zu investieren, um die ersten Downloads klar zu machen. Ok, jeder der Software entwickelt weiss ja wie das so ist mit den Plänen, aber noch steht der Plan :-).

Bei dem Versuch unter Mac OS mit Eclipse ein Runnable JAR File zu exportieren bin ich heute auf ein Problem gestossen. Der Export an sich klappt problemlos, doch wenn man das JAR dann gestartet hat – eine SWT Applikation – war die Applikation langsam bis hin zur Unbrauchbarkeit.

Da dieses Problem nicht auftritt wenn die Applikation aus Eclipse heraus gestartet wird, habe ich im Terminal ein wenig mit ps gespielt und herausgefunden, dass Eclipse per default die folgenden Java Option setzt -XstartOnFirstThread. Startet man das Runnable JAR direkt (per Doppelklick) fehlt diese Option.

Dieses Problem wird auch im SWT FAQ behandelt, aber das habe ich erst hinterher gefunden ;):

Q: On Mac Carbon, how do I run an SWT application from the command line?
A: If you run a Java application that uses Carbon via JNI, the application is not registered with the OS as a ‘normal’ UI application. As a consequence, it has no entry in the dock and it cannot be activated. AWT (or Swing) based applications don’t have this problem because they seem to use undocumented SPI to register themselves.
To work around this problem you’ll have to pass the -XstartOnFirstThread option to the java executable as follows:

java -XstartOnFirstThread -cp swt.jar:. ControlExample

If you want to run a bundled application, take a look at this article.

Zum Glück führt das FAQ dann auch direkt zu diesem Artikel, der beschreibt wie man aus einem Runnable JAR ein Mac OS Bundle machen kann. Das ist genau die Information, die mir noch gefehlt hat und das werde ich natürlich vorm Release von iPlode noch ausprobieren und dann berichten; ich hoffe vielmehr man kann das Ergebnis dann hier bewundern :).

Vor einiger Zeit – genau genommen in einer Zeit vor diesem Blog ;) – habe ich mich mal intensiv nach frei verfügbaren UML-Editoren umgeschaut. Nachdem ich durch die Arbeit Rational Rose kennen und “hassen” gelernt hatte, war ich auf der Suche nach einer besseren Alternative. Idealerweise sollte diese für Freizeit-Projekte frei verfügbar sein. Nach einigem Stöbern bin ich schliesslich auf Visual Paradigm gestossen.

Wenn man sich von der etwas überfrachteten Webseite nicht abschrecken lässt und auch nicht von dem nötigen Account für den Download bekommt man ein auf Eclipse basiertes UML-Tool, welches einen sehr guten Eindruck macht. Für nicht-kommerzielle Projekte gibt es eine Community-Version mit eingeschränkter Funktionalität. Die folgende Übersicht zeigt alle möglichen Editionen und Preise. Einen Feature-Vergleich der verschiedenen Editionen findet man hier.

Um ein paar Gedanken (UML-technisch) zu ordnen oder auch einfach nur zum Ausprobieren ist Visual Paradigm schon in der Community-Version gut zu gebrauchen. Wer täglich mit Eclipse arbeitet wird den Einstieg als noch einfacher (intuitiver) empfinden.

Leider finden sich die richtig geilen Features, die auch einen eher agilen Entwicklungsansatz unterstützen würden, erst ab der Professional Edition. Diese ist mit knapp $840 dann doch etwas teuer für den privaten Gebrauch. Ab dieser Version gibt es dann das “Java Round-trip” Feature. Damit lässt sich sowohl Java-Code aus dem Model generieren, als auch das Model aus dem Java-Code. Somit würde sich zumindest der aktuelle Stand dokumentieren lassen. Manchmal ist ja dann der Blick auf ein UML-Diagramm schon hilfreich, um die Klassenstruktur besser zu verstehen. Wenn im neuen Jahr ein wenig mehr Zeit am Stück ist, werde ich dieses Features mit Hilfe einer Evaluierungs-Lizenz nochmal näher unter die Lupe nehmen.

Von Java war bisher in diesem Blog noch nichts zu lesen, aber irgendwann ist immer das erste Mal :). Der Weihnachtsurlaub ist da und damit auch mal wieder Zeit kleinere private Projekte weiter voran zu treiben. Eines dieser Projekte ist – neben diesem Blog – ein Strategiespiel. Dieses entwickle ich in Java und für das GUI habe ich mich – nach einigen Recherchen – für das Standard Widget Toolkit (SWT) von Eclipse entschieden. Nicht ganz so portabel wie Swing/AWT, aber dafür haben die Applikationen wirklich das native Look & Feel des jeweiligen Betriebssystems. Mit Mac OS, Windows und Linux als unterstützte Plattformen habe ich auch nicht wirklich ein Problem mit der Portabilität.

Mein Problem ist eher, dass ich im Urlaub nicht immer Online sein kann und deswegen eine Offline-Version der entsprechenden SWT API-Documentation gesucht habe. Vielleicht habe ich falsch gesucht, aber ich bin nicht fündig geworden (google war hier mal nicht mein Freund ;)). Und auch die Version, die Eclipse bereit stellt beinhaltet keine Sourcen und daher auch kein JavaDoc.

Die Suche nach den passenden SWT-Sourcen auf der Eclipse Homepage gestaltet sich dabei etwas schwieriger, aber am Ende bin ich dann doch fündig geworden (passenden Download-Link am Ende der Seite auswählen). Dieses Package beinhaltet die kompletten Sourcen in einem File src.zip. Von hier an habe ich einen recht klassischen Weg gewählt, um an die Offline-Version der API-Doku zu kommen. Nach dem Auspacken des src.zip Files findet man unter org/eclipse/swt alle Quelldateien.

Nach ein wenig Kramen im Gedächtnis und Ausprobieren war das passende javadoc-Kommando zusammengebaut. Vorher noch ein javadoc-Verzeichnis anlegen und es kann los gehen. Das folgende Kommando läuft so unter Unix (in diesem Fall Mac OS), sollte aber mit leichten Anpassungen auch problemlos unter Windows laufen. Die Pfade müssen natürlich in jedem Fall angepasst werden.

javadoc -d /Users/thomasjaspers/Java/Lib/swt-3.4.1-carbon-macosx/javadoc -sourcepath /Users/thomasjaspers/Java/Lib/swt-3.4.1-carbon-macosx/src/ org.eclipse.swt.accessibility org.eclipse.swt.awt org.eclipse.swt.browser org.eclipse.swt.custom org.eclipse.swt.dnd org.eclipse.swt.events org.eclipse.swt.graphics org.eclipse.swt.internal org.eclipse.swt.layout org.eclipse.swt.opengl org.eclipse.swt.printing org.eclipse.swt.program org.eclipse.swt.widgets org.eclipse.swt

Danach ist die API-Documentation im javadoc-Verzeichnis verfügbar und kann mit einem Klick auf index.html lokal gestartet werden. Das Ganze ist zumindest ein Weg an die passenden Dokumentation zu kommen. Für Tips wenn es noch einfachere Möglichkeiten gibt (z.B. direkt in Eclipse) bin ich auf jeden Fall dankbar. Aber für den Urlaub reicht erstmal die LowTech Lösung :).