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)