Instalação do Java [Bóson Treinamentos]

Renan Rischiotto · 06 de Maio de 2014, 01:01

Boa noite!

Nestes dois vídeos abaixo, o Fábio ensina a instalar o Java.

https://www.youtube.com/watch?v=qTzlaeGsVfY

https://www.youtube.com/watch?v=mnC_Gf3VEM0

São métodos diferentes do que costumamos ver na rede, como por exemplo do tópico que eu criei.

Gostaria de saber se os métodos que ele usou tem alguma diferença dos que eu postei. No primeiro vídeo ele adiciona um PPA pra instalar o OpenJDK, no segundo vídeo, quando ele mostra como instalar o Java da Oracle, além da PPA ele configura váriáveis de ambiente Java. Isso é necessário?

Abraços!

rodrigo.miguel · 06 de Maio de 2014, 11:10

Vou aproveitar o tópico e compartilhar outro método para instalar e ativar o Oracle Java 7 (32 bits), versão em pacote tar.gz do site oficial.

Vídeo: http://www.youtube.com/watch?v=VntOWXlkl5U&feature=share&list=PLDd4HYheS_uIkuOspXdzPeHF8Gw1rrPzo

Por que instalar o pacote tar.gz?

Tentei de várias formas (OpenJDK, PPA, etc). Mas o Internet Banking da Caixa Econômica e o Guardião Itaú só funcionaram com a instalação manual do Java Oficial da Oracle.

Se você está tendo problemas com estes bancos, tente este método.

A lista com os comandos está dispoível na descrição do vídeo, e neste link: http://linuxuserlog.blogspot.com.br/2014/05/internet-banking-caixa-e-itau-no-ubuntu.html

Este método deve ser compatível com várias Distribuições, como Debian e Linux Mint. A instalação da versão 64 bits é similar (bastando adaptar o caminho das pastas em alguns comandos). Exemplo: sudo ln -s /usr/java/jre1.7.0_55/lib/amd64/libnpjp2.so

Sampayu · 09 de Maio de 2014, 02:22

Comentando as postagens anteriores:

1) Neste primeiro vídeo o Fábio adiciona um repositório não-oficial (e portanto não-confiável) a partir do qual será baixado o instalador do Java da Oracle. Esse instalador, por sua vez, é um pacote DEB especial, que executa um script que atualiza o JRE inteiro.

O ruim desse método é que você vai depender de o mantenedor desse repositório manter os arquivos do repositório sempre atualizados. Além disso, você também tem que confiar no mantenedor, claro: confiar que (por exemplo) ele não vai incluir nenhum código malicioso dentro dos arquivos que você vai baixar e instalar no seu sistema a partir do repositório que ele mantém na internet. Eu tô fora.

2) Neste segundo vídeo o Fábio mostra como instalar usando o repositório da equipe Webupd8team. Esse é um procedimento atualmente bastante popular na internet, existem "trocentos" tutoriais na internet ensinando a instalar via repositório do Webupd8team. Mas eu particularmente também não gosto de usar esse método, e é pela mesma razão do método anterior: eu não confio em repositórios de terceiros. Só confio em baixar os arquivos do Java diretamente do website da Oracle mesmo. Mas isso sou eu...

Ainda em relação a esse segundo vídeo: não é necessário configurar variáveis de ambiente caso você esteja instalando o JRE apenas para usá-lo no seu navegador (via plugin). Como o nome diz, as variáveis de ambiente são do ambiente, ou seja, são do seu sistema operacional (não são da internet, do seu navegador etc.): seu plugin não vai utilizá-las. Se (por exemplo) você for desenvolver programas em Java, pode ser interessante (por exemplo) acrescentar a pasta do seu JRE ou a do seu JDK à variável PATH do seu sistema, por exemplo, ou ainda criar a variável JAVA_HOME para informar que o seu JRE padrão está instalado (por exemplo) em /opt/java/jre (ou em /usr/java/jre, ou em outro lugar).

Mas nada disso é necessário para que o seu JRE e o plugin funcionem, tanto que no meu tutorial eu nem toco no assunto e mesmo assim tudo funciona. Não tem nada a ver uma coisa com a outra, são temas distintos.

