In unregelmäßigen Abständen halte ich ja am ZGDV Rostock zwei Seminare: “Perl Grundlagen” und “Perl Aufbaukurs”. Und am 18. und 19.09.2008 war es wieder mal soweit – ein “Aufbaukurs” war angesagt.

Ich hatte mich nach dem leztzten Kurs dazu entscheden, den Abschnitt “Objektorientiertes Perl in 4 Stunden” rauszunehmen und durch einen Exkurs in die Themen “Testen” und “Erstellen einer Distribution” zu ersetzen. Da mir erst wenige Tage vor dem Kurs einfiel, dass ich ein Jahr zuvor die Agenda geändert hatte, war auf den letzten Drücker ganz schön was zu tun!

Aber es hat mir wiedermal viel Spaß gemacht, “meine” Kursteilnehmer schienen auch zufrieden. Und ich hoffe, den Leuten im Kurs mit Testgetriebener Entwicklung von Perl-Modulen so richtig den Mund wässrig geredet zu haben.

Und noch etwas war neu: Statt auf das Duo “Notepad und Kommandozeile” (die Kurse finden an Windows-PCs mit ActiveState Perl statt) habe ich Eclipse mit dem Perlipse-Plugin eingesetzt. Und auch das war eine gute Entscheidung. Wenngleich ich beim nächsten Mal auf E-P-I-C setzen werde – das ist doch schon weiter in der Entwicklung und bietet mehr Funktionalität (wie man sie als Plugin- und Java-Entwickler von JDT und PDE gewohnt ist).

Anbei der PDF-Foliensatz des Kurses und der Eclipse-Workspace mit den Übungen. Versprochen ist versprochen :-)

PS: Ich gehe aus einem solchen Kurs jedes Mal mit so viel Ideen und könnte meine ganze Skriptsammlung überarbeiten … :-)

Abhilfe schaffte das Einsetzen des Schalters -dontusemixedcaseclassnames in der Proguard-Konfiguration, und schon macht Proguard bei der 27. Klasse eines Packages mit "aa.class" weiter. Das sollte m.E. Voreinstellung sein!

Einen interessanten Workaround fand ich bei http://osdir.com/ml/java.sun.kvm/2003-09/msg00083.html :

If you have more than 26 files,create another package and place the rest 26 files and so on.

Klasse!

Die Details zur neuen Version und zur Anwendung des Plugins sind auf der Homepage des Projekts zu finden: http://obfuscate4e.partmaster.de/ ...

Das war ziemlich nervig, weil der Grund dafür nicht lokaloisierbar war und der Fehler sogar auftrat, wenn ich die letzte Release auscheckte und diese nachweislich funktionierende Version nicht funktionierte. Bis ich nun den Fehler gefunden habe:
Beim Testen der Distribution vor der letzten Release habe ich das feature auch mal über unsere Update site installiert. Und zwar in die Extension location, in der ich eigentlich nur das Subversive Feature verwalte. Und wann immer ich ein Eclipse neu aufsetzte und die Subversive-Extension location integrierte, kannte Eclipse auch das (mittlerweile veraltete) proguard-Plugin. Nachdem ich es entfernt und Eclipse einmal neu gestartet hatte, funktionierte alles wieder bestens. Es war also wirklich ein Konfigurationsfehler – 1:0 für Ant.

Gefunden habe ich den Fehler übrigens, als ich in der Eclipse IDE (mit geöffnetem obfuscate4e-Workspace) in den Preferences > Ant > Runtime im Classpath das proguard.jar und in der Tasks-Liste den proguard-Task gelistst sah, den Eclipse zu diesem Zeitpunkt gar nicht kennen durfte. Zum Glück habe ich vergessen zu zählen, wie viele Stunden mich dieser Fehler gekostet hat.

