Integration von Java Anwendungen in Mac OS X

Java Anwendungen laufen auf fast jeder Plattform, der Mac ist hier keine Ausnahme. Aber der Mac ist nicht nur was besonderes sondern er ist auch ein bisschen anders. Eine normale, unangepasste Java Anwendung sieht wie folgt aus:

Baralga Zeiterfassung auf dem Mac

Was dem Mac-User auffällt ist, dass das Menü im Fenster und nicht wie Mac-üblich in der Menüleiste untergebracht ist. Um dies zu ändern muss ein Property-Wert gesetzt werden, dies kann in der Kommandozeile beim Aufruf des Programm passieren oder im Code. 

   java -Dapple.laf.useScreenMenuBar=true -jar baralga-core-1.4.4-SNAPSHOT.jar

Alternativ kann man in der Klasse die die Main-Methode enthält folgende Zeile einfügen:

static {

   System.setProperty("apple.laf.useScreenMenuBar", "true");

}

Dieser Code wird beim Erzeugen eines Objektes dieser Klasse ausgeführt und der Property-Wert gesetzt.  Das Ergebnis sieht dann wie folgt aus:

Noch besser wird es wenn man folgendes Argument mit übergibt:

   -Xdock:name="Alif" 

Es wird damit der Name der Applikation gesetzt. Dies führt dazu, dass nicht die Javaklasse in der Menüleiste auftaucht sondern der Applikationsname. Dies gilt auch für Dock. Wenn man einen Mac zur Verfügung hat kann man es sich einfacher machen, in dem man den Jar Bundler benutzt. Dieser ist ein Werkzeug, dass mit Apples Xcode installiert wird. Leider ist es nicht separat zu finden. Mit Hilfe des Jar Bundlers lassen sich aus Java-Applikationen einfach Doppel-Klick-bare Anwendungen bauen. Naürlich kann sind auch richtig gebaute JARs Doppel-Klick-bare Anwendungen,  mit Hilfe  des Jar Bundlers kann man alle Mac OS X spezifischen Einstellungen vornehmen. Für den Fall das, die Java-Anwendung kein sogenanntes Big-JAR ist, kann man die benötigeten JARs auch mit Hilfe des Jar Bundlers hinzufügen. Leider fügt der Jar Bundler nur absolute Pfade in die entsprechende Datei (Info.plist) ein. Man kann jetzt die abhängigen Bibliotheken mit in Paket kopieren z.B. unter Contents/Resoures/Java/lib. DAnach muss man nur noch die Pfade in der Datei Info.plist korrigieren und die absoluten Pfade ersetzen. Dazu kann man z.B. JEdit benutzen:

   $JAVAROOT/lib/commons-lang-2.4.jar

Die Variable JAVAROOT gibt den vollständigen Pfad zum Verzeichnis an, in dem die eigentliche JAR meines Programms liegt, also /Application/Baralga/Baralga/Contents/Resource/Java.

Datenbank-Ressource in Tomcat einbinden

Das das verwenden von Connection Poos eine tolle, Performance steigernde Sache ist hat sich sicher herumgesprochen. Nun gibt es verschiedene Möglichkeiten einen DB Connection Pool zu benutzen. Man kann natürlich auch selber entsprechende Logik in eine zentralen Datenbankklasse implementieren. Bei Serversoftware ist eher davon abzuraten, weil man dann das Connection Management komplexer wird. So schliesst die Datenbank von ihrer Seite aus eine Connection nach einer festgelegten Zeit der Inaktivität um Ressourcen zu sparen, bei MySQL sind dass 8 Stunden, d.h. wenn 8 Stunden lang keine Daten über die Datenbank Connection geflossen sind schliesst die Datenbank die Verbindung. Dies bemerkt man in der Regel erst am nächsten Tag oder am Montag, wenn man versucht Daten von Datenbank zu holen. Die Lösung lautet, man muss immer prüfen ob die Connection noch funktioniert, das macht man in dem man eine Datenbankabfrage macht, die immer ein definiertes Ergebnis liefert. Das prüfen der DB-Connection reicht nicht.

Zurück zum Pooling, Tomcat bietet ein eigenes Pooling mittel Tag resource. Das sieht in der Datei META-INF/context.xml der Webapp wie folgt aus:

<Resource

name="jdbc/MYSQLDB"

auth="Container"

type="javax.sql.DataSource"

username="smartblu"

password="xxx"

url="jdbc:mysql://localhost:3306/igd"

driverClassName="com.mysql.jdbc.Driver"

maxActive="500"

maxIdle="100"

maxWait="10000"

validationQuery="select count(*) from USER"

removeAbandoned="true"

logAbandoned="true"

/>

Mit validationQuery gibt man die oben erwähnte Wartungsabfrage an, mit der DB-Connection-Pool die Datenbankverbindung testen kann. Was jetzt noch fehlt, ist die Referenzierung der Datenbankressource in der Datei web.xml.

<resource-ref>

<description>DB Connection</description>

<res-ref-name>jdbc/MYSQLDB</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<res-auth>Container</res-auth>

</resource-ref>

Dependency Management mit Ant