Inclusive, no final do segundo vídeo o Fábio diz que vai confirmar se as variáveis de ambiente estão configuradas e daí ele executa o comando

Código Selecionar

java -version
no terminal do shell, porém esse comando não serve para ver variáveis de ambiente, ele apenas faz a JVM padrão do sistema informar qual é a versão dela.

3) Falando em variáveis de ambiente: no Linux, o comando que lista as variáveis de ambiente é o comando printenv. Por exemplo, se você quiser ver quais são as variáveis de ambiente que contêm a palavra java, deverá executar este comando, no terminal do shell:

Código Selecionar

printenv |grep java

Nota: o comando printenv gera a lista das variáveis do ambiente, daí o caractere | envia essa lista para o comando grep, que por sua vez percorre essa lista procurando a palavra java (porque o comando grep procura a palavra que você digita à direita dele, e no caso eu digitei java). Daí o comando grep exibe na tela somente as linhas da lista na qual a palavra procurada (java, no caso) aparece.

4) A respeito deste vídeo, ele basicamente reproduz o que o manual de instalação da Oracle sugere (inclusive instalando o JRE dentro de /usr/java, ao invés de em /opt/java).

Eu não gosto deste método da Oracle porque, como explico lá no meu tutorial, a pasta /usr foi criada para armazenar arquivos do usuário e de aplicações que fazem parte da distribuição e foram instalados pelo usuário para uso próprio, enquanto que a pasta /opt existe para se instalar tudo o que não faz parte da distribuição, como é o caso do JRE da Oracle, que por ser proprietário não faz parte da distribuição e por isto é instalado como um optional (um "opcional"). É por isto que eu instalo o Java da Oracle na pasta /opt. É uma questão de organização.

...mas claro que para o programa em si é indiferente onde você o instala: se instalá-lo e configurá-lo corretamente, ele vai funcionar, independentemente de onde ele esteja: /opt, /usr ou o que for.

Outra coisa que não gosto nesse manual de instalação da Oracle é que ele diz para criarmos a pasta do JRE com o nome completo desse JRE (exemplo: /usr/java/jre1.7.0_55/). Acho isso péssimo, porque quando o usuário for atualizar o Java para (por exemplo) a versão 1.7.0_56, ele vai ter que criar o caminho /usr/java/jre1.7.0_56/ e excluir a pasta jre1.7.0_55. É por isto que no meu tutorial eu crio a pasta /opt/java/jre/ (a palavra jre aparece isolada, sem o número da versão do JRE) e daí toda vez que eu atualizo o java os comandos do meu tutorial excluem os arquivos da pasta "jre" e colocam os arquivos novos dentro dessa mesma pasta.

A principal vantagem desse segundo método é que você não vai precisar atualizar os links que você havia criado com o comando ls. Se você criou o link ls (para os seus navegadores Firefox, Opera, Chrome, Chromium etc.) apontando para a pasta /usr/java/jre1.7.0_55/, após a atualização via manual da Oracle você vai ter que executar novamente o ls para todos os seus navegadores, pois só assim o link passará a apontar para o novo caminho, que agora será /usr/java/jre1.7.0_56/. Porém, se a pasta sempre tem o mesmo nome "jre", não é necessário ficar executando novamente o comando ls porque a pasta ainda é a mesma, com o mesmo nome e estando no mesmo lugar: apenas os arquivos dentro dela foram substituídos pelos da nova versão do Java.

Ainda outra vantagem é que você fica com (e somente com) a última (a mais recente) versão do Java instalada em seu sistema, dentro da pasta "jre" (ao invés de ficar com um JRE dentro da pasta jre1.7.0_55, outro JRE dentro da pasta jre1.7.0_56, e assim por diante).

E isso é bom por questões de segurança: se você instalou a versão mais recente do Java, é melhor que exclua todas as demais (antigas), porque quando o Java é atualizado, muitas vezes é porque encontraram falhas de segurança na versão anterior, daí deixar essa versão anterior instalada pode abrir uma brecha para oportunistas mal-intencionados.

