Java in OS X 10.10 "Yosemite"

Wie auch schon die Vorgängerversion wird OS X 10.10 ohne vorinstalliertes Java 6 ausgeliefert. Bei einem Update wird eine vorhandene Java-6-Installation aus /System/Library/Java/JavaVirtualMachines gelöscht. Das alles ist eigentlich kein Problem, denn Java 6 ist eh veraltet, seit Oracle vor zwei Jahren den kostenlosen Support für Version 6 eingestellt hat – und in /Library/Java/JavaVirtualMachines installierte Versionen von Java 7 und Java 8 bleiben bei einem Update auf OS X 10.10 erhalten.

Manche Programme benötigen aber noch Java 6 zum Starten. Yosemite weist mit einem Dialog darauf hin:

Mit der Schaltfläche "Weitere Infos" gelangt man zur Download-Seite von Java für OS X 2014-001, mit dem in Mac OS X 10.7 bis OS X 10.10 Java 1.6.0_65 installiert werden kann. Dies ist dieselbe Java-Version, die Apple auch schon mit "Java für OS X 2013-005" ausgeliefert hat – nur ein geringfügig aktuellerer Build.

Java in OS X 10.9 "Mavericks"

Das Upgrade von OS X 10.8 nach 10.9 lief komplett problemlos, so soll es sein. Allerdings war anschließend Java 6 (Apples Implementation) nicht mehr vorhanden – wer diese Version benötigt, muss Java for OS X 2013-005 manuell herunterladen und installieren. Man hat dann Java 1.6.0_65 auf der Platte (im Gegensatz zu Oracle veröffentlicht Apple noch kostenfreie Updates für Java SE 6).

Ein bereits installiertes JDK 7 von Oracle bleibt normalerweise erhalten. Wer zu den Nutzern gehört, bei denen auch diese Java-Installation nach dem Upgrade nicht mehr aktiv ist, installiert einfach das aktuelle JDK 7u45. Java-7-Versionen bis einschließlich 7u25 wurden/werden von Apple aus Sicherheitsgründen deaktiviert.

Wie Apple riskante Java-Versionen mit der Xprotect-Liste deaktiviert

Am 1. Februar hat Oracle mit Java 7u13 und Java 6u39 zwei Updates veröffentlicht, die diverse sicherheitskritische Lücken geschlossen haben. Anwender von Mac OS X 10.6, 10.7 und 10.8 haben dies vielleicht schon einen Tag früher erahnen können, denn am 31. Januar hat Apple alle bis dahin gültigen Java-Versionen – zumindest die Applet-Nutzung – deaktiviert.

Nun sind Java-Applets zwar nicht mehr der Stand der Dinge, aber diverse Anwendungen laufen nicht ohne sie (einige VPN-Clients, elektronische Steuererklärung etc.). Und wer beruflich oder privat darauf angewiesen ist und einen Tag lang nicht weiß, warum die Web-Anwendung plötzlich nicht mehr funktioniert (gestern tat sie es ja noch!), steht erst einmal auf dem Schlauch...

Unabhängig von der Frage, ob es eine kluge Entscheidung war, die Java-Versionen zu deaktivieren, bevor entsprechende Updates zur Verfügung standen – wie hat Apple die Deaktivierung der Java-Applets realisiert?

Dazu gibt es im System die Datei /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist mit derzeit folgendem Inhalt (XML-Prolog etc. leicht gekürzt):

<dict>
  <key>JavaWebComponentVersionMinimum</key>
  <string>1.6.0_37-b06-435</string>
  <key>LastModification</key>
  <string>Fri, 08 Feb 2013 00:54:09 GMT</string>
  <key>PlugInBlacklist</key>
  <dict>
    <key>10</key>
    <dict>
      <key>com.macromedia.Flash Player.plugin</key>
      <dict>
        <key>MinimumPlugInBundleVersion</key>
        <string>11.5.502.149</string>
      </dict>
      <key>com.oracle.java.JavaAppletPlugin</key>
      <dict>
        <key>MinimumPlugInBundleVersion</key>
        <string>1.7.11.22</string>
      </dict>
    </dict>
  </dict>
  <key>Version</key>
  <integer>2029</integer>
</dict>

Die angegebenen Versionsnummern beziehen sich auf die Java Runtime Version, und die waren Ende Januar noch 1.6.0_37-b06-434 bzw. 1.7.0_11-b21. Apple hat die erforderliche Version also minimal über die verfügbaren Versionen gesetzt und damit die Applet-Plugins blockiert.

Wenn man auf das Arbeiten mit einer solchen, als gefährlich eingestuften Java-Version angewiesen ist und weiß, was man tut, kann man die Xprotect-Liste mit

sudo pico /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist

bearbeiten und den Minimum-Wert auf die installierte Java-Runtime-Version setzen. Sollten die Java-Bugfix-Updates dann längere Zeit ausbleiben, könnte man noch überlegen, das Aktualisieren der XProtect-Liste auszuschalten (in den Systemeinstellungen / Sicherheit / Weitere Optionen...), damit man die manuelle Änderung nicht jeden Tag durchführen muss. Aber Achtung, diese Option bezieht sich nicht nur auf Java-Versionen, sondern auch auf Flash und eventuelle Malware-Downloads!

