Quando digo que eu recomendo update-java-alternatives para alternativas Java, suponho que os provedores Java estejam instalados para fornecer a infraestrutura necessária. Esse é o caso dos pacotes OpenJDK disponíveis no Debian e seus derivados, mas não necessariamente para outros pacotes JDK, e é improvável que seja o caso de um JDK instalado manualmente. Os pacotes do Oracle JDK criados usando java-package do fornecem a infraestrutura necessária. Não acho que seja um uso sensato do tempo das pessoas configurar as alternativas para todos os comandos Java manualmente: se você quiser instalar o Oracle JRE ou o JDK, use java-package .
O ponto de update-java-alternatives é permitir uma configuração consistente das ferramentas JRE / JDK padrão. Em teoria, isso poderia ser feito usando update-alternatives ’ --slave relacionamentos; no entanto, isso geralmente não funciona para pacotes do OpenJDK porque você pode ter um subconjunto das ferramentas disponíveis instaladas, com as quais update-alternatives não lida. Daí a criação de update-java-alternatives , que cuida de todas as ferramentas que estão instaladas e não reclama de mais nada. Para que update-java-alternatives funcione, os pacotes JRE / JDK precisam fornecer as informações necessárias em um arquivo em /usr/lib/jvm ( por exemplo, .java-1.8.0-openjdk-amd64.jinfo ). ( update-alternatives nas distribuições baseadas em RPM, aparentemente, lidam com isso, mas eu não examinei os detalhes.)
O próprio Java tem sua própria maneira de escolher entre vários JREs / JDKs instalados, a variável de ambiente JAVA_HOME . update-java-alternatives e JAVA_HOME são realmente complementares: deve ser possível definir ambos para apontar para diferentes JREs / JDKs, dependendo de suas necessidades. update-java-alternatives permite que o administrador do sistema especifique qual JRE / JDK deve ser o padrão em um sistema (na verdade, pode-se considerar que permite aos mantenedores de pacotes especificar qual deve ser o padrão - é tudo deveria funcionar de forma transparente para os administradores e usuários). JAVA_HOME permite que qualquer usuário ou script de inicialização especifique qual JRE / JDK deve ser usado em um ambiente específico. Onde as coisas desmoronam um pouco nos sistemas estilo Unix é com PATH -handling, pois PATH não pode ser definido para usar dinamicamente JAVA_HOME para escolher java , javac etc. (diferentemente do Windows); por isso, lembre-se de redefinir seu PATH quando alterar seu JAVA_HOME , se quiser que seu padrão java etc. acompanhe sua configuração JAVA_HOME (adicione $JAVA_HOME/bin ao início de seu PATH ).
O resumo de tudo isso é semelhante à minha resposta a A configuração de variáveis de ambiente pode ser substituída por 'update-alternatives' ? : o administrador do sistema deve usar update-java-alternatives para definir o JRE / JDK padrão para o sistema (ou deixar os pacotes escolherem eles mesmos) e os usuários podem usar JAVA_HOME para definir o JRE / JDK para um ambiente específico .