Como posso alterar o Java VM padrão do Mac OS retornado de / usr / libexec / java_home

(Não tinha certeza se isso deveria continuar no SU ... a migração é certamente uma opção, mas mais programadores lêem as perguntas aqui, então aqui vai).

Estou executando o Mac OS X 10.8.4 e tenho o JDK 1.6.0_51 da Apple instalado, bem como o JDK 1.7.0_25 da Oracle. Recentemente, instalei o JDK de visualização 1.8 da Oracle para alguns softwares de pré-lançamento que exigem isso. Agora, quando executo / usr / libexec / java_home, recebo o seguinte:

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (4):
    1.8.0, x86_64:  "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
    1.7.0_25, x86_64:   "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home
    1.6.0_51-b11-457, x86_64:   "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
    1.6.0_51-b11-457, i386: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

Ótimo.

No entanto, executando:

$ java -version

Retorna:

java version "1.8.0-ea"

Isso significa que a versão padrão do Java é atualmente a versão de pré-lançamento, o que quebra alguns pacotes "normais" (no meu caso, VisualVM).

Não consigo definir JAVA_HOMEporque o lançamento de aplicativos ignora variáveis ​​de ambiente, mesmo ao iniciar a partir da linha de comando (por exemplo$ open /Applications/VisualVM.app ).

Então, há um arquivo que eu posso editar onde posso definir minhas preferências de pedido JVM globalmente ?

(Por favor, não me diga para iniciar o painel de preferências do Java porque isso simplesmente não funciona: ele não contém nada de útil e lista apenas uma das 4 JVMs que instalei.)

Atualização :

Oracle JVMs residem em /Library/Java/JavaVirtualMachines. Renomear o diretório JDK 1.8 para jdk1.8.0.jvm.xyznão muda nada: java_homeainda o encontra no lugar certo e a execução de / usr / bin / java ainda executa a JVM 1.8. Isso não é um problema com links de sincronização, etc.

Respostas a perguntas semelhantes

Embora esta resposta ofereça o que equivale a um hack que removerá versões do Java de serem capturadas por java_home, ela ainda não responde a esta questão de como java_home escolhe seu padrão e se os usuários podem ou não configurá-lo de forma não destrutiva .

Acho que JAVA_HOMEé o melhor que você pode fazer. As ferramentas de linha de comando gostam javae javacrespeitarão essa variável de ambiente, você pode usar /usr/libexec/java_home -v '1.7*'para fornecer um valor adequado para colocar a JAVA_HOMEfim de fazer as ferramentas de linha de comando usarem Java 7.

export JAVA_HOME="`/usr/libexec/java_home -v '1.7*'`"

Mas os pacotes de aplicativos padrão clicáveis ​​não usam JDKs instalados /Library/Javano. Os .apppacotes de estilo antigo JavaApplicationStubque usam o da Apple usarão o Apple Java 6 de /System/Library/Frameworks, e os de estilo novo construídos com AppBundler sem um JRE embutido usarão o JRE "público" /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home- que está embutido no código stub e não pode ser alterado, e você não pode ter dois JREs públicos diferentes instalados ao mesmo tempo.

Edit: Eu dei uma olhada no VisualVM especificamente, supondo que você esteja usando a versão "pacote de aplicativos" da página de download , e este aplicativo em particular não é um aplicativo AppBundler, em vez disso, seu executável principal é um script de shell que chama um número de outros scripts de shell e lê vários arquivos de configuração. O padrão é escolher o JDK mais novo de/Library/Java que seja 7u10 ou posterior, ou usar Java 6 se a instalação do Java 7 for atualização 9 ou anterior. Mas desvendando a lógica nos scripts de shell, parece-me que você pode especificar um JDK particular usando um arquivo de configuração.

Crie um arquivo de texto ~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.conf(substitua 1.3.6 por qualquer versão do VisualVM que você está usando) contendo a linha

visualvm_jdkhome="`/usr/libexec/java_home -v '1.7*'`"

e isso o forçará a escolher Java 7 em vez de 8.

Eu estive lá também e procurei em todos os lugares como /usr/libexec/java_home funciona, mas não consegui encontrar nenhuma informação sobre como ele determina as Java Virtual Machines disponíveis que ele lista.

Eu experimentei um pouco e acho que simplesmente executa um ls /Library/Java/JavaVirtualMachinese inspeciona o./<version>/Contents/Info.plist todos os tempos de execução que encontra lá.

Em seguida, ele os classifica em ordem decrescente de chaveJVMVersion contida no Info.plist e, por padrão, usa a primeira entrada como sua JVM padrão.

Acho que a única coisa que podemos fazer é mudar o plist: sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.pliste, em seguida, modificar o JVMVersion 1.8.0para outra coisa que faça com que seja classificado na parte inferior em vez de na parte superior, como !1.8.0.