OS X 10.8, Java und X11

Es gibt Java-Anwendungen, die X11 verwenden. Bei mir ist dies z.B. ein VPN-Client-Applet, was ich allerdings erst durch folgenden Hinweis erfahren habe:

In OS X 10.8 wird nicht nur Java nicht mehr vorinstalliert, auch X11 ist als Komponente, die "normale" Anwender nicht benötigen, nicht mehr vorhanden ...

Klickt man in dem Dialog auf "Fortfahren", wird man auf eine Apple-Support-Web-Seite gebracht, auf der man die Hintergründe zum XQuartz-Open-Source-Projekt erfährt. Dort kann man dann auch eine aktuelle Version (mind. 2.7.2, getestet habe ich 2.7.4) herunterladen, mit der OS X "Mountain Lion" und Java glücklich werden.

Die Installation von X11 löst ein weiteres Problem: Das GlassFish-Installations-Shellskript meldet unter OS X 10.8 folgenden Fehler:

much$ ./glassfish-3.1.2.2-unix.sh 
This program requires DISPLAY environment variable to be set.
Please re-run after assigning an appropriate value to DISPLAY.

Nach der Installation von X11 und einem Aus- und Einloggen ist die Umgebungsvariable "DISPLAY" wieder korrekt gesetzt und das Installations-Skript funktioniert wie gewohnt.

Apples Java-Update 2012-006 und die Sache mit dem Browser-Applet-Plugin

Zeitgleich haben Apple und Oracle Anfang vergangener Woche die neuesten Java-Updates veröffentlicht (Oracle: JDK und JRE 7u9; Apple: Java 6u37). Dieser Blog-Eintrag fasst zusammen, was ich bereits im Usenet geschrieben habe bzw. was Oracle als Hinweise dazu veröffentlicht hat.

Bisher war es so, dass in den Mac-Web-Browsern immer Apples Java-Applet-Plugin (also Java 6) aktiv war – es sei denn, man hatte Oracles JRE 7 installiert, dann wurde genau dieses Java 7 als Applet-Plugin verwendet.

Mit dem neuen Update "Java for OS X 2012-006" für Mac OS X 10.7 und 10.8 entfernt Apple das Java-6-Applet-Plugin nun explizit aus dem System. D.h. nach der Installation des Java-Updates ist zunächst einmal kein Applet-Plugin mehr verfügbar. Stattdessen wird auf einer Web-Seite, die ein Applet einbindet, die Meldung "Fehlendes Plug-In" angezeigt:

Klickt man auf die Meldung, erscheint ein etwas ausführlicherer Hinweis:

Dort bringt einen der Klick auf "Weitere Infos ..." auf Oracles Mac-JRE-Download-Seite. Apple drängt die Anwender also recht eindeutig zum Upgrade auf Java 7, was angesichts von wichtigen Security-Bugfixes, die es für Java 6 bald nicht mehr geben wird, mehr als verständlich ist.

Leider kommen einige wenige Java-Applets noch nicht mit Java 7 zurecht. Manche verweigern z.B. aufgrund schlechter bzw. zu restriktiver Programmierung (fest kodierte Prüfung einer bestimmten Java-Versionsnummer o.ä.) den Dienst mit der seit über einem Jahr aktuellen Java-Version... Wer auf die Arbeit mit so einem Applet angewiesen ist, kann das alte Plugin manuell im Terminal reaktivieren. Im Wesentlichen läuft das darauf hinaus, den Symlink /Library/Internet Plug-Ins/JavaAppletPlugin.plugin auf das noch vorhandene, aber gut versteckte /System/Library/Java/Support/Deploy.bundle/Contents/Resources/JavaPlugin2_NPAPI.plugin zeigen zu lassen (das ebenfalls vorhandene /System/Library/Java/Support/CoreDeploy.bundle/Contents/JavaAppletPlugin.plugin ist mit dem Update 2012-006 kein vollwertiges Applet-Plugin mehr, sondern zeigt nur noch den Hinweis zum fehlenden JRE7-Plugin an, s.o.).

Apples Java-Update 2012-006 löscht zudem die Java-Einstellungen in den Dienstprogrammen. Das Java Control Panel in den Systemeinstellungen ist damit die einzige Möglichkeit, Laufzeitparameter für Applets festzulegen. Schwerwiegender dürfte aber sein, dass Entwickler damit die bisher unter Mac OS X sehr einfache grafische Möglichkeit verlieren, aus allen installierten JDKs die aktive Version für die Kommandozeile auszuwählen. Stattdessen wird von den Kommandozeilentools in /usr/bin das JDK mit der höchsten Nummer verwendet. Was so einfach klingt, kann durchaus zu Problemen führen, wenn Vorabversionen des JDKs installiert sind:

HeartOfGold:~ much$ which java
/usr/bin/java
HeartOfGold:~ much$ java -version
openjdk version "1.8.0-b50"
OpenJDK Runtime Environment (build 1.8.0-b50-20120801)
OpenJDK 64-Bit Server VM (build 24.0-b16, mixed mode)

