baisse

Oi de novo.

Nos últimos 12 meses (aproximadamente), vários artigos especializados em T.I. têm apontado falhas de segurança encontradas no JRE da Sun/Oracle. Algumas dessas falhas afetam também as implementações livres (tais como o JRE OpenJDK e o JRE GIJ), outras afetam apenas o JRE da Sun/Oracle. Por conta disto, os desenvolvedores dos navegadores web têm inserido mecanismos que alertam o usuário a respeito dos riscos de se utilizar o Java. Os navegadores não chegam a impedir a utilização do Java, mas avisam que há riscos envolvidos.

Só que a gente precisa do Sun/Oracle, porque (por exemplo) os nossos bancos utilizam applets Java que em muitos casos só funcionam com o JRE da Sun/Oracle. Então o negócio é instalar o Java, mas ser cauteloso: só autorizar a execução do Java plugin quando o applet que estiver solicitando isto for de um website confiável (como é o caso do website do seu banco, por exemplo).

Junte-se a isso aquele bug de compatibilidade do Sun Java com os navegadores, e o resultado é que você vai ver 2 tipos de mensagens aparecerem em seus navegadores:

1. Avisos de plugin desatualizado (por conta do "bug da falta de diálogo" entre o Java e os navegadores); e
   
2. Avisos de segurança (que iriam aparecer mesmo que o bug acima não existisse, porque os navegadores estão mesmo alertando os usuários a respeito dos riscos de se usar o Java).
   

Em outras palavras: você não cometeu nenhum erro na instalação, pois se tivesse cometido o Java não estaria funcionando. Se você seguiu todos os passos da seção 1 do tutorial (e inclusive verificou a versão do Java com o comando java -version e acessando a página de testes da Sun e, nos dois casos, a resposta obtida foi que seu Java está instalado e é o 7u21), então com certeza o problema está é naquele bug de versão e nos inevitáveis alertas de segurança que os navegadores estão emitindo.

A solução para esse problema é, na verdade, um paliativo (que você aliás já vem executando): se você estiver em um website no qual você confia, então sempre clique em Executar esta vez e jamais bloqueie a execução do applet Java, quando o navegador perguntar se você deseja bloquear ou não o applet que está sendo carregado pelo website.

No caso tanto do Chrome quanto do Chromium, você poderá executar o navegador a partir do terminal do shell, para poder incluir a opção --allow-outdated-plugins e com isto não ter que ficar toda hora clicando em Executar esta vez. Já o Firefox não possui este tipo de recurso, portanto o jeito é ficar clicando no botão Executar esta vez...

Daqui a pouco a equipe do Google atualiza o Chrome e o Chromium (ou a equipe da Sun/Oracle lança uma nova atualização para o Java) e daí o bug some! Isso já aconteceu antes, rs.

Quanto aos alertas de segurança, a tendência é eles continuarem sendo exibidos pelos navegadores, até que a Sun/Oracle reconquiste a confiabilidade perdida e daí os desenvolvedores dos navegadores sintam-se suficientemente seguros para remover os alertas de segurança, nas próximas versões dos navegadores deles.

Muito obrigado Yuri!

Oi, baisse.

Resumidamente: sim, pode executar tranquilamente o passo 1.3. O comando de remoção que você executou é (mais do que) suficiente para você poder executar o passo 1.3 sem ter estresse.

Agora vou lhe dar a explicação que eu gostaria que alguém tivesse me dado quando eu entrei em contato pela primeira vez com o comando update-alternatives e não fazia ideia do que diabos era isso (e tive que me virar para entender o que é e como funciona, porque não encontrei explicações suficientemente didáticas, na internet e nos fóruns): o comando update-alternatives serve para que você possa instalar, em seu sistema, várias versões (ou implementações) diferentes de um mesmo programa, mantidas ou não pelo mesmo desenvolvedor, e então alternar entre essas versões e/ou implementações. As diferentes versões e implementações são instaladas em diversas pastas diferentes, mas daí você usa o update-alternatives para criar uma "lista" dessas versões e implementações que você possui e então definir qual delas será a "padrão" que o seu sistema vai usar. Daí, sempre que você quiser usar uma outra versão ou implementação, basta executar o update-alternatives e informar qual versão ou implementação você deseja que passe a ser a "padrão" do sistema. Você pode fazer isso ou de forma interativa, usando o comando update-alternatives --config apelido, ou então de forma não-interativa, usando o comando update-alternatives --set apelido caminho. No caso, apelido é o apelido que você atribuiu a esse "grupo de versões e implementações de um mesmo programa" e caminho é o local em que está a versão ou implementação que você deseja que passe a ser o novo padrão do seu sistema.