O meu tutorial é grande mas vale a pena lê-lo todo, porque nele eu explico esses e vários outros pormenores que justificam o fato de eu haver estruturado o meu tutorial da maneira como o estruturei.

rodrigo.miguel · 09 de Maio de 2014, 09:09

O how to que postei é mais completo que o manual do site da Oracle. A questão do nome das pastas e da instalação em /usr é justamente para manter a consistência com o manual da Oracle.

Citação de: Sampayu online 09 de Maio de 2014, 02:22
...

Outra coisa que não gosto nesse manual de instalação da Oracle é que ele diz para criarmos a pasta do JRE com o nome completo desse JRE (exemplo: /usr/java/jre1.7.0_55/). Acho isso péssimo, porque quando o usuário for atualizar o Java para (por exemplo) a versão 1.7.0_56, ele vai ter que criar o caminho /usr/java/jre1.7.0_56/ e excluir a pasta jre1.7.0_55. É por isto que no meu tutorial eu crio a pasta /opt/java/jre/ (a palavra jre aparece isolada, sem o número da versão do JRE) e daí toda vez que eu atualizo o java os comandos do meu tutorial excluem os arquivos da pasta "jre" e colocam os arquivos novos dentro dessa mesma pasta.

...

Ainda outra vantagem é que você fica com (e somente com) a última (a mais recente) versão do Java instalada em seu sistema, dentro da pasta "jre" (ao invés de ficar com um JRE dentro da pasta jre1.7.0_55, outro JRE dentro da pasta jre1.7.0_56, e assim por diante). E isso é bom por questões de segurança: se você instalou a versão mais recente do Java, é melhor que exclua todas as demais (antigas), porque quando o Java é atualizado, muitas vezes é porque encontraram falhas de segurança na versão anterior, daí deixar essa versão anterior instalada pode abrir uma brecha para oportunistas mal-intencionados.

Prefiro manter o nome da pasta original com a versão do update. E manter sempre a versão anterior até que me certifique que os Bancos que acesso via Internet estejam funcionando com a nova versão (o que geralmente não acontece - e os Bancos param de funcionar).

Não sei se é possível aproveitar a brecha da versão anterior se esta não está configurada pelo comando update-alternatives. Se alguém puder esclarecer...

Citação de: Sampayu online 09 de Maio de 2014, 02:22
...
A principal vantagem desse segundo método é que você não vai precisar atualizar os links que você havia criado com o comando ls. Se você criou o link ls (para os seus navegadores Firefox, Opera, Chrome, Chromium etc.) apontando para a pasta /usr/java/jre1.7.0_55/,

Não é necessário criar um link para cada navegador, apenas para o Firefox. O Chrome / Chromium identifica automaticamente. O Opera não sei, não uso.

Meu how to é focado no funcionamento da Caixa e Itaú no Ubuntu / Xubuntu. Outros métodos de instalação geralmente funcionam, mas não para estes Bancos.

Renan Rischiotto · 09 de Maio de 2014, 16:55

Obrigado pela explicação Sampayu!

Sampayu · 09 de Maio de 2014, 17:35

Citação de: Renan Rischiotto online 09 de Maio de 2014, 16:55
Obrigado pela explicação Sampayu!

Por nada.

Sampayu · 09 de Maio de 2014, 18:24

Citação de: rodrigo.miguel online 09 de Maio de 2014, 09:09
Prefiro manter o nome da pasta original com a versão do update. E manter sempre a versão anterior até que me certifique que os Bancos que acesso via Internet estejam funcionando com a nova versão (o que geralmente não acontece - e os Bancos param de funcionar).

Não sei se é possível aproveitar a brecha da versão anterior se esta não está configurada pelo comando update-alternatives. Se alguém puder esclarecer...

Não é necessário criar um link para cada navegador, apenas para o Firefox. O Chrome / Chromium identifica automaticamente. O Opera não sei, não uso.

Meu how to é focado no funcionamento da Caixa e Itaú no Ubuntu / Xubuntu. Outros métodos de instalação geralmente funcionam, mas não para estes Bancos.