Glücklicherweise beachten die Tools die Umgebungsvariable JAVA_HOME, die man in seinen Shell-Skripten mithilfe des – schon längere Zeit verfügbaren – OSX-Tools /usr/libexec/java_home passend setzen kann:

HeartOfGold:~ much$ export JAVA_HOME=`/usr/libexec/java_home -v 1.7`
HeartOfGold:~ much$ printenv JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home
HeartOfGold:~ much$ java -version
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)

Alternativ kann man das java_home-Tool dazu verwenden, ein (Java-)Kommando mit einer bestimmten Java-Version auszuführen:

HeartOfGold:~ much$ /usr/libexec/java_home -v 1.6 --exec java -version
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)

OS X 10.8 "Mountain Lion", Java und der Gatekeeper

Vor einer Woche wurde (Mac) OS X 10.8 "Mountain Lion" veröffentlicht. Wie schon bei der Vorgängerversion liefert Apple keine Java-Laufzeitumgebung mehr mit dem Berglöwen/Puma aus – bei einem Update von 10.7.x wird eine bestehende Java 6-Installation sogar entfernt und muss erneut installiert werden:

Der Vergleich mit der Java-Installation unter 10.7 zeigt einen kleinen, aber wichtigen Unterschied: Es wird nun explizit eine Java SE 6-Runtime erwähnt. D.h. selbst wenn man Java 7 installiert hat, muss man zum Ausführen eines Java Application Bundles zusätzlich das alte Java 6 herunterladen. Dies ist das derzeit aktuelle Apple-Java-Update, das ursprünglich für Mac OS X 10.7 veröffentlicht wurde:

Ein Problem für Java-Anwendungen entsteht durch den Gatekeeper, der ab OS X 10.8 dafür sorgt, dass normalerweise nur Anwendungen aus dem App Store bzw. von zertifizierten Entwicklern gestartet werden können. Der Java Application Stub, mit dem die meisten Mac OS X-Java Application Bundles gestartet werden, enthält aber kein oder kein passendes Zertifikat (je nachdem, wie alt der Stub ist), was zu einer ziemlich unpassenden Fehlermeldung führt:

Mit ein bisschen Trickserei (Austausch des Application Stubs bzw. Entfernen der Prüfsumme / des Zertifikats) kann man die Fehlermeldung zwar etwas verständlicher bekommen ...

... aber das ist nicht im Sinne der Erfinder / nicht ganz einfach / zu instabil für künftige OS X-Versionen. Kurzum: Tun Sie's nicht. Eine Möglichkeit für den Anwender, Java-Anwendungen trotzdem noch starten zu können, besteht darin, den Gatekeeper in den Systemeinstellungen zu deaktivieren (auf "Keine Einschränkungen" stellen):

Das ist nun allerdings auch nicht im Sinne der zusätzlichen Sicherheit, die OS X 10.8 bringen soll, weil dann wirklich alle Anwendungen (auch die nativen Mac-Anwendungen) ungeprüft ausgeführt werden. Besser ist es, gezielt nur die gewünschte Java-Anwendung ohne Gatekeeper-Prüfung aufzurufen, was man über den "Öffnen"-Menüpunkt im Kontextmenü erreicht:

OS X verbietet das Starten nun nicht mehr pauschal, sondern fragt nach, ob man die vermeintlich unsichere Anwendung wirklich ausführen möchte:

Leider klappt das – je nach verwendetem Application Stub – nicht mit allen Java-Anwendungen. JD-GUI kann man so aufrufen, ArgoUML und TV-Browser beispielsweise nicht... Für letztere muss der Gatekeeper wie oben beschrieben deaktiviert werden. Kleiner Trost: Wenn man einmal eine Java-Anwendung gestartet hat, merkt sich der OS X dies, man kann den Gatekeeper anschließend also wieder aktivieren.

Am besten wäre es allerdings, wenn die Entwickler von Java-Anwendungen den Gatekeeper aktiv unterstützten und ihre Applikation signierten. Bei Oracle gibt es dazu kompakte Informationen. Und vor kurzem hat sich jemand die Mühe gemacht, ausführlich zu beschreiben, wie man seine Java-Programme im Mac App Store veröffentlichen kann.

Flashback und Apples Java-Updates

Apples (späte) Antwort auf den "Flashback" Virus/Trojaner waren diverse Java-Updates in schneller Folge (bzw. ein Hilfsprogramm zum Entfernen des Virus für Mac OS X-Systeme ohne installiertes Java, was seit Mac OS X 10.7 "Lion" möglich ist). Sowohl die Java-Updates als auch das Removal-Tool entfernen Flashback, wenn es auf einem System gefunden wird.

Weniger offensichtlich ist, dass durch das letzte der Java-Updates die Ausführung von Java-Applets und Java Web Start generell deaktiviert wird... Der Anwender muss Applets und Web-Start-Anwendungen in den Java-Einstellungen (im Ordner /Programme/Dienstprogramme) explizit wieder aktivieren:

Dies ist ebenfalls notwendig, wenn der Anwender mehr als 35 Tage weder mit Applets noch mit Java Web Start gearbeitet hat – dann wird beides wiederum automatisch deaktiviert.

