[Tutorial] Instalação manual do Ambiente de Execução Java (JRE) no *Ubuntu Linux

[edson_olivetti]

Olá amigo.
Aqui na empresa tivemos que utilizar o kernel 3.13 para funcional o bbtoken.

Att.,

[Sampayu]

Olá amigo.
Aqui na empresa tivemos que utilizar o kernel 3.13 para funcional o bbtoken.

Att.,

Interessante. Eu não uso token, mas acabei instalando a ferramenta de uso do token, só para testar se ela funcionaria no meu sistema. O BB Token Tool ("bbtokentool") não funcionou aqui, embora o kernel do meu sistema de 32 bits seja versão 3.13.0-45-generic. Mas daí eu instalei o aplicativo WatchKey Manager ("wdtokentool") versão 1.1.0 e funcionou. Bom, pelo menos a janela abriu aqui...

O BB Token Tool foi desenvolvido pela empresa Watchdata Technologies e não passa de uma "versão personalizada" (para o Banco do Brasil) da ferramenta WatchKey Manager que já era desenvolvida e mantida pela própria Watchdata Technologies. O que eu fiz foi instalar o programa original (o "genérico" wdtokentool) para ver se funcionava. Interessante é que pelo visto o "genérico" funcionou.

Antes de instalar o BB Token Tool ou o WD Token Tool é necessário instalar o JRE da Sun. Após isso, pode acessar a página http://www.watchdata.com/service/usbtoken.jsp para testar diferentes versões do BB Token Tool (WatchKey Manager específico para os dispositivos token do Banco do Brasil). Pelo menos no meu caso, nenhuma delas funcionou (ou não funcionou direito) no meu sistema. Curioso também que, no meu caso, a instalação do pacote DEB sempre deu algum problema, mas a instalação do tarball (arquivo .tar.gz) não deu. Digo: no caso dos pacotes DEB, a instalação é concluída com algum erro, e ao tentar executar o programa a janela dele não abra (ou surja apenas uma janela vazia). Mas no caso do tarball a instalação é completada e a janela do programa sempre abre, embora essa janela fique sem elementos.

=> Pelo menos no meu sistema (XUbuntu 14.04 de 32 bits, com kernel 3.13.0-45-generic e Sun JRE 8u31), o que realmente funcionou foi acessar http://www.watchdata.com/brazil/watchkey/index.htm e baixar a instalar o conteúdo do tarball wdtokentool-icp_1.1.0-4 beta3.tar.gz, que é o WD Token Tool (WatchKey Manager "genérico") versão 1.1.0.

Difícil saber se o WD Token Tool funcionará com outras versões de kernel e na arquitetura de 64 bits. Cabe a cada usuário testar. Mas é bom que saibam que pelo menos existe essa opção de instalar uma versão "genérica" do programa, obtida diretamente no website do desenvolvedor.

[cavalheri]

Primeiramente parabéns pelo tutorial!!! bem completo e de fácil entendimento, fiz como mandou e funcionou tudo corretamente!

[Sampayu]

Primeiramente parabéns pelo tutorial!!! bem completo e de fácil entendimento, fiz como mandou e funcionou tudo corretamente!

Bacana, cavalheri, é sempre uma satisfação receber feedbacks positivos como o seu.

[Sampayu]

A todos os que porventura estejam monitorando este tópico: informo que o Sun Java estável / stable / "oficial" a partir de hoje (03/03/2015) passou a ser o 8u40 (versão 8, atualização 40).

Para atualizar seu Sun Java, basta executar este comando de desinstalação:

Código Selecionar Expandir

sudo rm -rf /opt/java

...e em seguida executar os passos da seção 1, que já está atualizada.

[andrevasconcelos]

Amigo criei o link simbólico em /usr/lib/mozilla/plugins e funcionou de boa. Inclusive, no próprio site do Java diz para criar aí.

Outra coisa: instalei o JDK, nele já vem a JRE inclusa. Mas... Encontrei o arquivo "Java" em dois locais diferentes:

1 - /op/jdk1.8.0_40/bin
2 - /op/jdk1.8.0_40/jre/bin

Minha pergunta é: quando for executar o update-alternatives --install, qual destes arquivos usar? Ou tanto faz?

Fontes:

https://www.java.com/pt_BR/download/help/enable_browser_ubuntu.xml

[Sampayu]

Amigo criei o link simbólico em /usr/lib/mozilla/plugins e funcionou de boa. Inclusive, no próprio site do Java diz para criar aí.

