/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.
/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.sudo pico /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
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.
/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.)./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)
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)
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)
/Library/Java/JavaVirtualMachines/1.7.0.jdk schreibt, d.h. das JDK steht für alle Benutzer auf dem Rechner zur Verfügung.
java -version und /usr/libexec/java_home liefern noch Java 6), obwohl es in den Java-Einstellungen als System-Default konfiguriert wurde, sollte man prüfen, ob die Umgebungsvariable JAVA_HOME (falsch) gesetzt ist. Das kann beispielsweise grafisch im RCEnvironment geschehen sein, falls man diese Erweiterung der Systemeinstellungen installiert hat. Häufiger ist dies wohl aber in der Shell-Konfigurationsdatei (z.B. .bash_profile) erfolgt. Entweder setzt man den Eintrag für JAVA_HOME aufexport JAVA_HOME=`/usr/libexec/java_home`JAVA_HOME komplett. Nach einem Rechner-Neustart (aus- und einloggen hat bei mir nicht geholfen) sollte dann alles funktionieren.
/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/Library/Java/JavaVirtualMachines oder /System/Library/Java/JavaVirtualMachines) und anschließend eine der dort installierten Java-Laufzeitumgebungen auswählen.
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.
Nachdem Java SE 7 schon seit einigen Monaten für Windows, Linux und Solaris verfügbar ist und eine Portierung des OpenJDK 7 für Mac OS X begonnen wurde, bietet Oracle nun eine Vorabversion des JDK 7 für Mac OS X an./Library/Java/JavaVirtualMachines. Fertig! Das Verzeichnis sollte bereits existieren, wenn man das letzte Apple-Java-Update installiert hat, ansonsten muss man es von Hand anlegen.
much$ /usr/libexec/java_home --version 1.7
/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home
much$ /usr/libexec/java_home -v 1.7 --exec java -version
openjdk version "1.7.0-ea"
OpenJDK Runtime Environment (build 1.7.0-ea-b211)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)
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)
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.
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.
java_ee_sdk-5_07-mac-nojdk.zip (Download "GlassFish Java EE") ausgepackt und zu installieren versucht:HeartOfGold:java_ee_sdk-5_07-mac-nojdk much$ chmod a+rx setup
HeartOfGold:java_ee_sdk-5_07-mac-nojdk much$ ./setup
Installer cannot find a suitable 1.5.x version of JDK under the
following directories.
1. /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
2. /Library/Java/Home
Please rerun with -javahome argument pointing to a valid 1.5 version of JDK.
setup ersetzt man mit einem Texteditor in Zeile 54 einfach am Ende der Zeile "1.5" durch "1.6":54: javaVersion=`${TIGER_JAVAHOME} ... ${GREP} 1.6`
Das war es dann auch schon! Der Installer lässt sich nun auch mit Java 6 problemlos ausführen, und GlassFish läuft auch (bzw. gerade) mit dem aktuellen JRE hervorragend.
/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./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 JavaApplicationStubWenn 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
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
/usr/bin/lipo entfernt werden.
/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)./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./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
-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
HeartOfGold:~ much$ /usr/libexec/java_home --version 1.6 --arch x86_64
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
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
/usr/libexec/java_home vorhanden ist, übergeben Sie optional die gewünschte Java-Version und werten Sie die Rückgabe aus./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./Library/Java/Home (und beten, das alles klappt).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.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.
Why isn't this blog available in English? Well, there are so many useful blogs out there, but only a few of them are written in languages other than English. So I decided it was time for a blog in my mother tongue.
Posts
Alle Kommentare