Damit diese Änderungen nun nicht gleich das Ende vom Desktop-Java auf Mac OS X bedeuten, zeigt Apples Java-Plugin immerhin einen Hinweis an, warum eine Webseite nicht ganz so aussieht bzw. funktioniert wie erwartet:

Der Hinweistext ist gleichzeitig ein Link, mit dem sich das Java-Plugin wieder aktivieren lässt, ohne dass man die Java-Einstellungen aufrufen muss:

Das funktioniert soweit auch ganz prima – nur leider wird vermutlich die Hälfte der Anwender den kleingedruckten Text übersehen, dass der Browser anschließend neu gestartet werden muss... Abgesehen von der Frage, warum überhaupt ein Neustart notwendig ist, wäre es sicherlich gut, wenn sich der Hinweis-Link nach dem Aktivieren in einen statischen Text "Inaktives Plug-In (bitte Browser neu starten)" o.ä. verwandeln würde.

Java für Mac OS X 10.7 "Lion"

Da Apple vor kurzem Java-Updates für Mac OS X veröffentlicht hat, gibt es an dieser Stelle eine kleine Erinnerung an die wichtige Änderung, die mit Mac OS X 10.7 "Lion" eingeführt wurde: Im Gegensatz zu allen anderen Mac OS X-Versionen davor (*) ist keine Java-Laufzeitumgebung mehr vorinstalliert.
(* Von der 10.0-Public Beta, die wir uns 2000 von der Apple Expo Paris mitgenommen haben, mal abgesehen.)

Beim ersten Aufruf einer Java-Anwendung erhält man einen Hinweis, dass die Java-Runtime benötigt wird. Bestätigt man dies, wird Java SE 6 heruntergeladen und installiert. Danach wird die ursprünglich aufgerufene Java-Anwendung gestartet.

Das aktuelle Java-Update von Apple enthält Java 1.6.0_29 und ist damit zeitlich erfreulich nah an Oracles Java 6-Update für andere Systeme. Java 7, für andere Systeme mittlerweile als erstes Update freigegeben, ist leider immer noch nicht final für Mac OS X verfügbar (immerhin gibt es eine Developer Preview von Oracle). Java 8, was sich derzeit noch in der Entwicklung befindet, ist aber schon als Build des OpenJDK 8 für Mac OS X erhältlich.

OpenJDK 7 für Mac OS X

Nachdem Apple vor knapp zwei Monaten Unterstützung für das OpenJDK-Projekt angekündigt hatte, wurde die Mac OS X-Portierung am Montag dieser Woche als offizielles OpenJDK-Projekt angenommen – und nur einen Tag später hat Apple den ersten offenen Code in das Projekt eingebracht. Im Wesentlichen entspricht diese erste Veröffentlichung der BSD-Portierung. Apple hat derzeit nur den Build-Prozess verändert, um ein Universal Binary mit einem .jdk-Bundle zu erzeugen, das zur neuen Java-Verzeichnisstruktur von Mac OS X passt (und entsprechend nach der Installation automatisch erkannt wird).

Jeder kann nun zum Mac OS X-Port beitragen und sich das aktuellste OpenJDK aus den Quelltexten bauen. Voraussetzung dafür sind u.a. Mac OS X ab Version 10.6.5 sowie Xcode ab Version 3.2.5. Genaueres ist im Wiki beschrieben; dort kann man auch den aktuellen Projekt-Status einsehen.

Wer das JDK 7 einfach ausprobieren möchte, ohne es selber bauen zu müssen, kann sich ein fertiges DMG von Google Code herunterladen. Der Installer für den Mac OS X-Branch enthält sowohl eine 32- als auch eine 64-Bit-JVM. Nach der schnellen und vollkommen unproblematischen Installation kann man das JDK 7 mit den üblichen Kommandos im Terminal testen:

much$ /usr/libexec/java_home --version 1.7
/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home

much$ export JAVA_HOME=`/usr/libexec/java_home -v 1.7`
much$ $JAVA_HOME/bin/java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-b00)
OpenJDK 64-Bit Server VM (build 20.0-b03, mixed mode)

much$ /usr/libexec/java_home -v 1.7 --exec java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-b00)
OpenJDK 64-Bit Server VM (build 20.0-b03, mixed mode)

Für grafische Frontends wird noch kein Cocoa, sondern nur X11 unterstützt. Zum Ausprobieren der neuen Sprachfeaturen (Strings im switch etc.) reicht das aber vollkommen aus.

Wie bereits erwähnt wird das OpenJDK 7 automatisch von den Java-Einstellungen in Mac OS X erkannt. Wegen der noch unvollständigen Cocoa- bzw. Mac OS X-Integration sollte man die neue Version aber noch nicht als Default setzen, d.h. besser am Ende der Liste belassen.

Oracle bringt Java SE 7 für Mac OS X

... und Apple wird auch in Mac OS X 10.7 "Lion" noch die eigene Java SE 6-Implementation bereitstellen. Das sind kurz zusammengefasst die Ergebnisse der letzten Tage.