A escolha pela pasta "usr" ou "opt" é mesmo indiferente, na prática: tem mais a ver com a questão conceitual mesmo, da maneira como são estruturadas as pastas dos sistemas Linux (a finalidade por que cada uma daquelas duas pastas foi criada). Conceitualmente, faz sentido que o OpenJDK seja instalado (como de fato é instalado) dentro de /usr porque o OpenJDK faz parte dos pacotes da distribuição. Já o Oracle Java é um opcional, então conceitualmente deveria ser instalado em /opt (assim como o Google Chrome, por exemplo, que também é opcional e por isto é automaticamente instalado em /opt/google/chrome). Mas novamente: se você instalar em outro local e configurar corretamente, vai funcionar, sim, claro. Embora conceitualmente o ideal fosse instalar em /opt, na prática isso é indiferente e por isto se torna mais questão de gosto/preferência de cada um.

Em relação a manter a versão anterior, eu entendo que essa seja uma preferência pessoal sua e você tem todo o direito de fazer do jeito que quiser, claro. Respeito isso, Rodrigo. Cada um faz como bem entender. Mas, pelo menos eu, quando elaboro um tutorial, procuro elaborá-lo não da maneira que acho melhor para mim, mas sim da maneira que me parece ser a melhor para todo mundo que for usar o tutorial, ou seja, para o maior número possível de usuários: e principalmente para os que não entendam nada de Linux, de Java etc. Se você elabora o tutorial tendo em mente essa preocupação, a tendência será que os usuários mais "básicos" que seguirem o seu tutorial consigam manter o sistema deles estável e seguro, e os usuários mais avançados não terão problema em desviar um pouco do que o seu tutorial disser (e por exemplo mantiverem a versão antiga e a nova instaladas ao mesmo tempo), porque, afinal de contas, eles são usuários mais avançados e portanto fazer isso não será difícil para eles. Enfim: seu tutorial acaba ficando mais versátil e seguro para todos, se você adota uma postura mais conservadora e impessoal.

Por exemplo: se você é um usuário mais avançado e também é mais neurótico com a questão da segurança, estabilidade e compatibilidade (como eu também sou, diga-se de passagem...), pode ser bastante saudável fazer o que você faz, ou seja, manter a versão anterior instalada enquanto você testa o funcionamento da versão nova. No entanto / por outro lado, como a versão nova do Java sempre é uma versão estável, ela a priori não necessita de testes nem de segurança nem de estabilidade: de maneira geral, o pior que pode eventualmente acontecer é uma incompatibilidade temporária com algum website, o que no entanto não é muito comum porque o lançamento/release mais novo do Java sempre é compatível com os applets dos websites que tenham sido desenvolvidos para versões anteriores do Java.

Por conta disso, a própria Oracle recomenda excluir as versões anteriores do Java e com isto manter somente a versão mais recente/atual do Java instalada em seu sistema. Como os usuários mais "básicos" podem não saber lidar com diferentes versões instaladas no sistema ao mesmo tempo, e tendo em vista que a abordagem mais segura é a recomendada pela Oracle, eu tive o cuidado de elaborar o tutorial dizendo para manter o Java sempre atualizado (e o sistema sempre apenas com o Java mais novo).

Sobre a possibilidade de uma brecha de segurança ser explorada: como você mesmo disse, os navegadores Chrome e Chromium detectam automaticamente o plugin Java. Portanto, se porventura (e por exemplo) você tiver as versões 1.7.0_51 e 1.7.0_55 instaladas no seu sistema e por qualquer motivo você acessar um website que não funcione com o plugin da versão 1.7.0_55, é possível que seu navegador tente usar a versão 1.7.0_51.

Outro problema de manter duas versões locais e não usar o nome de pasta genérico "jre" é que toda vez que você instalar uma versão nova do Java você vai ter que refazer o link com o comando ls e também vai ter que executar novamente o comando update-alternatives.