No caso dos JRE, o update-alternatives permite, por exemplo, alternar entre diferentes versões do Oracle JRE (6u20, 7u10, 7u21 etc.) que estejam presentes no seu sistema, ou ainda alternar entre diferentes implementações do JRE, como por exemplo o OpenJDK (uma implementação livre do Java) e o GIJ (outra implementação livre do Java). Repare que, no caso dos JRE do seu sistema, esse grupo de JRE recebeu o apelido java. Exemplo: o comando interativo update-alternatives --config java exibirá a lista de JRE cadastrados no grupo java e pedirá para você escolher na lista qual deles você quer que se torne o JRE padrão. Já o comando não-interativo update-alternatives --set java /opt/java/jre/bin/java faz com que o JRE padrão do seu sistema passe a ser aquele que se encontra em /opt/java/jre/bin/java.

O update-alternatives faz isso basicamente modificando o link que aponta para o JRE padrão. O arquivo /usr/bin/java é apenas um link simbólico: você instala "um monte de JRE", em várias pastas diferentes, mas o update-alternatives faz com que o seu Linux sempre considere que o Java está instalado em /usr/bin/java, daí o /usr/bin/java redireciona o seu sistema para a pasta que você definiu como padrão (que pode ser a pasta do Oracle JRE 7, pode ser a do OpenJDK ou alguma outra).

Além do JRE 7 da Sun/Oracle, você provavelmente tem aí no seu sistema o OpenJDK, e talvez também tenha o GIJ (GNU Interpreter for Java), que recentemente passou a ser instalado junto com as últimas atualizações de algumas distribuições Linux (como é o caso da Ubuntu). Exemplo: aqui no meu XUbuntu 12.04 de 32 bits, há cerca de 1 mês o GIJ versão 4.6 foi instalado em /usr/bin/gij-4.6.

Ocorre que aquele comando sudo update-alternatives --remove-all java que você executou remove todos os vínculos para todos os JRE do seu sistema, portanto é um comando bem radical. Veja bem: ele não remove os JRE, mas remove as ligações para eles. É como se eles tivessem sido descadastrados da "lista de JRE", embora esses JRE continuem presentes no seu sistema. Por isto, seu sistema Linux "deixou de saber" que aqueles JRE estão presentes e qual é a localização deles. Se (por exemplo) você tiver aí o OpenJDK e o GIJ (além do Oracle que você instalou), então você possui aí três JRE instalados, mas o seu Linux já não "sabe" mais isso.

Você poderia ter simplesmente executado este comando, no terminal:

sudo update-alternatives --remove java /usr/lib/jvm/java-7-oracle/bin/java

O comando acima significa "remova do grupo java o JRE que se encontra em /usr/lib/jvm/java-7-oracle/bin/java", ou seja, ele removeria apenas o vínculo para o JRE que você possui em /usr/lib/jvm/java-7-oracle/bin/java: os demais vínculos (para o OpenJDK e o GIJ, por exemplo) seriam preservados.

Mas tudo bem, você fez uma limpeza geral nos vínculos e excluiu o grupo java. Isto não chega a ser um problema, caso a sua intenção seja usar apenas o JRE da Sun/Oracle. O comando do item 1.3 do tutorial irá recriar o grupo java e incluir na lista o Sun/Oracle java que você puser em /opt/java/jre. Mas não se esqueça de que você excluiu apenas os vínculos. Ficou faltando excluir a pasta do Oracle Java que você havia instalado em /usr/lib/jvm/java-7-oracle. Para excluí-la, execute este comando, no terminal:

sudo rm -rf /usr/lib/jvm/java-7-oracle

Após excluir a pasta java-7-oracle, execute normalmente os passos da seção 1 do tutorial.