Algo como:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    ...
    <dict>
            ...
            <key>JVMVersion</key>
            <string>!1.8.0</string>   <!-- changed from '1.8.0' to '!1.8.0' -->`

e então desaparece magicamente do topo da lista:

/usr/libexec/java_home -verbose
Matching Java Virtual Machines (3):
    1.7.0_45, x86_64:   "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home
    1.7.0_09, x86_64:   "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home
    !1.8.0, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home

Agora você precisará fazer logout / login e então:

java -version
java version "1.7.0_45"

:-)

É claro que não tenho ideia se algo mais quebrou agora ou se a versão 1.8.0-ea do java ainda funciona corretamente.

Você provavelmente não deve fazer nada disso, mas simplesmente desinstalar o 1.8.0.

No entanto, até agora isso tem funcionado para mim.

Na verdade, é muito fácil. Digamos que temos isso em nossa pasta JavaVirtualMachines:

• jdk1.7.0_51.jdk
• jdk1.8.0.jdk

Imagine que 1.8 é o nosso padrão, então apenas adicionamos uma nova pasta (por exemplo, 'old') e movemos a pasta jdk padrão para essa nova pasta. Faça java -versionnovamente et voila, 1.7!

É muito simples, se você não se importa de arregaçar as mangas ... / Library / Java / Home é o padrão para JAVA_HOME e é apenas um link que aponta para um dos seguintes:

• /System/Library/Java/JavaVirtualMachines/1.?.?.jdk/Contents/Home
• /Library/Java/JavaVirtualMachines/jdk1.?.?_??.jdk/Contents/Home

Então, eu queria mudar minha versão JVM / JDK padrão sem mudar o conteúdo de JAVA_HOME ... / Library / Java / Home é o local padrão para o JVM / JDK atual e é isso que eu queria preservar ... parece-me para ser a maneira mais fácil de mudar as coisas com o mínimo de efeitos colaterais.

Na verdade, é muito simples. Para alterar a versão do java que você vê com java -version, tudo o que você precisa fazer é alguma versão deste:

cd /Library/Java
sudo rm Home
sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home ./Home

Eu não perdi tempo, mas um script de shell muito simples que usa / usr / libexec / java_home e ln para reposicionar o link simbólico acima deve ser estúpido fácil de criar ...

Depois de alterar para onde / Library / Java / Home está apontado ... você obtém o resultado correto:

cerebro:~ magneto$ java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM)
64-Bit Server VM (build 25.60-b23, mixed mode)

As instruções de desinstalação do Oracle para Java 7 funcionaram para mim.

Excerto:

Desinstalando o JDK Para desinstalar o JDK, você deve ter privilégios de Administrador e executar o comando remove como root ou usando a ferramenta sudo (8).

Navegue até / Library / Java / JavaVirtualMachines e remova o diretório cujo nome corresponde ao seguinte formato: *

/Library/Java/JavaVirtualMachines/jdk<major>.<minor>.<macro[_update]>.jdk

Por exemplo, para desinstalar o 7u6:

% rm -rf jdk1.7.0_06.jdk

Um pouco tarde, mas como este é um problema contínuo com o Mac OSX ...

A solução mais simples que encontrei foi simplesmente remover as coisas do OpenJDK que a Apple instala. Sempre que chega uma atualização do Mac OSX, ela é instalada e você precisa removê-la novamente.

Isso funciona muito bem se você desenvolver aplicativos para o Google App Engine em seu mac usando Java. O OpenJDK não funciona bem e a versão Java que vem com a atualização do Mac OSX Yosemite fará com que o Plug-in Eclipse para App Engine trave em cada implantação com o erro útil: "Tempo limite de leitura esgotado".

Testei "jenv" e outras coisas como definir "JAVA_HOME" sem sucesso. Agora eu e acabo com a seguinte solução

function setJava {
    export JAVA_HOME="$(/usr/libexec/java_home -v $1)"
    launchctl setenv JAVA_HOME $JAVA_HOME
    sudo ln -nsf "$(dirname ${JAVA_HOME})/MacOS" /Library/Java/MacOS 
    java -version
}

(adicionado a ~ / .bashrc ou ~ / .bash.profile ou ~ / .zshrc)

E chamando assim:

setJava 1.8

java_home irá lidar com a entrada errada. então você não pode fazer algo errado. Maven e outras coisas vão pegar a versão certa agora.

Na verdade, olhei um pouco para isso no desmontador, já que a fonte não está disponível.

/ usr / bin / java e / usr / libexec / java_home usam JavaLaunching.framework. A variável de ambiente JAVA_HOME é verificada primeiro por / usr / bin / java e amigos (mas não por / usr / libexec / java_home.) A estrutura usa as variáveis ​​de ambiente JAVA_VERSION e JAVA_ARCH para filtrar as JVMs disponíveis. Portanto, por padrão:

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
    11.0.5, x86_64: "Amazon Corretto 11"    /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
    1.8.0_232, x86_64:  "Amazon Corretto 8" /Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home

Mas definir, digamos, JAVA_VERSION pode substituir o padrão:

$ JAVA_VERSION=1.8 /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home

Você também pode definir JAVA_LAUNCHER_VERBOSE = 1 para ver alguns registros de depuração adicionais no que diz respeito a caminhos de pesquisa, JVMs encontrados, etc., com / usr / bin / java e / usr / libexec / java_home.

No passado, JavaLaunching.framework realmente usava o sistema de preferências (sob o domínio com.apple.java.JavaPreferences) para definir a ordem JVM preferida, permitindo que a JVM padrão fosse definida com PlistBuddy - mas o melhor que posso dizer, que o código foi removido em versões recentes do macOS. As variáveis ​​de ambiente parecem ser a única maneira (além de editar o Info.plist nos próprios pacotes JDK).

A configuração das variáveis ​​de ambiente padrão pode, obviamente, ser feita por meio do seu .profile ou via launchd , se você precisar que elas sejam definidas no nível da sessão.

Editar: essas informações são para visualvm especificamente, não para qualquer outro aplicativo java

Conforme mencionado por outros, você precisa modificar o visualvm.conf

Para a versão mais recente do JvisualVM 1.3.6 no Mac, os diretórios de instalação foram alterados.

Está atualmente em /Applications/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf .

No entanto, isso pode depender de onde você instalou o VisualVM. A maneira mais fácil de descobrir onde seu VisualVM é iniciá-lo e, em seguida, examinar o processo usando:

ps -ef | grep VisualVM

Você verá algo como:

... -Dnetbeans.dirs = / Applications / VisualVM.app / Contents / Resources / visualvm / visualvm ...

Você deseja obter a propriedade netbeans.dir e procurar um diretório e encontrará a pasta etc.

Remova o comentário desta linha no visualvm.conf e altere o caminho para o jdk

visualvm_jdkhome="/path/to/jdk"

Além disso, se você está tendo lentidão com seu visualvm e tem muita memória, sugiro aumentar bastante a quantidade de memória disponível e executá-lo no modo de servidor:

visualvm_default_options="-J-XX:MaxPermSize=96m -J-Xmx2048m -J-Xms2048m -J-server -J-XX:+UseCompressedOops -J-XX:+UseConcMarkSweepGC -J-XX:+UseParNewGC -J-XX:NewRatio=2 -J-Dnetbeans.accept_license_class=com.sun.tools.visualvm.modules.startup.AcceptLicense -J-Dsun.jvmstat.perdata.syncWaitMs=10000 -J-Dsun.java2d.noddraw=true -J-Dsun.java2d.d3d=false"

Eu tive uma situação semelhante, e o seguinte processo funcionou para mim:

1. No terminal, digite

   vi ~/.profile

2. Em seguida, adicione esta linha no arquivo e salve

   export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk<version>.jdk/Contents/Home

   onde a versão é a do seu computador, como 1.7.0_25

3. Saia do editor e digite o seguinte comando para torná-lo efetivo

   source ~/.profile 

Em seguida, digite java -version para verificar o resultado

    java -version 

O que é .profile? De: http://computers.tutsplus.com/tutorials/speed-up-your-terminal-workflow-with-command-aliases-and-profile--mac-30515

O arquivo .profile é um arquivo oculto. É um arquivo opcional que informa ao sistema quais comandos executar quando o usuário cujo arquivo de perfil ele está loga. Por exemplo, se meu nome de usuário for bruno e houver um arquivo .profile em / Usuários / bruno /, todo o seu conteúdo será executado durante o procedimento de login.

MacOS usa / usr / libexec / java_home para encontrar a versão Java atual. Uma maneira de ignorar é alterar o arquivo plist conforme explicado por @ void256 acima. Outra maneira é fazer o backup de java_home e substituí-lo por seu próprio script java_home com o código
echo $ JAVA_HOME

Agora exporte o JAVA_HOME para a versão desejada do SDK, adicionando os seguintes comandos ao ~ / .bash_profile. export JAVA_HOME = "/ System / Library / Java / JavaVirtualMachines / 1.6.0.jdk / Contents / Home" launchctl setenv JAVA_HOME $ JAVA_HOME /// Torne a variável de ambiente global

Execute o comando source ~ / .bash_profile para executar os comandos acima.

Sempre que for necessário alterar o JAVA_HOME, ele pode redefinir o valor JAVA_HOME no arquivo ~ / .bash_profile.

Eu queria mudar a versão padrão do java de 1.6 * para 1.7 *. Tentei os seguintes passos e funcionou para mim:

• Removido o link "java" de / usr / bin
• Criou-o novamente, apontando para o novo local:

ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/bin/java java

• verificado com "java -version"

Java versão "1.7.0_51"
Java (TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot (TM) 64-Bit Server VM (build 24.51-b03, modo misto)