Como o próprio nome da pasta mozilla deixa a entender, esse endereço /usr/lib/mozilla/plugins só é válido para navegadores de arquitetura Mozilla (navegadores que utilizam o motor Gecko). Como os navegadores Google Chrome e Google Chromium não usam arquitetura Mozilla / motor Gecko, mas sim uma que usa o motor Blink (baseado no motor Webkit), se na época em que eles suportavam plugins NPAPI (como é o caso do plugin Java) você criasse um atalho dentro de /usr/lib/mozilla/plugins, os navegadores Chrome e Chromium do seu sistema continuariam não "enxergando" o plugin Java.

Na época, o Google Chrome só funcionava com o plugin Java caso um atalho fosse criado em /opt/google/chrome/plugins, e o Google Chromium só funcionava com o plugin Java caso um atalho fosse criado em /usr/lib/chromium-browser/plugins. Depois a Google parou de dar suporte à tecnologia NPAPI, e daí os usuários de GNU/Linux passaram a conseguir usar o plugin somente em navegadores de arquitetura Mozilla (como é o caso do Iceweasel, Firefox e SeaMonkey, por exemplo). Mas isso não significa que ao colocar o atalho em /usr/lib/mozilla/plugins você automaticamente fará com que todos os navegadores "enxerguem" o plugin. Isso não é verdade. Pelo menos não para os navegadores que não sejam de arquitetura Mozilla. Nenhum navegador baseado em Blink / Webkit funciona com esse atalho aí. É o caso não apenas dos navegadores Google Chrome e Chromium, mas também do Konqueror, do Epiphany (atualmente denominado Web) e outros navegadores do GNU/Linux que usam um motor diferente.

Outra coisa: instalei o JDK, nele já vem a JRE inclusa.

Você desenvolve alguma coisa em Java? JDK = Java Development Kit = Kit de Desenvolvimento Java. Salvo raríssimas exceções, instalar um JDK só é útil para quem vai programar em Java, desenvolver aplicações etc. em Java. Se você não for programador/desenvolvedor Java, instalar o JDK é completamente inútil: instalar o JRE e criar o vínculo JRE-plugin-navegador é mais que suficiente para que o(s) seu(s) navegador(es) de arquitetura Mozilla funcione(m) com o plugin NPAPI do Java e que você consiga executar localmente os arquivos do JRE, inclusive os binários executáveis da JVM.

Mas... Encontrei o arquivo "Java" em dois locais diferentes:

1 - /op/jdk1.8.0_40/bin
2 - /op/jdk1.8.0_40/jre/bin[/opt]

Minha pergunta é: quando for executar o update-alternatives --install, qual destes arquivos usar? Ou tanto faz?

Os arquivos que estão dentro da pasta jre evidentemente são os arquivos do JRE, por isto o caminho correto é aquele do item 2. Já os que estão dentro de .../jdk1.8.0_40/bin são os arquivos do kit de desenvolvimento: nessa pasta bin do kit de desenvolvimento há binários executáveis, como por exemplo o arquivo jar (empacotador) e o javac (compilador), que você não encontrará dentro da pasta do JRE porque o JRE não é para desenvolvimento de nada, apenas para execução. Somente desenvolvedores utilizam empacotador, compilador etc.

Essa sua pergunta evidencia que você não é desenvolvedor Java. Sugiro que desinstale o JDK e siga à risca as instruções do tutorial para instalar somente o JRE. Vai facilitar sua própria vida, principalmente em instalações (atualizações) futuras.

Se por acaso você for desenvolvedor, ou tiver alguma necessidade muito específica tal que seja realmente necessário ter o JDK instalado, renomeie a pasta jdk1.8.0_40 para simplesmente jdk e somente então execute os comandos update-alternatives, ln etc. Não se esqueça de corrigir os comandos para que usem o caminho /opt/jdk... ao invés de /op/jdk1.8.0_40.... Deste modo, quando surgir uma nova versão do JDK, não será necessário executar novamente os comandos ln e update-alternatives (para atualizar a localização da pasta do JDK dentro do qual encontra-se o JRE mais recente), pois o nome da pasta continuará sendo jdk, ao invés de mudar de jdk1.8.0_40 para jdk1.alguma-outra-coisa. 

[lperdigao]

Parabéns pelo tutorial. Excelente!!!

Funcionou perfeitamente no meu Ubuntu.

[Sampayu]

Parabéns pelo tutorial. Excelente!!!

Funcionou perfeitamente no meu Ubuntu.

Obrigado. Que bom que funcionou aí.

[Sampayu]

A todos os que porventura estejam monitorando este tópico: informo que o Sun Java estável / stable / "oficial" a partir de hoje (14/04/2015) passou a ser o 8u45 (versão 8, atualização 45).

Para atualizar seu Sun Java, basta executar este comando de desinstalação:

Código Selecionar Expandir

sudo rm -rf /opt/java

