Alex Online Today

Kurz nach Vorstellung des neuen Macbook Air hat Apple auch ein Update für Java veröffentlicht. In den release Notes ist folgendes prominent an erster Stelle zu lesen:

As of the release of Java for Mac OS X 10.6 Update 3, the version of Java that is ported by Apple, and that ships with Mac OS X, is deprecated.
This means that the Apple-produced runtime will not be maintained at the same level, and may be removed from future versions of Mac OS X. The Java runtime shipping in Mac OS X 10.6 Snow Leopard, and Mac OS X 10.5 Leopard, will continue to be supported and maintained through the standard support cycles of those products.

darauf hat mich vorhin ein Artikel auf heise.de aufmerksam gemacht.

Welche Bedeutung hat die Java Runtime auf der Mac Plattform? Einige Fakten

- Die Java Runtime dient als Grundlage für viele Anwendungen, von denen einige auch nur deshalb für den Mac portiert wurden, da sich durch die Verwendung von Java der Aufwand in Grenzen hält.
- Besonders beliebt war Java auf dem Mac auch deshalb, weil es stets mit dem Betriebsystem mitgeliefert wurde. Bis heute ist die JRE auf jedem Mac vorinstalliert.
- Die gute Integration erlaubt, dass viele Java Anwendungen optisch nicht von Cocoa Anwendungen (der nativen Mac Umgebung) zu unterscheiden sind.

Die Alternative
- z.B. für Windows wurde die Java Runtime immer von Oracle bzw. Sun entwickelt.
- Das Open Source Projekt SoyLatte bietet schon seit langem aktuellere Releases des JDK für die Mac Plattform (insbesondere relevant für Entwickler).

Die möglichen Gründe für Apple von der eigenen Runtime abzuweichen?
- Apple möchte den Mac als Anwendungsplattform geschlossener gestalten und versucht zukünftig ausschließlich auf Cocoa zu setzen.
- Apple sieht in der Entwicklung von Java auf Clientseite keinen so großen Nutzen mehr und hofft auf andere Anbieter (Oracle, Open Source Community).
- Apple ist von der neuen Abmahn-Politik Oracles eingeschüchtert und möchte einen Rechtsstreit verhindern.

Was bedeutet das für die Zukunft von Java auf dem Mac?

Hier sind verschiedene Szenarien möglich, manche machen den Mac für Java Entwickler und High-End User sehr uninteressant. Aber Ich kann mir nicht vorstellen, dass Apple es sich unbedingt mit der (Java-) Entwicklergemeinde verscherzen möchte, schließlich gibt es hier viele Zusammenhänge auch zur Mac Entwicklergemeinde und der Mac als Entwicklungsplattform hat gerade in letzter Zeit enormen Zuwachs erfahren.

1. Szenario: Apple möchte den Mac als Anwendungsplattform geschlossener gestalten und versucht zukünftig ausschließlich auf Cocoa zu setzen.
Folge: Im App Store werden keine Java Applikationen zugelassen. Zu erwarten ist dann allerdings, dass Oracle relativ schnell eine eigene und auch möglichst gute Runtime zur Verfügung stellen wird, um Apple gegenzusteuern. Könnte für Apple nach hinten losgehen, weil man erstens die Entwickler verärgert und zweitens nicht wirklich etwas erreicht.

2. Szenario: Apple hat schon seit einiger Zeit sehr zögerlich neue Java-Versionen übernommen. Offenbar hat man einfach die Lust daran verloren und hofft, Oracle oder OpenSource Projekte wie SoyLatte werden zukünftig die Arbeit übernehmen.
Folge: Genau das passiert auch, eine Verzögerung ist jedoch vorerst nicht auszuschließen. Die Folgen sind besonders schlimm, denn von Oracle oder der Open Source community sind keine derartig guten Integrationen der JRE in Mac OS zu erwarten, wie wir sie momentan kennen. Dies könnte Java auf dem Mac tatsächlich gehörig schaden.

Die Zukunft von Java wird auch für Mac OS eine wichtige Rolle spielen. Ich persönlich als Entwickler würde mich eventuell von Apple trennen, wenn zukünftig keine ordentliche JRE mehr aufzutreiben ist. Denn selbst wenn ich auf einige Javaprogramme verzichten könnte, so basieren doch die alle Eclipse-Derivate ebenso auf Java. Das SKD alleine reicht zum Entwickeln leider nicht aus.

Leider unterstützt die hervorragende Backuplösung von Apple – Time Maschine – keine FAT32 formatierten USB Sticks als Quellmedien. Gerade bei diesen kleinen Dingern ist die Wahrscheinlichkeit eines Verlustes jedoch besonders hoch, weshalb man entweder gar keine kritischen Daten darauf speichern, oder regelmäßig Backups erstellen sollte.

Mein Ziel: Bei jedem Anstecken des USB Sticks wird der gesamte Inhalt automatisch via AppleScript und rSync auf ein Verzeichnis auf meinen Mac kopiert. Vor korrupten Dateien schützt mich dann das automatische Time Maschine Backup.