Nachdem es vor drei Wochen recht düster für die Zukunft von Java auf Mac OS X ausgesehen hatte, weil Apple die eigene Java-Implementierung abgekündigt, aber keinen Ersatz als Perspektive geboten hatte, sieht es nun so aus, als ob wir genau die Lösung bekommen, die von vielen favorisiert wurde: Apple bringt die meisten Teile seiner Java-Implementation als Open Source in das OpenJDK-Projekt ein, und Oracle wird daraus – beginnend mit Java SE 7 – offizielle Java-Releases für Mac OS X bauen.

Es ist noch nicht ganz klar, wann Java SE 7 für Mac OS X verfügbar sein wird und wie die Quelltexte im Detail zur Verfügung gestellt werden. Aber die Zukunft für Java auf Mac OS X dürfte damit sichergestellt sein.

Nebenbei hat Apple in der Pressemitteilung bekannt gegeben, dass auch das im nächsten Jahr erscheinende Mac OS X 10.7 "Lion" noch die eigene Java SE 6-Implementation enthalten wird, so dass für die Übergangszeit auf Oracles Mac-Java-Implementation eine klare Perspektive besteht.

Na also. Warum denn nicht gleich so?

@Deprecated Java für Mac OS X

Es musste ja irgendwann passieren: Nachdem schon Flash in Ungnade gefallen war, hat Apple nun keine Lust mehr auf Java...

In den Release Notes zum gestern erschienenen "Java for Mac OS X 10.6 Update 3", das Java SE 6 auf Version 1.6.0_22 aktualisiert, findet sich an prominenter Stelle der Hinweis, dass Apples eigene Java-Implementation ab sofort als veraltete Technologie gilt und in künftigen Mac OS X-Versionen fehlen könnte.

Auch wenn direkt unter dieser Ankündigung beschrieben ist, dass und wie mit diesem Update Java Virtual Machines (JVMs) anderer Hersteller leichter ins System eingebunden werden können (was ich in einem folgenden Blog-Eintrag beschreibe) und auch die exakte Wortwahl der Apple-Java-Abkündigung fast impliziert, dass ein anderer Hersteller in die Bresche springen wird – gesichert ist dies nicht.

Bis also Oracle oder IBM oder irgendwer sonst (Google?) offiziell bekannt gibt, dass sie eine Java-Implementierung für Mac OS X anbieten werden, müssen wir leider davon ausgehen, dass Java auf dem Mac tot ist.

Dies dürfte extrem negative Auswirkungen auf den Einsatz von Macs in Unternehmen haben, da dort Java-Anwendungen häufig in der einen oder anderen Form benötigt werden. Ebenso wird der Mac damit für Bildungseinrichtungen und insbesondere Hochschulen uninteressant, da dort oft Java als Lehrsprache eingesetzt wird. Und die Java-Entwickler-Gemeinde, in der sich (zumindest gefühlt) überdurchschnittlich viele Mac-Anwender befinden, wird sich neue Hardware-Investitionen und Upgrades auf kommende Mac OS X-Versionen gut überlegen.

Zu hoffen bleibt, dass die Ankündigung nur eine Kommunikations-Katastrophe mit schlechtem Timing war. Andererseite werden, sofern man diversen Internet-Quellen glauben darf, Java-Anwendungen für den kommende "Mac App Store" nicht akzeptiert werden, da es sich um veraltete Technologie handelt. Und das sieht dann schon eher nach Absicht aus...

Abwarten und Kaffee trinken.

Snow Leopard und Rosetta

Schon seit den ersten Mac OS X-Versionen können Java-Applikationen in einer speziellen Verzeichnisstruktur als "normale" Mac OS X-Anwendung verpackt werden, so dass sie u.a. mit einem eigenen Programmsymbol dargestellt werden. Damit solche Application Bundles Java-Bytecode ausführen können, enthalten sie als nativen Mach-O-Startcode im Verzeichnis /Contents/MacOS/ die Datei JavaApplicationStub:

Führt man ältere, noch unter PowerPC (PPC) Mac OS X zusammengebaute Java-Application-Bundles unter Mac OS X 10.6 "Snow Leopard" aus, erhält man eventuell den Hinweis, dass man den auf der Snow-Leopard-Installations-DVD enthaltenen PPC-Emulator "Rosetta" installieren muss, um die Anwendung starten zu können. Obwohl Apple seit Mac OS X 10.4 alte PPC-JavaApplicationStubs erkennt und als 32-Bit-Intel-Prozess neu startet, muss dafür Rosetta installiert sein – und genau das ist seit Snow Leopard nicht mehr standardmäßig der Fall.

Die einfachste Lösung, die zudem Rosetta nicht benötigt, ist, den alten Stub im Application Bundle durch eine Kopie der aktuelle Version /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub zu ersetzen. Dieser neue Stub enthält Code für die drei derzeit unterstützten Prozessorarchitekturen:

Straylight:~ much$ file JavaApplicationStub
JavaApplicationStub: Mach-O universal binary with 3 architectures
JavaApplicationStub (for architecture x86_64):  Mach-O 64-bit executable x86_64
JavaApplicationStub (for architecture i386):    Mach-O executable i386
JavaApplicationStub (for architecture ppc7400): Mach-O executable ppc