...e em seguida executar os passos da seção 1, que já está atualizada.

Recentemente atualizei também o texto das outras seções. Os maiores ajustes foram realizados na seção 3 (troubleshooting).

[Visterine]

Sampayu,
Boa noite.
Tentei instalar no Mint Debian mas sem sucesso.
Segui a dica abaixo da comunidade do Mint funcionou:
Howto install Oracle (Sun) Java JRE for Linux Mint
In this tutorial you can read how to configure java and the java browser plugin.

1. Open up the Terminal (Applications > Accessories > Terminal).

2. Copy/Paste or type the following line of code into Terminal and then press enter:

3. First remove every openjdk package including icedtea-plugin:

sudo apt-get update && apt-get remove openjdk-6-jre

Because libreoffice needs openjdk, your mint linux will automatically install openjdk-7 dependencies.
That would not be any problem for this tutorial.

Just because you can and it's recommended:

sudo apt-get autoremove && apt-get clean

All unnecessary packages will be removed.
Install JAVA

Download the tar.gz java package for linux on www.java.com and store the file in the folder Downloads.
(if you have Linux x64, download the x64 bit package, do not download the RPM!!)

1. In your terminal, run the command thats create a new subfolder in the directory opt.

2. Check if you want to create a x64 or 32 bit java directory.

 32 Bit version:

sudo mkdir -p -v /opt/java/32

 64-Bit version:

sudo mkdir -p -v /opt/java/64

3. Go to your download folder (where you have downloaded java).

4. Unpack it to the created subfolder.

 32 Bit version:

cd ~/Downloads
tar -zxvf jre-7u9-linux-i586.tar.gz
sudo mv -v jre1.7.0_* /opt/java/32

 64-Bit version:

cd ~/Downloads
tar -zxvf jre-7u9-linux-x64.tar.gz
sudo mv -v jre1.7.0_* /opt/java/64

5. The last step is to make the new JRE as default: (Check if you have 32 or x64)

 32 Bit version:

sudo update-alternatives --install "/usr/bin/java" "java" "/opt/java/32/jre1.7.0_09/bin/java" 1

sudo update-alternatives --set java /opt/java/32/jre1.7.0_09/bin/java

 64-Bit version:

sudo update-alternatives --install "/usr/bin/java" "java" "/opt/java/64/jre1.7.0_09/bin/java" 1

sudo update-alternatives --set java /opt/java/64/jre1.7.0_09/bin/java
Install the Firefox Plugin

1. Make for every user in his home directory a subfolder:

mkdir -v ~/.mozilla/plugins

2. Create a symbolic link, so Firefox knows where to find the java plug-in.

 32-Bit version:

ln -s /opt/java/32/jre1.7.0_09/lib/i386/libnpjp2.so ~/.mozilla/plugins/

 64-Bit version:

ln -s /opt/java/64/jre1.7.0_09/lib/amd64/libnpjp2.so ~/.mozilla/plugins/

3. Now you have to restart the browser and check in Firefox if the installation has been succeeded.

Type in the browser: about:plugins
TIP!!

A good thing to do is to set a maximum amount of disk space for the cache.

/opt/java/32/jre1.7.0_09/bin/ControlPanel

/opt/java/64/jre1.7.0_09/bin/ControlPanel

Click on settings under temporary Internet files and set amount the disk space to 50MB.

Note: do this step for every user account.

Fonte: http://community.linuxmint.com/tutorial/view/1091

Fica a dica para possíveis implementações.

Peço a ajuda do amigo para compreender qual a diferença entre os dois tutoriais.

Nas distros derivadas do Ubuntu tem funcionado perfeitamente só no Mint Debian que tive que usar a dica acima.
Abs.

[Sampayu]

Sampayu,
Boa noite.
Tentei instalar no Mint Debian mas sem sucesso.

Oi, Visterine. Analisei o tutorial acima. As únicas diferenças significativas que notei foram estas:

1) Ele ensina a instalar uma versão antiga do Java (versão 7, atualização 9).
Esse tutorial aí está desatualizado. Quem o ler deve instalar a versão mais atual do JRE, que no momento é a versão 8, atualização 45.

2) Ele diz para criar o atalho para o plugin dentro da sua pasta pessoal (~/.mozilla/plugins).
Eu desaconselho fazer isso, porque neste caso a configuração funcionará somente para a conta do usuário que está conectado no momento. Se houver outras contas e um desses outros usuários se conectar, o plugin Java não estará configurado para esse usuário, daí se ele for um usuário básico e por isto não souber configurar o Java, ficará impossibilitado de usufruir do plugin. O ideal é instalar o JRE mais recente e configurá-lo para ser o padrão para todos os usuários, e isso é feito criando os atalhos nas "pastas globais" dos navegadores (Firefox, SeaMonkey etc.) e do sistema (/usr/lib/mozilla/plugins, no caso). As alterações feitas nessas pastas globais surtem efeito em todas as contas do sistema.