Ich bin natürlich nicht der erste, der sich mit der Thematik befasst. Im Internet fand  zwei etwas angestaubte Einträge, einer beschrieb eine Lösung mit AppleScript und dem Tool “Do Something When” [Link1], der andere mit einer FolderAction im Volumes Verzeichnis und einem Script auf jedem USB Stick [Link2]. Wem meine Lösung nicht gefällt, der wird eventuell dort glücklich.

Der Ansatz mit der FolderAction und einem Script auf dem USB Stick gefällt mir am besten. Allerdings habe ich das Script ein wenig für meine Bedürfnisse angepasst, da ich das Archivieren der Daten im Endeffekt Time Maschine überlassen möchte. Ausserdem habe ich eine Abfrage eingebaut, denn das Script startet in der ursprünglichen Form beim Anschließen eines Datenträgers ohne Rückfrage das Script rsync.app vom Stick, was Sicherheitstechnisch bedenklich ist.

Also folgend meine Lösung: (Der Code wurde größtenteils von hier kopiert und modifiziert)

Teil 1: Das Folderaction Script:

property backup_script : "rsync.app" (* add/change this string to match the name of your script *)
 
on adding folder items to this_folder after receiving these_volumes
tell application "Finder"
try
set the volume_list to every file of this_folder
 
(* go through all entries in /Volumes/ *)
repeat with i from 1 to number of items in volume_list
set this_item to the original item of item i of volume_list
if the kind of this_item is "Volume" then
set this_disk to (this_item as alias)
 
(* is this item the newly mounted disk? *)
if this_disk is in these_volumes then
 
(* iterate through all files in the root of disk *)
set searchCmd to "ls -d " & quoted form of POSIX path of this_disk & backup_script
(* check to see if a backup script is available *)
set searchResult to ""
try
set searchResult to do shell script searchCmd
end try
(* run the backup script *)
if (searchResult starts with "/Volumes") then
set backupFile to POSIX file searchResult as alias
display dialog "Backupscript auf Volume gefunden, backup ausführen?" buttons {"JA", "NEIN"} default button 2 with icon stop
if button returned of result is "NEIN" then return
open backupFile
end if
 
end if
end if
end repeat
on error error_message number error_number
if the error_number is not -128 then
display dialog error_message buttons {"OK"} default button 1
end if
end try
end tell
end adding folder items to

1. Kopiere das Script in den Script Editor

2. Speichern als… “Script” unter /Library/Scripts/Folder Action Scripts/

3.-  Mit 10.6 und folgenden: Öffne im Finder die Systempartition

Rechtsklicke auf /Volumes und wähle im Kontextmenü Folder Action Setup

- Mit 10.5 und früher: Öffne den Finder und wähle Gehe zu Ordner > /Volumes/

Öffne Folder Actions Setup (aus dem Dienstprogrammen)

Dragge das Ordnericon aus der Titelleiste des Finder Fensters auf das geöffnete Formular und klicke OK

4. Wähle im Dialogfenster das gespeicherte Script aus.

Teil 2: Das Script auf dem Datenträger

property display_notification : false
property backup_target : "Documents/Backups/" (* MUST be a folder location with trailing slash! Always relative to home folder *)
 
property rsync_params : "-aEz --delete-excluded"
(* END OF PREFERENCES *)
 
set WhereImRunningFrom to path to me
tell application "Finder"
 
(* NEVER run from the hard drive! comment: nice feature, thats why it stays!*)
set bootVolume to name of disk of home (* safety feature! *)
set NameOfDisk to name of disk of WhereImRunningFrom
if NameOfDisk is bootVolume then
beep
display alert "Should not run this script from the boot volume!"
return
end if
 
(* setup backup dir *)
set homeDir to path to home folder from user domain
set backup_folder to POSIX path of homeDir & backup_target
try
(* quick and dirty check to see if folder exists - must be a good way to do this in applescript? *)
do shell script "cd " & backup_folder
on error
try
do shell script "mkdir " & backup_folder
on error
display alert "There was an error creating the backup folder " & backup_folder
return
end try
end try
 
(* find source and target *)
set backupBase to NameOfDisk & "-Backup"
set targetDir to backup_folder & quoted form of backupBase
set sourceDir to quoted form of ("/Volumes/" & NameOfDisk & "/")
end tell
 
(* do the backup *)
 
set excluded to " --exclude='.Trash*' --exclude='.Spotlight*'  "
 
set theScript to "rsync " & rsync_params & excluded & sourceDir & " " & targetDir & "; touch " & targetDir
 
do shell script theScript
 
activate of me
beep
if display_notification then display alert NameOfDisk & " drive backed up"

1. Kopiere das Script in den Script Editor

2. Ändere die Konstante backup_targets, beachte dass das Script keine Adminrechte hat und deshalb nur in den Benutzerordner speichern kann!