Genau. Einer der oft genannten Vorteile von Maven im Vergleich zu Ant ist das Dependency Management. D.h. in Maven muss man nur angeben welche Bibliotheken man für das Softwareprojekt braucht und Maven lädt die JARs dann automatisch aus dem Internet und legt sie im lokalen Repository ab. Bei Ant muss man die JARs selber laden und verwalten. Dies ist nicht notwendig wenn Apache Ivy eingesetzt wird. Ivy übernimmt das Dependency Management bei Ant-Projekten. Das schöne an Ivy ist die Kompatibilität zu Maven. Die Beschreibung der Bibliotheken erfolgt nach dem gleichen Prinzip und benutzt auch das zentrale Maven Repository. Aktuell gibt es bei IT Republik einen Artikel zu Ivy.

Brownfield Projekte

Nicht alle Projekte starten auf einer grünen Wiese oft oder meistens beziehen sich Projekte auf vorhandene Software, den so genannten Brownfield Projekten. Wie kann man trotz dieser existierenden und oft laufenden Software die Grundsätze der CCD (Clean Code Developer). Mit diesem Thema beschäftigen sich zwei Artikel auf Heise Developer. Ich denke vielen Entwicklern werden einige Dinge bekannt vorkommen.

Maven vs. Ant

"Maven - eine Ausgeburt der Hölle", das ist ein toller Aufmacher von JAXenter. Das Zitat stammt von Kent Spillner, aus diesem Artikel. Interessant ist, dass Ant zumindest das zweit beste Build-Tool ist. Was sich dahinter versteckt, ist ein tiefer Frust über Maven. Maven sollte das Leben und den Build vereinfachen. Mein Urteil ist noch nicht gefällt. Auf jeden Fall sollt man diesen Blog-Eintrag lesen, oft habe ich mit dem Kopf genickt. Maven bringt aber noch andere Probleme mit sich, die zum Teil aus der Transparenz der Vorgänge in Maven herrühren. Das Dependency-Management ist einer der Argumente für Maven. Mein erstes Problem, wie heisst das Artefakt. Ausserdem lädt das Depency-Management alle möglichen Pakete, egal ob ich sie nötig sind oder nicht. Die Frage ist das ein Problem oder nicht, ich merke davon nichts und ich hab' keinen Einfluss drauf. Doch da fällt mir ein Nachteil ein, wenn ich Web-Applikationen entwickle und deploye muss ich ein grösseres WAR-transferieren, das kostet mehr Zeit und was das für bedeutet, kann man bei Joel Splonsky nachlesen.

Ein Kritikpunk von Kent Spiller, dass das Maven-Paradigma "Convention over Configuration" bei fast jeder Anforderung an den Build-Prozess nicht stimmt kann ich nachvollziehen, vor allem bei grösseren Projekten. Meine Idee ist es Projekte stärker zu modularisieren und jedes einzelne Projekt mit Maven zu realisieren. Vorteile sind überschaubare, wenig modifizierte (konfigurierte) POMs. Am besten man richtet dann auch gleich ein eigenes Remote-Repository ein, wie in diesem Blog beschrieben. D.h. benutze Maven bei grossen, modularen Projekten, sonst nehme lieber Ant.

Aber es ist schon ein Ärgernis, dass man bei Maven so viel konfigurieren muss und dass die Dokumentation spärlich ist. Ein andere Tipp ist, komplexere Anforderungen via Ant zu realisieren.

Fehlende Einträge

Hier meine unvollständige Liste noch fehlender Einträge. Ich nehme noch gerne Vorschläge für weitere Artikel entgegen.

• Security, Rolls in Tomcat
• Performancevergleich von Webservices im Vergleich zu reinem HTTP
• Optimierter Code
• DB Zugriffe
• XSL
• SCORM
• Automatisierung, Konsistenz

Joel on Software

Es ist schon erstaunlich, dass viele Entwickler ähnliche Probleme haben, zumindest die Guten :-D. Hier ein interessanter Blog: Joel on Software von Joel Spolsky. Joel Spolsky ist ein ehemaliger Fallschirmjäger und Microsoftentwickler. Ob es zwischen diesen Fähigkeiten einen Zusammenhang gibt? In dem Blog geht es um gutes und natürlich schlechtes Projektmanagement aber auch um Programmierdinge (z.B. Blähsoftware, Bytes oder der Joel-Test). Einige Beiträge von 2000 bis 2009 sind auch auf Deutsch verfügbar. Man kann auch bei der Übersetzung helfen. Spontan meine liebste Stelle:

...

Aber ich mache mir nicht über die Tage Sorgen, an denen ich "nur" zwei Stunden arbeite. Es sind die Tage, an denen ich gar nichts tue.

...

Interessant ist auch der Joel-Test, obwohl er schon fast 10 Jahre alt ist, erfüllen immer noch nicht alle Softwarefirmen den Test. Selbst wenn man den Test nicht kennt, so ist sein Inhalt doch für alle guten Programmierer keine Überraschung sondern sollte der Normalfall sein.

Die Forderung des Test eines One-Click-Build passt gut zu Maven und Ant und zu diesem Blog. Ja und ich habe einen zweiten Monitor.