O meu tutorial deveria ter funcionado no Mint. Mas não funcionou, o que significa que há alguma diferença na estrutura e configuração de pastas e/ou arquivos desse LMDE / Mint Debian, em relação ao Ubuntu. Como não conheço tal estrutura, acabei de baixar o ISO do LMDE MATE versão 2 ("Betsy"), de 32 bits, e rodá-la no modo "live CD", a partir da Virtual Box. O que identifiquei foi que dentro de /usr/lib/mozilla/plugins há o link simbólico libjavaplugin.so apontando para /etc/alternatives/mozilla-javaplugin.so, que evidentemente é o arquivo errado. Foi somente por isto que o meu tutorial não funcionou.

A maneira mais prática de corrigir isso é executar este comando no terminal do shell:

No LMDE de 32 bits:

Código Selecionar Expandir

sudo ln -sf /opt/java/jre/lib/i386/libnpjp2.so /usr/lib/mozilla/plugins/libjavaplugin.so

No LMDE de 64 bits:

Código Selecionar Expandir

sudo ln -sf /opt/java/jre/lib/amd64/libnpjp2.so /usr/lib/mozilla/plugins/libjavaplugin.so

O comando acima corrigirá o link simbólico /usr/lib/mozilla/plugins/libjavaplugin.so, que daí passará a apontar ou para /opt/java/jre/lib/amd64/libnpjp2.so (no caso do JRE para 64 bits) ou para /opt/java/jre/lib/i386/libnpjp2.so (no caso do JRE para 32 bits). Como esse link simbólico, agora corrigido, está dentro de uma pasta global do sistema, essa modificação surtirá efeito nas contas de todos os usuários.

Em suma: basta desinstalar completamente o JRE instalado segundo o outro tutorial, em seguida efetuar a instalação completa do JRE conforme este tutorial, mas criar o link simbólico acima para garantir que o arquivo libjavaplugin.so aponte para o destino correto.

A solução acima resolveu o problema aqui no LMDE que estou rodando. Caso não resolva no seu caso, avise-me que daí podemos tentar uma modificação um pouco mais profunda. Mas creio que a solução apresentada acima será suficiente.

[Visterine]

ok Sampayu
Obrigado, vou tentar e depois coloco o resultado.

[farbus]

Amigos, alguém que usa VM encontrou problemas recentemente? A que eu uso sempre funcionou sem problemas, nunca precisei fazer nada de diferente, no entanto parou de funcionar nessas últimas semanas.
Eu uso o firefox, mas com outros browsers o problema é o mesmo, a página carrega, mas na parte do login da conta fica eternamente carregando...
Eu segui o tuto direitinho, tentei até criar outra VM, mas não teve diferença alguma...

[Sampayu]

Amigos, alguém que usa VM encontrou problemas recentemente? A que eu uso sempre funcionou sem problemas, nunca precisei fazer nada de diferente, no entanto parou de funcionar nessas últimas semanas.
Eu uso o firefox, mas com outros browsers o problema é o mesmo, a página carrega, mas na parte do login da conta fica eternamente carregando...
Eu segui o tuto direitinho, tentei até criar outra VM, mas não teve diferença alguma...

Deixe-me ver se entendi: você está executando o Ubuntu dentro de uma VM? Quais são os navegadores que não estão funcionando?

Observe que, tal como explicado na Introdução deste tutorial, desde a versão 35.X os navegadores Google Chrome e Chromium não funcionam mais com plugins NPAPI, e que também o navegador Opera deixou de funcionar com plugins NPAPI desde o advento da versão 26 desse navegador. Isso significa que atualmente um número muito pequeno de navegadores para GNU/Linux funciona com o plugin Sun Java: Firefox, SeaMonkey e Iceweasel são os três navegadores que eu conheço que ainda funcionam com o plugin Sun Java.

Às vezes a tela de login do banco demora para carregar e é preciso limpar o cache do navegador e dar refresh (atualizar) a página para que o módulo (applet Java) seja carregado corretamente. Se você não fez isso ainda, veja se as dicas que constam na seção de Troubleshooting (do item 3.4 em diante) conseguem ajudar você. Se nada resolver, poste aqui o resultado destes comandos:

Código Selecionar Expandir

ls -lask /usr/lib/mozilla/plugins

Código Selecionar Expandir

uname -a

Código Selecionar Expandir

java -version

Também informe o que ocorre quando você acessa http://www.java.com/pt_BR/download/installed8.jsp?detect=jre