Após instalar o Sun Java, você pode querer tentar recuperar seus JRE "alternativos". Caso esteja em um Ubuntu de 32 bits, procure seus JRE nestes locais:

1. OpenJDK: /usr/lib/jvm/java-6-openjdk-i386/jre/bin/java
   
2. GIJ: /usr/bin/gij-4.6
   

Para adicioná-los à "lista dos JRE", os comandos são estes:

1. Adicionar o OpenJDK com prioridade 11 (número maior que o da prioridade 10 usada no item 1.3 do tutorial):
   

   sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-6-openjdk-i386/jre/bin/java 11

   
   

2. Adicionar o GIJ com prioridade 12 (número maior que o das prioridades 10 e 11, assinaladas respectivamente para o Sun Java e para o OpenJDK):
   

   sudo update-alternatives --install /usr/bin/java java /usr/bin/gij-4.6 12

   
   

Como no item 1.3 do tutorial você executou o comando update-alternatives --set java /opt/java/jre/bin/java, o JRE padrão continuará sendo o que se encontra em /opt/java/jre/bin/java (daí a "sacada" de sempre instalar o Sun Java naquela pasta "jre": quando você instala numa pasta que tem o nome da versão, como por exemplo "jre-7u21", você fica limitado, porque teria que ficar executando o update-alternatives para atualizar a lista do grupo java, sempre que você instalasse um novo JRE, em uma pasta com nome diferente, como por exemplo "jre-7u22", "jre-7u23" etc.).

Por fim, mas não menos importante: aqui em casa o Google Chrome voltou a dar pane de versão com o Java (estou executando o Sun Java versão 7, atualização 21). Se isto acontecer com você, ignore: é um bug antigo, que inclusive já foi solucionado pelo time do Google, mas que de tempos em tempos retorna (veja a seção 4 do tutorial), provavelmente porque o pessoal da Sun/Oracle desenvolve uma nova versão do Java mas não a testa em todos os navegadores (ou a equipe do Google desenvolve uma nova versão do navegador Chrome mas não a testa com todos os plugins, como por exemplo o Sun Java).

Por isto, o navegador Chrome talvez lhe diga que o plugin Java está desatualizado, mesmo após você instalar a última (a mais recente) versão do Sun Java. Simplesmente clique em "Executar esta vez" e prossiga. Se o botão aparecer de novo, clique de novo em "Executar esta vez". Se perder a paciência, execute o --allow-outdated-plugins que eu explico lá na seção 4.

Era isso.

Agora vou dormir, rs.

Yuri,

Entendi suas explicações sobre o comando. Excelente! Muito obrigado! O que fiz de diferente foi alterar as prioridades, dando prioridade para o JRE da Sun/Oracle.

Infelizmente, alguns problemas persistem:

1. O Chromium não está reconhecendo o plugin, mas se eu clico em Executar esta vez dá certo, tanto na página do banco quanto na página de teste do Java. Ainda assim surge aquele aviso assustador rsrs O Java encontrou componentes da aplicação que poderiam indicar um problema de segurança.

2. No Firefox o plugin foi reconhecido e apesar de haver uma certa demora para carregar funciona na página de teste do Java, mas no site do banco aparece o aviso O Java encontrou componentes da aplicação que poderiam indicar um problema de segurança. Clico em Não para não bloquear a execução e só assim dá certo.

Esses problemas se devem aos navegadores ou cometi algum erro na instalação? A solução para esses problemas é a mesma que você apresentou para o Chrome?

Valeu, Yuri!

Yuri,

Acredito que a minha dúvida a seguir tenha sido parcialmente discutida nas mensagens anteriores, mas ainda não estou seguro.

Antes de conhecer este tutorial havia seguido um outro tutorial, que lá pelas tantas dizia para executar

sudo update-alternatives --install "/usr/bin/java" "java" /usr/lib/jvm/java-7-oracle/bin/java 1

Como ultimamente não tenho conseguido acessar o site do banco resolvi testar seu tutorial. Ocorre que fiquei na dúvida se deveria ou não executar o passo 1.3 por causa do comando acima e então executei

sudo update-alternatives --remove-all java

Será que agora posso executar o passo 1.3 e seguir os procedimentos do restante do tutorial?

Valeu!