Se toda vez que instalar uma nova versão do Java você se lembrar de atualizar novamente todos os links (comando ls) e também atualizar o novo local da JVM padrão (com o comando update-alternatives), e também lembrar-se de exportar novamente as variáveis de ambiente do Java, caso você tenha porventura criado alguma(s) na instalação anterior, o risco remanescente será mínimo, quase inexistente: alguém teria que invadir ou de algum outro modo obter indevidamente acesso privilegiado ao seu sistema e conseguir executar o JRE do seu Java antigo, para poder tentar explorar alguma brecha de segurança, tentar realizar algum tipo de ataque. Mas isso é (bem) mais difícil de acontecer.

Se você se lembrar de atualizar os links com comando ls mas se esquecer do update-alternatives, na prática o que vai acontecer é que seus navegadores vão usar o JRE mais novo, porém se você executar localmente algum arquivo JAR (programa escrito em Java) o JRE usado será o da versão anterior. Para eliminar essas possibilidades e riscos eu considero mais recomendável manter somente o Java mais novo instalado, e sempre na pasta de mesmo nome: jre. É uma sugestão que eu faço.

Como eu comento lá no meu tutorial, de fato o Chrome e o Chromium detectam automaticamente o plugin Java padrão do sistema. Mas isso não foi sempre assim (antes a detecção não era automática), e se qualquer problema ocorrer no navegador durante a execução (ou após a atualização) dele, essa funcionalidade pode se perder (ainda que temporariamente) e você então poderá ter que no fim das contas acabar criando o link com o ls. Já que não custa nada criar o link e ele nada faz enquanto a detecção automática do Chrome/Chromium estiver funcionando, eu recomendo usar o comando ls também para o Chrome e o Chromium (mas isso realmente vai ser trabalhoso se a pessoa instalar o JRE sempre numa pasta com o nome completo do JRE, como você faz).

Quanto ao Opera, ele funciona igual ao Firefox: só enxerga o plugin se você criar o link.

Não tenho conta no Itaú. Na Caixa eu já tive conta e funcionava ok com a instalação manual do Oracle Java proprietário (esse que tanto eu quanto você explicamos como instalar em nossos tutoriais), mas na Caixa eu não conseguia acessar com o OpenJDK + plugin IcedTea. Parece que no Itaú o OpenJDK + plugin IcedTea também dá problema devido ao fato de o applet de segurança do Itaú (um tal de "Guardião") ter um bytecode que o JIT da JVM do OpenJDK não consegue interpretar: o IcedTea-Web consegue transferir o código para o interpretador, mas o interpretador encontra erros e finaliza. Em outras palavras: pelo menos na época em que testei (há cerca de 18 meses), a dupla OpenJDK JRE + plugin IcedTea não funcionava nem na Caixa nem no Itaú, independentemente do navegador utilizado.

Achei bacana a gravação que você fez e postou no YouTube.

Qual foi o aplicativo que você usou no Linux, para poder capturar a tela? Ou você estava no OS X (ou no Windows) executando o Linux dentro de uma VirtualBox?

rodrigo.miguel · 09 de Maio de 2014, 18:44

Rapaz, tu gosta de escrever.

Vamos lá...

Citação de: Sampayu online 09 de Maio de 2014, 18:24
...
Em relação a manter a versão anterior, eu entendo que essa seja uma preferência pessoal sua e você tem todo o direito de fazer do jeito que quiser, claro. Respeito isso, Rodrigo. Cada um faz como bem entender. Mas, pelo menos eu, quando elaboro um tutorial, procuro elaborá-lo não da maneira que acho melhor para mim, mas sim da maneira que me parece ser a melhor para todo mundo que for usar o tutorial, ou seja, para o maior número possível de usuários: e principalmente para os que não entendam nada de Linux, de Java etc.
...

Eu faço assim pensando em mim e nos clientes do Itaú / Caixa.

Seu comentário me lembrou de um detalhe que devo acrescentar no meu how to. A desinstalação / remoção de versões anteriores.

A propósito, o link para o how to completo (texto e vídeo):

http://linuxuserlog.blogspot.com.br/2014/05/internet-banking-caixa-e-itau-no-ubuntu.html

Sobre como o vídeo é gravado, uso o Simple Screen Recorder, direto no Xubuntu (nada de Windows, VM, etc).

Renan Rischiotto · 09 de Maio de 2014, 21:40