Wenn eine Java-Anwendung eine bestimmte Architektur nicht benötigt (z.B. weil nachgeladene JNI-Bibliotheken dafür nicht compiliert wurden), kann und sollte der entsprechende Code mit /usr/bin/lipo entfernt werden.

Java in Mac OS X 10.6 "Snow Leopard"

Der Schneeleopard ist also aus dem Käfig... Und während das nun "alte" Mac OS X 10.5 noch drei Implementierungen für Java 1.4, 5.0 und 6 mitbrachte, enthält Mac OS X 10.6 ausschließlich Java SE 6 (1.6.0_15) in einer 32-Bit- und einer 64-Bit-Version. Detaillierte Informationen zu beseitigten und bekannten Fehlern enthalten die Release Notes.

Damit auch Java 5-Anwendungen weitestgehend problemlos laufen, sind im Ordner /System/Library/Frameworks/JavaVM.framework/Versions noch die Unterordner 1.5 und 1.5.0 enthalten, aber beide sind Aliase (Symlinks) auf die Java 6-Implementierung.

Und obwohl QuickTime for Java schon seit längerem nicht mehr offiziell unterstützt wird, sind die QTJava-Bibliotheken immer noch vorhanden und funktionieren auch mit Java 6.

Mal abwarten, was die praktischen Erfahrungen in den kommenden Tagen zeigen.

java_home oder /Library/Java/Home?

Es ist immer wieder eine spannende Frage, wie man in Mac OS X die Standard-Java-Version einstellt bzw. wie man die für eine bestimmte Anwendung "richtige" Java-Version herausbekommt. Mac OS X 10.5 unterstützt derzeit bis zu drei verschiedene Hauptversionen (1.4.2, 1.5.0, 1.6.0), teils als 32-Bit-, teils als 64-Bit-Variante.

Bisher konnten Anwender die bevorzugte Java-Version getrennt für Applets und für andere Anwendungen (Web Start, Kommandozeile) mit /Programme/Dienstprogramme/Java/Java-Einstellungen konfigurieren. Alternativ konnte man natürlich auch die Umgebungsvariable JAVA_HOME setzen oder sich auf den festen Pfad /Library/Java/Home verlassen. Und weil diese Möglichkeiten immer noch nicht bei allen Anwendungen funktionierten, verbogen die ganz Wagemutigen diverse Symlinks im JavaVM-Framework (was aber auch nicht immer klappte und zu diversen Fehlern führte).

Bevor wir uns um die empfohlene Lösung kümmern, hier zunächst eine Warnung: Basteln Sie niemals an den Symlinks in /System/Library/Frameworks/JavaVM.framework (und in Unterordnern davon) herum! Auch dann nicht, wenn Sie viele gutgemeinte Tipps finden, wie man Current und CurrentJDK verbiegen kann... Apple weist seit langem darauf hin, dass diese Symlinks interne Implementationsdetails sind, die sich jederzeit ändern können.

Mit dem aktuellen Java-Update für Mac OS X 10.5 liefert Apple nun ein Kommandozeilenprogramm aus, mit dem sich die Benutzereinstellungen aus /Programme/Dienstprogramme/Java-Einstellungen auslesen lassen (beachten Sie, dass der Java-Unterordner in dem Pfad mit diesem Update verschwunden ist):

HeartOfGold:~ much$ /usr/libexec/java_home
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home

Ein Aufruf mit der Option -h zeigt alle erlaubten Optionen an. Eine Liste aller verfügbaren JVMs – in der in den Java-Einstellungen festgelegten Reihenfolge – erhalten wir mit --verbose:

HeartOfGold:~ much$ /usr/libexec/java_home --verbose
Matching Java Virtual Machines (4):
1.5.0_19 (i386): /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
1.6.0_13 (x86_64): /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
1.5.0_19 (x86_64): /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
1.4.2_21 (i386): /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Home

Man kann auch ganz gezielt nach einer bestimmten Java-Version und/oder Prozessorarchitektur fragen:

HeartOfGold:~ much$ /usr/libexec/java_home --version 1.6 --arch x86_64
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home

Sofern die gewünschte JVM nicht vorhanden ist, erhält man eine Fehlermeldung und eine hoffentliche passende alternative JVM:

HeartOfGold:~ much$ /usr/libexec/java_home --version 1.6 --arch i386
Unable to find any JVMs matching architecture "i386".
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home


Zurück zur Ausgangsfrage. Wie finden wir damit z.B. in einem Shell-Skript die passende Java-Version für eine Anwendung? Apple empfiehlt folgendes Vorgehen:

1. Prüfen Sie, ob /usr/libexec/java_home vorhanden ist, übergeben Sie optional die gewünschte Java-Version und werten Sie die Rückgabe aus.
2. Wenn das nicht erfolgreich war, verwenden Sie als Java-Home-Verzeichnis fest kodiert (!) das Verzeichnis /System/Library/Frameworks/JavaVM.framework/Versions/1.X/Home, wobei Sie "1.X" durch die gewünschte Versionsnummer (1.4, 1.5, 1.6) ersetzen.
3. Sollte das Verzeichnis nicht existieren, verwenden Sie /Library/Java/Home (und beten, das alles klappt).
   

