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

108

(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 .

Christopher Schultz
fonte
Digite 'which java' e siga a localização atual. /usr/bin/javaé apenas um link simbólico
Brian Roach
11
Já estive lá, fiz isso. /usr/bin/javaaponta para /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java. O Versionsdiretório não contém um link simbólico para o JDK 1.8.0. Em vez disso, ele contém um diretório chamado útil, Aque Currentaponta para. Anão é um "JAVA_HOME. Ele tem um subdiretório chamado Commandsque tem um javacomando, mas é um binário universal opaco que faz sabe-se lá o quê. Suspeito que ele usa java_homeetc. para decidir qual JVM usar.
Christopher Schultz
2
Se estiver fora do tópico, migre em vez de fechar. FWIW, trata-se de "ferramentas de software comumente usadas por programadores", portanto, fechar "fora do tópico" é falso.
Christopher Schultz
Sim, isso é frustrante! Quero apenas um JDK para todos, ou talvez 2 para que eu possa alternar entre 1,7 e 1,8 facilmente.
Brian
1
Achei esta resposta SO útil para esta pergunta: stackoverflow.com/a/44169445/2987755
dkb

Respostas:

89

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.

Ian Roberts
fonte
Este não parece ser o caso em meu sistema. Iniciar o VisualVM antes da instalação do JDK 1.8 funcionou. Após JDK1.8, o VisualVM mostra a tela inicial e, em seguida, morre. Mover o diretório JDK1.8 para fora de / Library / Java restaura sua capacidade de execução.
Christopher Schultz
@ChristopherSchultz Eu dei uma olhada dentro do pacote VisualVM e descobri que não é um aplicativo appbundler normal. Veja minha edição para uma possível solução alternativa.
Ian Roberts
Desculpe, escrevi meu comentário anterior antes de sua edição. Vou verificar como o VisualVM é executado usando essa técnica, mas é improvável que seja universalmente aplicável. Eu tenho um monte de outros softwares baseados em Java que eu executo também como Eclipse, JasperReports iReport, etc. que provavelmente serão afetados por isso. Acho que prefiro apenas mover o diretório JDK1.8 para outro lugar e usá-lo explicitamente com JAVA_HOME nas (poucas) vezes em que realmente precisar.
Christopher Schultz
1
Sim, você está certo, JAVA_HOMEé o caminho a seguir e, em geral, sua melhor aposta é especificar a versão secundária necessária em outros casos. Com base na desmontagem, acontece que você pode export JAVA_VERSION=1.7tornar java_homepadrão a exibição de JKD7 em vez de JDK8, mas isso é interrompido java_home -v 1.6porque o java-homeinterpreta como uma restrição adicional e desiste devido a restrições mutuamente insatisfatórias, então apenas segue com o padrão 1.8 mesmo com a --failfastopção.
andrewdotn
2
Não consigo entender por que o Painel de Controle do Java de Preferências do Sistema não apresenta apenas uma lista para selecionar, em vez de ter que recorrer a scripts / comandos de shell. Suspeito que isso seja apenas para miniaplicativos executados no navegador ...
JGFMK
51

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.

void256
fonte
Isso funcionou para mim. Tive de usar esse ajuste para manter o plug-in Idea Sbt funcionando para mim no MacOS. Estou mencionando isso no meu blog agilebuild.blogspot.com/2014/02/…
antoine
Isso funciona, mas parece um pouco complicado e pode não parecer um procedimento de operação padrão. Eu vagueio se houver uma abordagem melhor.
Weibo Li
Eu ainda gostaria de uma solução para isso, mas para definir o JDK para Intellij usar, adicionei isso ao meu zshenv: export IDEA_JDK = /usr/libexec/java_home -v 1.7. Acho que vou fazer o mesmo para JAVA_HOME ...
David Resnick
Consigo usar esta resposta para evitar o uso do Java 9 para lançar aplicativos de clique duplo (devido a um problema no Keystore Store explorer). Obrigado!
Nicolas Henneaux
2
Um trecho da Instalação do JDK e do JRE no macOS : Depois de instalar o Java para macOS 2012-006, /usr/bin/javaencontrará o JDK mais recente instalado e o usará para todas as ferramentas de linha de comando relacionadas ao Java no /usr/bin.
Jeremy Kao
7

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!

User404
fonte
1
Inacreditável, mas funcionou ... Obrigado Mac OS Mojave
Michał Dobi Dobrzański
5

É 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)
jrypkahauer
fonte
1
Não é assim que funciona: /Library/Java/Homeé de fato um link simbólico, mas aponta para o /System/Library/Frameworks/JavaVM.framework/Homequal está em uma grande confusão de links simbólicos que finalmente leva você a ... um comando mágico que determina o JRE certo para iniciar. Observe que /usr/libexec/java_hometambém se conecta a essa magia. Portanto, você pode interromper tudo apenas substituindo os links simbólicos e apontando para um único JRE, mas terá que atualizar isso todas as vezes. Evidentemente não há nenhum comando semelhante set_preferred_jvm_versionou semelhante.
Christopher Schultz,
1
A vantagem dessa técnica, porém, é que ela não exige que você configure em JAVA_HOMEnenhum lugar. Vou brincar com essa técnica para ver se ela resultará na inicialização de programas baseados em Java com a VM Java "preferida". Eu suspeito que sim, mas é muito frágil.
Christopher Schultz,
Bem, atualmente eu só tenho isso em .bash_profile:export JAVA_HOME=`/usr/libexec/java_home -v 12`
jrypkahauer
Isso não funciona para clicar duas vezes em um ícone, o que era quase todo o ponto. Soluções que funcionam apenas na linha de comando ... não são soluções.
Christopher Schultz
3

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