Gerade habe ich ein wenig mit Launch4j (http://launch4j.sourceforge.net/) experimentiert. Es ist ein (sehr leichtgewichtiger) Wrapper für Jar-Aufrufe, d.h. es verpackt ein Jar in einer ausführbaren Windows-Datei (exe), wobei man einige sinnvolle Einstellungen vornehmen kann, z.B.:

• Programm-Icon und Splash,
• Programmname, der auch im Taskmanager auftaucht (statt "java"),
• Verweis auf eine JRE, die automatisch zur Ausführung genommen wird,
• Main-Class, Classpath-Einträge und Kommandozeilenargumente des Jars,
• Registry-Einträge,
• ...

Alle notwendigen Ressourcen werden in eine Exe gepackt, man muss dann nur noch eine JRE hinzupacken und alles zippen – fertig ist die Dist. Und der Overhead ist gering (in dem Zip-Archiv ist noch die 1.4er JRE enthalten):

# l myapp*<br />-rw-r--r-- 1 drue users 13983944 2008-03-18 16:42 myapp-1.0.zip<br />-rwxr-xr-x 1 drue users&nbsp; 1892105 2008-03-18 16:41 myapp.exe*<br />-rw-r--r-- 1 drue users&nbsp; 1858825 2008-03-18 16:41 myapp.jar

Hier ein Beispiel für die Konfiguration, alles XML (ich habe die Launch4J-Dateien im Untervereichnis lib/launch4j abgelegt):

&lt;launch4jConfig&gt;<br />&nbsp; &lt;dontWrapJar&gt;false&lt;/dontWrapJar&gt;<br />&nbsp; &lt;headerType&gt;gui&lt;/headerType&gt;<br />&nbsp; &lt;jar&gt;myapp.jar&lt;/jar&gt;<br />&nbsp; &lt;outfile&gt;myapp.exe&lt;/outfile&gt;<br />&nbsp; &lt;errTitle&gt;My launch4J app&lt;/errTitle&gt;<br />&nbsp; &lt;cmdLine&gt;&lt;/cmdLine&gt;<br />&nbsp; &lt;chdir&gt;.&lt;/chdir&gt;<br />&nbsp; &lt;priority&gt;normal&lt;/priority&gt;<br />&nbsp; &lt;downloadUrl&gt;http://java.com/download&lt;/downloadUrl&gt;<br />&nbsp; &lt;supportUrl&gt;&lt;/supportUrl&gt;<br />&nbsp; &lt;customProcName&gt;true&lt;/customProcName&gt;<br />&nbsp; &lt;stayAlive&gt;false&lt;/stayAlive&gt;<br />&nbsp; &lt;manifest&gt;lib/launch4j/manifest/xp-themes.exe.manifest&lt;/manifest&gt;<br />&nbsp; &lt;icon&gt;resources/myapp.ico&lt;/icon&gt;<br />&nbsp; &lt;jre&gt;<br />&nbsp;&nbsp;&nbsp; &lt;path&gt;jre&lt;/path&gt;<br />&nbsp;&nbsp;&nbsp; &lt;minVersion&gt;1.4.0&lt;/minVersion&gt;<br />&nbsp;&nbsp;&nbsp; &lt;maxVersion&gt;&lt;/maxVersion&gt;<br />&nbsp;&nbsp;&nbsp; &lt;jdkPreference&gt;preferJre&lt;/jdkPreference&gt;<br />&nbsp; &lt;/jre&gt;<br />&nbsp; &lt;splash&gt;<br />&nbsp;&nbsp;&nbsp; &lt;file&gt;resources/splash.bmp&lt;/file&gt;<br />&nbsp;&nbsp;&nbsp; &lt;waitForWindow&gt;true&lt;/waitForWindow&gt;<br />&nbsp;&nbsp;&nbsp; &lt;timeout&gt;60&lt;/timeout&gt;<br />&nbsp;&nbsp;&nbsp; &lt;timeoutErr&gt;true&lt;/timeoutErr&gt;<br />&nbsp; &lt;/splash&gt;<br />&lt;/launch4jConfig&gt;

Für die Konfiguration wird auch eine GUI mitgeliefert. Der Screenshot ist unten angehängt. Die JRE wird im Unterverzeichnis JRE erwartet.

Die Integration von Launch4J in ein Java-Projekt mit Ant und build.xml ist auch ganz einfach. Launch4J bringt einen Ant-Task mit, der im Build-Skript angemeldet werden muss:

&lt;target name=&quot;exe&quot; depends=&quot;jar&quot; description=&quot;Create a selfcontaining executable&quot;&gt;<br />&nbsp;&nbsp; &lt;taskdef name=&quot;launch4j&quot; classname=&quot;net.sf.launch4j.ant.Launch4jTask&quot;<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; classpath=&quot;${launch4j.dir}/launch4j.jar:${launch4j.dir}/lib/xstream.jar&quot; /&gt;<br />&nbsp;&nbsp; &lt;launch4j configFile=&quot;${basedir}/myapp.xml&quot; /&gt;<br />&lt;/target&gt;

Nun gibt es ja noch das EclipseNSIS-Projekt zum Erstellen eines Installers für Eclipse-Anwendungen. Der Launch4J-Ansatz kann gewählt werden, wenn für das Projekt kein Installer benötigt wird und der Aufwand für Entwicklung und Testen der Installation so minimal bleibt. Mit Launch4J liefert man ein Zip-Archiv. Und das war in einer Stunde erstellt.

You might ask: What’s an obfuscator? In Java a obfuscator is used to prevent program code from reverse engineering. It removes unneccesary debugger information, shrinks variable and method names (means: makes them senseless). Modern obfuscators additionally remove code that would be obfuscated but is never called from somwhere.

The project obfuscate4e adds the obfuscation facilities into the build process of Eclipse plugins. During the export of plugins or a product the code will be obfuscated automaticly and the product can be delivered to the customers without further post processing.

This release has built-in support for ProGuard, an Open Source Java obfuscator. In the future additional obfuscators will be integrated and the customization possibilities will be improved.