100% perfekt ist das m.E. zwar nicht, denn Punkt 2 geht schief, wenn das Verzeichnis für Java 6 existiert, Java 6 aber nicht ausgeführt werden kann (das betrifft vor allem 32-Bit CoreDuo-Macs). Aber immerhin hat Apple nun dokumentiert, wie man künftig – und in den meisten Fällen auch bisher – zum korrekten Ergebnis gelangt.


Und was ist mit der Umgebungsvariable JAVA_HOME? Offenbar werten diverse Systemprogramme (wie /usr/bin/java) nicht nur die Rückgabe von /usr/libexec/java_home aus, sondern auch den Wert von JAVA_HOME. Wenn sich die Werte unterscheiden, kann das zu unerwartetem Verhalten führen... Insofern sollte mittelfristig auf das Setzen von JAVA_HOME besser verzichtet werden.

Da sich aber kurzfristig viele Anwendungen noch auf die Umgebungsvariable JAVA_HOME verlassen, ist es derzeit m.E. am besten, die Variable auf die Java-Version zu setzen, die auch in den Java-Einstellungen an oberster Stelle steht (auch wenn das erst einmal doppelten Konfigurationsaufwand bedeutet). Das Setzen der Variablen geschieht am einfachsten mit RCEnvironment, wodurch die Variable sowohl Shell-Skripten als auch GUI-Anwendungen bekannt ist:

Eine ausführliche Diskussion rund um java_home findet sich auf Apples Java-Mailingliste.

Monitoring und Profiling mit VisualVM

Am Wochenende habe ich einen kleinen Vortrag über VisualVM gehalten. Dieses nützliche Werkzeug ist seit dem Update 7 fester Bestandteil des JDK 6. Es bietet gute Überwachungsmöglichkeiten für laufende Java-Anwendungen (sowohl lokal als auch auf entfernten Rechnern). Beim Profiling kann es zwar nicht ganz mit kommerziellen Lösungen mithalten, bietet aber dennoch für viele Situationen vollkommen ausreichende Auswertungen (z.B. die Aufrufstellen einer Methode).

VisualVM benötigt Java 6 als Laufzeitumgebung, kann aber Anwendungen schon ab Java 1.4 überwachen. Faustregel: Je neuer die Laufzeitumgebung des auszuwertenden Programms ist und je lokaler sie läuft, desto bessere Informationen liefert VisualVM.

Leider liefert Apple VisualVM auch mit dem neuesten Update ihrer Java SE 6-Implementation nicht mit. Sofern man dieses Update eingespielt hat, kann man VisualVM 1.1.1 aber problemlos separat herunterladen und (durch Auspacken des ZIP-Archivs) installieren.

Da es gute Gründe gibt, als Standard-Java-Version unter Mac OS X derzeit noch 5.0 einzusetzen, muss man Java 6 beim Aufruf im Terminal explizit als Parameter angeben:

HeartOfGold:visualvm-1.1.1 much$ bin/visualvm --jdkhome /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/ &


Das Profiling funktioniert mit der Apple-Java-Implementierung noch nicht wirklich zuverlässig... Eventuell ist ein älterer Bug immer noch nicht vollständig korrigiert. Immerhin stehen die Monitoring-Möglichkeiten komplett und stabil zur Verfügung.

Mit dem neuen "Memory Sampler"-Plugin können aber zumindest Live-Speichervergleiche (Deltas) ermittelt werden, was einen wichtigen Aspekt des Memory-Profilings abdeckt. Und der Memory Sampler läuft zum Glück auch unter Mac OS X.

WebObjects-Anwendungen in Eclipse entwickeln

Still und heimlich hat Apple vor ein paar Wochen eine Anleitung veröffentlicht, wie man WebObjects-Anwendungen in Eclipse mit den WOLips-Plugins entwickelt.

Zur Erinnerung: WebObjects ist Apples Enterprise-Framework zur Entwicklung skalierbarer Web-Applikationen. Von NeXT bereits 1996 veröffentlicht, ist es heute die Software-Basis u.a. vom iTunes Store. 2001 wurde das bis dahin in Objective-C entwickelte Framework komplett neu geschrieben – in Java. Entsprechend kann WebObjects 5.x problemlos mit Java SE oder innerhalb eines Java EE-kompatiblen Servers genutzt werden.

Nachdem Apple 2006 die Weiterentwicklung der eigenen, auf Xcode basierenden Entwicklerwerkzeuge eingestellt hat, unterstützt und verwendet Apple nun WOLips, eine OpenSource-Plugin-Sammlung für Eclipse, die die WebObjects-Entwicklertools nachbildet.

Java EE und JavaFX für Mac OS X

Während nach wie vor Apple für das JDK (Java SE) unter Mac OS X verantwortlich ist und sich dabei nicht besonders gut um ältere Macs kümmert, sind andere Java-Technologien direkt von Sun für Mac OS X erhältlich:

• das Java EE 5 SDK inkl. Sun Application Server (GlassFish)
• das JavaFX 1.1 SDK inkl. NetBeans IDE 6.5
  

Beide Produkte können ab Mac OS X 10.4 genutzt werden, sowohl auf Intel- als auch auf PowerPC-G5-Macs – sofern Apples aktuellstes Java 5.0-Update installiert ist.

