2013-02-27 16 views
33

Utilizzo Java su OS X per molti, molti anni e di recente quando Apple ha smesso di includere Java per impostazione predefinita, lascio andare il sistema operativo e installarlo per me (varietà Apple, ovviamente).Informazioni su Oracle Java su Mac

Così ora sto usando OS X 10.8 e ho bisogno di installare Java 7 così ho appena ottenuto l'aggiornamento 15 di Oracle in formato DMG e ho eseguito l'installer. E 'aggiornato il mio/usr/bin/java (ed i relativi file) per puntare qui:

/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java 

Tracciare questo torna a tutto cio '/System/Library/Frameworks/JavaVM.framework/Versions' entrambi i punti di 'corrente' o 'CurrentJDK', il primo è un collegamento a 'A' (che è Oracle Java 7, da quello che posso dire, non so perché sia ​​'A') e quest'ultimo è un collegamento a Java 6 in '/ System di Apple /Library/Java/JavaVirtualMachines/1.6.0.jdk'.

Ora questo è tutto davvero confuso ma questa non è nemmeno la mia domanda ancora. Sembra ci sia un Java 7 installato qui:

/System/Library/Frameworks/JavaVM.framework/Versions/A 

Ma c'è anche un Java 7 installato qui:

/Library/Java/JavaVirtualMachines/jdk1.7.0_15.jdk 

Finding 'java' in entrambi e stampare la versione produce la stessa versione e build (versione java "1.7.0_15"), tuttavia, quando si cancellano i file sono diversi.

Questo significa che Oracle ha installato Java 7 in due diversi punti? Se è così, perché? Che dovrei usare? E perché alcune cose puntano ancora a Java 6 (CurrentJDK).

Ho consultato il sito Web di Oracle, ma nulla chiarisce nulla.

+0

Chiesto esattamente la stessa domanda che voglio. Ero davvero confuso dal JRE "2" nel mio Mac. La tua descrizione è chiara e pulita. Grazie per avermelo chiesto :) –

risposta

56

La JVM di Oracle viene installata solo in una posizione. Sei stato ingannato!

Come si è notato, i comandi Java in /usr/bin sono collegamenti simbolici ai file binari in /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands. I binari all'interno di quella directory sono applicazioni stub che determinano quale Java VM usare *, quindi eseguono il binario reale corrispondente all'interno della versione di VM. Questo è il motivo per cui tutti i binari all'interno di /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands hanno dimensioni quasi identiche, nonostante il fatto che ci si aspetterebbe che implementassero funzionalità abbastanza diverse.

si può vedere questo in azione utilizzando dtrace:

[email protected]:~$ sudo dtrace -n 'syscall::posix_spawn:entry { trace(copyinstr(arg1)); }' -c "/usr/bin/java -version" 
dtrace: description 'syscall::posix_spawn:entry ' matched 1 probe 
dtrace: pid 44727 has exited 
CPU  ID     FUNCTION:NAME 
    8 619    posix_spawn:entry /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java 

I dati dtrace invocazione stampa l'argomento percorso posix_spawn quando viene chiamato da java -version. Nel mio caso l'applicazione stub ha rilevato il runtime Java 1.6 di Apple in /System/Library/Java/JavaVirtualMachines/1.6.0.jdk e sta richiamando quella versione del comando java.

I binari degli stub hanno anche un altro vantaggio: quando rilevano che nessuna VM Java è installata, richiedono all'utente di installarne una.

Per quanto riguarda il CurrentJDK link simbolico, come meglio posso dire questo per amore di retro-compatibilità con il passato, quando Apple era l'unica fonte di JVM su OS X.


* Una combinazione di i fattori vengono presi in considerazione quando si determina quale Java VM deve essere utilizzata. JAVA_HOME viene utilizzato se impostato (prova JAVA_HOME=/tmp java).Se JAVA_HOME non è impostato, viene rilevato l'elenco di tutte le macchine virtuali sul sistema. Le variabili di ambiente JAVA_VERSION e JAVA_ARCH vengono utilizzate, se impostate, per filtrare l'elenco di macchine virtuali in una particolare versione e architettura supportata. L'elenco risultante viene quindi ordinato per architettura (preferendo 64 bit su 32 bit) e versione (più recente è migliore) e viene restituita la migliore corrispondenza.

+1

Grazie mille, non ho nemmeno pensato di guardare le dimensioni dei file. Posso investigare un po 'di più da solo, ma dove dici "applicazioni stub che determinano quale Java VM usare" ... come fanno a fare questa determinazione? Spero che sia con JAVA_HOME ma forse qualcos'altro? – rjcarr

+1

Viene considerata una combinazione di fattori. JAVA_HOME viene usato se impostato (prova 'JAVA_HOME =/tmp java'). Se JAVA_HOME non è impostato, viene individuata l'elenco di tutte le macchine virtuali sul sistema. Le variabili di ambiente JAVA_VERSION e JAVA_ARCH vengono utilizzate, se impostate, per filtrare l'elenco di macchine virtuali in una particolare versione e architettura supportata. L'elenco risultante viene quindi ordinato per architettura (preferendo 64 bit su 32 bit) e versione (più recente è migliore) e viene restituita la migliore corrispondenza. – bdash

8

The Oracle Java 7 JRE (cioè quello che viene utilizzato dal plugin browser web per eseguire le applet e Java Web Start) si installa in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home, ed è questo quello che tutti gli aggiornamenti automatici interesserà. Il JDK (quello che scarichi da http://www.oracle.com/technetwork/java/javase/downloads/index.html) si installa creando una directory sotto /Library/Java/JavaVirtualMachines, e tocca a te aggiornarlo tu stesso. È possibile avere più versioni JDK installate affiancate, ma solo una JRE "pubblica" sotto JavaAppletPlugin.plugin (che corrisponderà all'ultima versione di JDK installata o successiva se è stata aggiornata automaticamente da allora).

Come spiegato dal bdash, comandi nel /usr/bin sono stub che delega a qualsiasi JDK/JRE è puntata dalla variabile ambiente JAVA_HOME, o se non è impostato, allora si preleverà Java più appropriato per eseguire. È possibile utilizzare /usr/libexec/java_home per vedere quale stub sceglierebbe. Se no Java è installato, gli stub offriranno di installare l'ultima versione di Apple Java 6 (per quanto so che saranno non offerta per l'installazione di Java 7).

+0

Grazie per la spiegazione e questo ha un senso. Dovrò testare il var JAVA_HOME var e java_home per assicurarmi che possa farlo funzionare come previsto. – rjcarr

+0

@rjcarr Mi rendo conto che la mia risposta non era perfettamente chiara - gli stub rispetteranno sempre JAVA_HOME - l'esecuzione di '/ usr/libexec/java_home' mostra quale sceglierebbe se JAVA_HOME fosse _not_ set. –

+1

@bdash e Ian hanno davvero apprezzato le tue risposte. Sono arrivato a questo post per un motivo DIFFERENTE, sono riuscito a rovinare la mia installazione Java maneggiando/fraintendendo i vari link simbolici e stub. Nel caso in cui altri hanno riscontrato questo problema, i miei errori durante l'esecuzione di ant erano "java.lang.NoClassDefFoundError: Impossibile inizializzare la classe sun.util.calendar.ZoneInfoFile, a sun.util.calendar.ZoneInfo.getTimeZone (ZoneInfo.java:663)" e "C'è stato un errore prima di questo: java.lang.AssertionError: Piattaforma non riconosciuta su sun.nio.fs.DefaultFileSystemProvider.create (DefaultFileSystemProvider.java:73)" - Phew! –