duma
fonte
2
Esta questão não era sobre a desinstalação ... era sobre escolher a JVM "primária" daquelas instaladas ...
Christopher Schultz
3

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".

Mo'in Creemers
fonte
1
Engraçado ... Achei que a Apple havia removido o Java completamente neste momento. Não me lembro de ter removido manualmente o Java 1.6 JVM da Apple e ele definitivamente não está mais aqui. De qualquer forma, isso realmente não corrige o problema original que era especificar a JVM preferida dada uma seleção que foi instalada.
Christopher Schultz de
Você está certo. Não responde à pergunta. Ele responde a isto: Se você remover o JVM que está sendo usado, o 'próximo' na lista será usado. Talvez isso ajude.
Mo'in Creemers
isso explica por que, depois de executar uma instalação do jdk 8, ele não aparece na pasta JavaVirtualMachines? Tudo o que vejo é "1.6.0.jdk" independentemente da versão que instalo.
whyoz
@whyoz Acabei de instalar o jdk-8u31-macosx-x64 no osx 10.10.2 e a VM foi instalada na pasta JavaVirtualMachines conforme o esperado.
Mo'in Creemers
Você está executando o Parallels por acaso? Eu instalei no lado do Windows do Parallels e 8u31 como esperado .. não apenas no lado do Mac ..
whyoz
3

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.

Yuna Braska
fonte
1

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.

Dan Walters
fonte
Esta é uma ótima informação, Dan. Usar .profilenão é útil para o meu caso de uso (iniciar um aplicativo, por exemplo, do launchpad), mas a dica launchdé boa. Vou ter que tentar, já que a recente loucura de versões do Java significa que tenho várias gerações de Java instaladas simultaneamente, com níveis variados de confiança (pessoal).
Christopher Schultz
-2

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"
Celandro
fonte
Conselho ruim: modificar o script de inicialização para um aplicativo específico provavelmente interromperá o aplicativo e não resolverá o problema original de alterar a JVM padrão para o sistema operacional.
Christopher Schultz de
Infelizmente, conforme mencionado por outros, o jvisualvm não usa métodos padrão para escolher um jvm. Esta é a única solução para este aplicativo.
Celandro
Como afirmei em minha resposta, você não precisa modificar nada dentro do pacote do aplicativo em si, o aplicativo pode carregar sua configuração de ~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.conf.
Ian Roberts
-2

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.

Tony
fonte
Isso não funcionará ao iniciar o VisualVM a partir do Launchpad. Iniciar a partir da linha de comando nunca é um problema, pois você pode definir a variável de ambiente JAVA_HOME.
Christopher Schultz
-2

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.

Rajat
fonte
Qualquer coisa que dependa de variáveis ​​de ambiente não funcionará. A questão é que os aplicativos iniciados por meio do LaunchPad etc. não terão essa configuração ambiental. O hack do plist acima parece ser o "melhor" porque, na verdade, atinge o resultado desejado. Não tenho certeza sobre as desvantagens, ainda. Veja a resposta da @Tony que tem o mesmo problema.
Christopher Schultz
-3

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)

user2756423
fonte
Não responde à pergunta: não afetará o comportamento de /usr/libexec/java_home.
Christopher Schultz