Als JEE-Umgebung eignet sich natürlich auch der JBoss AS 5.0, der ebenfalls problemlos unter Mac OS X betrieben werden kann.

Aktuelle Java-Versionen für Mac OS X

Im Netz taucht immer wieder die Frage auf, welche Java-Versionen aktuell unter Apples Mac OS X genutzt werden können – gerade wenn Java-Entwickler ihre Programme nicht selber auf einem Mac testen können.

Für Mac OS X 10.5 sind die Java-Versionen 1.4, 5.0 und 6 direkt von Apple verfügbar und können über die Softwareaktualisierung ins System eingebunden werden (als JDKs, es gibt von Apple keine separaten JREs). Unter Mac OS X 10.4 war zusätzlich noch Java 1.3 nutzbar, dafür hat Apple für diese ältere Betriebssystemversion kein Java SE 6 herausgebracht.

Aber Achtung: Gerade Java SE 6, also die einzige Version, die Ende dieses Jahres noch nicht EOL sein wird, steht nur für 64-Bit-Intel-Macs zur Verfügung. Das sind solche mit Core2Duo-Prozessor. PPC-Macs und ältere Intel-Macs mit CoreDuos bleiben leider außen vor...

Standardmäßig ist für Applets und Java Web Start-Anwendungen so oder so Java 5.0 eingestellt. Mit dem System-Utility /Programme/Dienstprogramme/Java/Java-Einstellungen kann man dies ändern (siehe Bildschirmfoto).

Fazit: Java 6 ist in der Apple-Welt für Endbenutzer leider immer noch nicht wirklich angekommen. Wenn Ihre Java-Applikationen von möglichst vielen Apple-Nutzern eingesetzt werden sollen, sollten Sie derzeit noch Java 5.0 als Mindestanforderung voraussetzen.

Und nun noch ein paar technische Details:

Die aktuellen JDKs für Mac OS X haben die Versionsnummern 1.4.2_18, 1.5.0_16 und 1.6.0_07. Sie können mit den Software-Updates Java for Mac OS X 10.4 Release 7 bzw. Java for Mac OS X 10.5 Update 2 installiert werden (es gibt mittlerweile auch Release 8 und Update 3, aber dadurch wird nur Java Web Start aktualisiert und nicht nicht JDK-Version verändert).

Das Java-Update für Mac OS X 10.5 installiert übrigens auch auf CoreDuo-Macs Java SE 6, nur leider lässt sich das auf diesen Rechnern trotzdem nicht ausführen...

Seit einigen Jahren pflege ich eine detaillierte Liste von Mac OS X- und deren Java-Versionen inkl. der entsprechenden Download-Links.

Unabhängig von Apples Java-Versionen gibt es mit SoyLatte seit einiger Zeit auch eine Portierung vom OpenJDK für Mac OS X. Damit kann Java SE 6 nicht nur unter Mac OS X 10.5, sondern auch unter 10.4 genutzt werden. Allerdings ist auch SoyLatte nur für Intel-Macs verfügbar, und für grafische Ausgaben wird das für Mac-Oberflächen unübliche X11 anstelle von Cocoa genutzt.

Bleibt zu hoffen, dass Sun es (mit Apples Hilfe?) ab Java 7 schafft, selber wieder ein vernünftiges JDK für Mac OS X herauszubringen.

Das Swing Application Framework lebt!

Desktop-Anwendungen mit Java zu entwickeln, war schon immer so eine Sache... Zwar gibt es die Swing-Bibliothek seit Ewigkeiten und deren GUI-Komponenten sind auch recht brauchbar. Was aber fehlte, war ein Framework, mit dem man den ganzen Lebenszyklus einer Desktop-Applikation einfacher handhaben konnte.

Auch wenn im Laufe der Zeit mit der NetBeans Platform und Eclipse RCP Alternativen entstanden sind, wollte Sun mit dem Swing Application Framework (JSR 296) eine reine Swing-Lösung anbieten. Der Ansatz war gut, doch leider wurde es um diesen JSR in den vergangenen Monaten sehr still - so still, dass der JSR vor kurzem in den Status "inaktiv" versetzt wurde.

Nun hat sich einer der Sun-Entwickler zu Wort gemeldet und verkündet, dass nun wieder aktiv an Swing und dem Swing Application Framework (SAF) gearbeitet wird. In der letzten Zeit gab es offenbar einfach wichtigere Dinge (vermutlich JavaFX?) zu erledigen.

Bei den neuerlichen Aktivitäten ist interessant, dass nicht mehr nur MDI-Anwendungen unterstützt werden sollen, sondern explizit auch die vor allem unter Mac OS X verbreiteten SDI-Applikationen (und auch die beim Mac üblichen Menüzeilen ganz ohne offenes Dokument-Fenster). Das lässt hoffen, denn bisher war für solche GUI-Anpassungen ein nicht unerheblicher Mehraufwand nötig.

Man darf gespannt sein, ob das Swing Application Framework Bestandteil von Java 7 sein wird, dessen Veröffentlichung mittlerweile für 2010 vorgesehen ist.