Acrescentando...

SimpleScreenRecorder

Sampayu · 09 de Maio de 2014, 22:18

Citação de: rodrigo.miguel online 09 de Maio de 2014, 18:44
Rapaz, tu gosta de escrever.

Vamos lá...

Citação de: Sampayu online 09 de Maio de 2014, 18:24
...
Em relação a manter a versão anterior, eu entendo que essa seja uma preferência pessoal sua e você tem todo o direito de fazer do jeito que quiser, claro. Respeito isso, Rodrigo. Cada um faz como bem entender. Mas, pelo menos eu, quando elaboro um tutorial, procuro elaborá-lo não da maneira que acho melhor para mim, mas sim da maneira que me parece ser a melhor para todo mundo que for usar o tutorial, ou seja, para o maior número possível de usuários: e principalmente para os que não entendam nada de Linux, de Java etc.
...

Eu faço assim pensando em mim e nos clientes do Itaú / Caixa.

Seu comentário me lembrou de um detalhe que devo acrescentar no meu how to. A desinstalação / remoção de versões anteriores.

A propósito, o link para o how to completo (texto e vídeo):

http://linuxuserlog.blogspot.com.br/2014/05/internet-banking-caixa-e-itau-no-ubuntu.html

Sobre como o vídeo é gravado, uso o Simple Screen Recorder, direto no Xubuntu (nada de Windows, VM, etc).

Eu gosto mesmo de escrever. Tanto que meu tutorial é gigante.

Mas eu geralmente só escrevo muito quando quero explicar ou esclarecer algo. Este post, por exemplo, vai ficar bem menor, é ver pra crer.

Não é muito frequente eu gravar vídeos capturando minhas atividades na tela do PC, mas nas eventuais vezes em que faço isso eu uso uma linha de comando gigantesca do avconv. Ela é tão grande que não consegui memorizá-la, daí acabei criando um botão lançador no painel do XFCE: eu clico no botão, daí uma janela do terminal abre-se e então o avconv é executado e a captura de tela inicia. Eu então gravo o que estou querendo gravar e uso Ctrl C na janela do terminal para interromper a gravação. Um arquivo MKV é então gerado. Se eu quiser editar alguma coisa, abro o vídeo no OpenSHot, edito e salvo.

Depois de algum tempo precisei de outras opções de gravação (gravar com áudio, gravar sem áudio, gravar tela inteira, gravar só um pedaço), daí criei um botão para cada um dos comandos extensos e agrupei esses botões lançadores no mesmo menu do painel do XFCE.

A vantagem do avconv é a flexibilidade que ele lhe dá: você consegue personalizar bastante as opções de vídeo e de áudio. A desvantagem é que o avconv é mais complicado, porque não tem interface gráfica, é tudo linha de comando. Eu cheguei a usar o RecordMyDesktop, mas ele foi descontinuado. Também usei o Kazam, mas achei que tem muito poucas opções. Daí acabei voltando para o avconv...

No momento não estou num computador com Linux, mas depois vou testar esse SimpleScreenRecorder aí. Agradeço pela dica.

Sampayu · 09 de Maio de 2014, 22:20

Citação de: Renan Rischiotto online 09 de Maio de 2014, 21:40
Acrescentando...

SimpleScreenRecorder

Valeu, Renan, depois vou testar esse aplicativo.

Sampayu · 21 de Agosto de 2014, 18:48

Hoje resolvi adotar oficialmente o SimpleScreenRecorder como meu aplicativo padrão para vídeo-captura (ou seja: deixei de usar o avconv via linha de comandos do shell). O SSR é muito bom mesmo.

Essa minha mudança de postura ocorreu porque atualizei meu XUbuntu de 32 bits da versão 12.04 para a 14.04 e percebi que o comando que eu usava no avconv já não funcionava mais direito (continuava criando o arquivo de vídeo, porém com algumas variações de velocidade que eu não consegui corrigir, mesmo após haver testado literalmente dezenas de comandos, opções, codificadores etc.). Desisti.

O Kazam e o Record My Desktop sempre achei horríveis e não recomendo pra ninguém, rs.