3. Speichere das Script auf dem USB Stick als Application mit dem Namen rsync.app (oder dem Namen, der im anderen Script angegeben ist).

4. Teste ob es funktioniert! Beim erneuten Anschließen des USB Sticks sollte eine Warnung erscheinen, die fragt ob ein Backup erstellt werden soll.

Wer einmal an einem Rechner in der Fremde arbeiten durfte, hat sicher erlebt, dass die Layouts der Tastaturen auf der ganzen Welt leichte bis mittelschwere Unterschiede aufweisen. Oft nervt das einfach nur, bei genauerer Betrachtung gibt es aber durchaus Layouts die Vorteile mit sich bringen. Während ich z.B. dem amerikanischen Layout relativ wenig abgewinnen kann (aufgrund der seltsamen Enter Taste), bin ich ein großer Fan des britischen Layouts. Deshalb bin ich jetzt umgestiegen. Einziges Problem für mich: Ich kann mich nicht an die Z/Y – Vertauschung gewöhnen, zumal ich abwechselnd auch immer deutsche Tastaturen verwende und: Schreiben der Umlaute mit Alt + U + Buchstabe ist mir definitiv zu umständlich.

Mac OS bietet  jedoch eine recht simple Lösung. Seit OS 10.2 unterstützt Mac OS das Verwenden eigener Unicode Layouts. Das Layout wird im XML Format gespeichert.

Man kann Keyboard Layouts unter Library ~ Keyboard Layouts ~ speichern.

Um jedoch nicht selbst die XML Datei bearbeiten zu müssen gibt es ein nette Freeware namens Ukulele.
Mit ihr lässt sich im Handumdrehen aus einem vorhandenen Layout ein neues erstellen. Dazu kann man einfach neue Befehle aus dem Mac OS Character Viewer auf das virtuelle Keyboard von Ukulele draggen und ein neues Layout erstellen.

Ich verwende z.B. Alt + O, U, A, S für Umlaute und habe Z und Y vertauscht. Ansonsten halte ich mich weitgehendst an das Britische Layout.
In diesem Zusammenhang möchte ich auch gerne auf das Simplified Dvorak Layout hinweisen. Ein optimiertes Tastatur Layout, das die am häufigsten verwendeten Buchstaben so anordnet, dass ein schnelleres Schreiben möglich wird. (Wenn man sich die Zeit nimmt, sich selbst darauf einzustellen).

Wünsche ein schönes, sonniges und erholsames Wochenende!

Leider braucht Apple immer ein bisschen Zeit um die neuste Java Version für Mac OS X zu veröffentlichen. Das reicht für den normalen Anwender zwar vollkommen, aber als Entwickler hat man unter Umständen durchaus das Bedürfnis, eine aktuelle(re) Version zu nutzen. Für Windows gibt es von OpenJDK regelmäßig aktuelle Binary Releases der neusten Entwicklungen. Den BSD Port von OpenJDK muss man sich selbst kompilieren. Da es mich ein bisschen Zeit gekostet hat und in der deutschen Blogosphäre nichts zu dem Thema zu finden war, will ich mal nicht so sein und euch an meinem Wissen teilhaben lassen:

Grundlage für den Artikel ist ein Beitrag von Sam Pullara und ein etwas älterer von Stephen Bannasch und einige Mails von der BSD Port Development Mailingliste

Als Grundlage für das Kompilieren von Java 1.7 habe ich den SoyLatte BSD Java Port von Langdon Fuller verwendet. Dabei habe ich prinzipiell die Scripte von den oben genannten Artikeln übernommen.
Hier wird in einfachen Schritten erklärt, wie man den Sourcecode des BSD Port Projektes per Mercurial (mit Forest Extension) auscheckt. Ab und an sind die aktuellen Versionen auf dem Repository allerdings nicht 100% lauffähig, dann sollte man eine ältere Version ausprobieren. Ausserdem ist es sehr hilfreich der Mailingliste zu folgen.
JIBX wird übrigens nicht mehr benötigt und kann übersprungen werden.

Sam Pullara schlägt auf seinem Blog folgendes Buildscript vor, welches bei mir gut funktioniert hat.

build.sh

env -i PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin \
make \
CC=gcc-4.0 CXX=g++-4.0 \
ALT_BOOTDIR=$SOYLATTE_HOME \
JAVA_TOOLS_DIR=$SOYLATTE_HOME/bin \
ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \
ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \
ANT_HOME=/usr/share/ant \
NO_DOCS=true \
HOTSPOT_BUILD_JOBS=1

Kompilieren hat hat ca. eine halbe Stunde auf meinem Macbook G1 gedauert. Mit einem aktuellen Gerät sollte das wesentlich schneller durch laufen. Auf meinem JBoss laufen mit Java 1.7 neuste Java Features die ich zur Dateiverarbeitung nutze. Hier bietet die neuste Version von Java einige Erleichterungen.