Como forçar o sistema/applet a usar uma versão específica do Java

PELiGRO · 12 de setembro de 2012

Alguns programas da RFB sofrem incompatibilidades com o Java 7, só rodam com o Java 6.

Tendo os dois instalados no computador, existe alguma forma de fazer que o Windows use uma versão específica do java ou então apontar para o applet .jar os binários C:\Arquivos de programas\Java\jre6\bin?

Desinstalar o Java 7 para que o sistema use apenas o Java 6 instalado não é uma opção.

Simon Viegas · 12 de setembro de 2012

Alguns programas da RFB sofrem incompatibilidades com o Java 7, só rodam com o Java 6.
Tendo os dois instalados no computador, existe alguma forma de fazer que o Windows use uma versão específica do java ou então apontar para o applet .jar os binários C:\Arquivos de programas\Java\jre6\bin?

Desinstalar o Java 7 para que o sistema use apenas o Java 6 instalado não é uma opção.

Uma forma seria mudando o endereço do ClassPath nas variáveis de ambiente do Windows antes de executar o programa do RFB. Ao terminar, volta para para o 7.

Se você tiver usando o Java 7 em uma IDE, como JCreator, Eclipse, NetBens, você pode setar para usar esse java 7 dentro do programa, e deixar o Java 6 para o ambiente Windows, já que o RFB usará ele. (supondo que no RFB não dá para editar).

No aguardo

Abraços

PELiGRO · 13 de setembro de 2012

O programa é o ITR 2008, 2009 e 2010, não testei com a versão 2011 nem 2012, e pode ser que outros programas da Receita Federal sofram do mesmo problema. Algumas funções do programa não funcionam e as vezes o programa simplesmente trava.

Colocar o ClassPath nas variáveis do sistema não vai dizer ao sistema operacional onde buscar o java, o java -version continua a retornar a versão atual:

java version "1.7.0_07"

Java SE Runtime Environment (build 1.7.0_07-b10)

Java HotSpot Client VM (build 23.3-b01, mixed mode, sharing)

Eu resolvi de outra maneira.

set path=C:\Arquivos de programas\Java\jre6\bin;%path%

O java -version me retorna:

java version "1.6.0_35"

Java SE Runtime Environment (build 1.6.0_35-b10)

Java HotSpot Client VM (build 20.10-b01, mixed mode, sharing)

Então executo o applet:

C:\Arquivos de programas\Programas RFB\ITR2008>javaw -jar pgditr.jar

E o programa funciona como deveria.

O problema é que o sistema continua a usar o Java 6 durante a seção, mesmo que eu feche o programa, isso não é interessante por questões de segurança e compatibilidade com outros aplicativos que dependem do Java 7, e dizer a pessoa para abrir o cmd e digitar tudo isso para ir e voltar as versões do java também não é uma opção, quem opera a máquina mal sabe para que serve o java.

Para resolver isso eu criei esse bat:

@echo off
set path=C:\Arquivos de programas\Java\jre6\bin;%path%
java -version
cd C:\Arquivos de programas\Programas RFB\ITR2008\
javaw -jar pgditr.jar
set path=C:\Arquivos de programas\Java\jre7\bin;%path%
java -version
pause
exit

A pessoa abre o bat, ele muda para o Java 6, a pessoa pode usar o programa normalmente, quando ele fecha, muda de volta para o Java 7.

Simon Viegas · 13 de setembro de 2012

Colocar o ClassPath nas variáveis do sistema não vai dizer ao sistema operacional onde buscar o java, o java -version continua a retornar a versão atual:
java version "1.7.0_07"

Java SE Runtime Environment (build 1.7.0_07-b10)

Java HotSpot Client VM (build 23.3-b01, mixed mode, sharing)

Certo... dei uma pesquisada e entendi melhor a diferença entre as variáveis, veja:

JAVA_HOME: JAVA_HOME, como o nome já diz é a CASA_JAVA (tradução estranha!). É nele que se indica onde que foi instalado o JDK (casa == morada == local em que “MORA” o JDK). Por exemplo: o meu JAVA_HOME é C:\Program Files\Java\jdk1.6.0_17 . Muitas vezes as pessoas pensam que o JAVA_HOME é onde está instalado o JRE. NÃOOOO É ISSO! Quando se pensa JAVA_HOME,CLASSPATH e PATH se usa o JDK e não o JRE. Esqueça o JRE!!!!!
CLASSPATH: Ele significa caminho de classe. É onde se indica os .jars que estão localizados na pasta lib e jre/lib do JDK.

PATH: Ele significa caminho. Nele se indica onde está os executáveis (aquela pasta bin que comentei antes) do JDK. Em meu caso é C:\Program Files\Java\jdk1.6.0_17\bin.

Fonte: http://devjava.wordpress.com/

Ou seja, realmente o Java.exe fica direcionado no Path, por isso que a versão muda ao testar. Mas será que não será preciso também as .jar e afins?

Eu resolvi de outra maneira.

set path=C:\Arquivos de programas\Java\jre6\bin;%path%

O java -version me retorna:

java version "1.6.0_35"

Java SE Runtime Environment (build 1.6.0_35-b10)

Java HotSpot Client VM (build 20.10-b01, mixed mode, sharing)

Tem um probleminha ai... percebo que você está concatenando o novo valor com o valor antigo, correto?

Daí a cada execução o texto vai aumentando, pois vai estar o "JR6"+"valor antigo", ao executar de novo vai ficar "JR7"+("JR6"+"valor antigo") e assim sucessivamente. Percebes?

PS: Para ver o que tem no Path basta executar Path.

Para resolver isso eu criei esse bat:
@echo off
set path=C:\Arquivos de programas\Java\jre6\bin;%path%
java -version
cd C:\Arquivos de programas\Programas RFB\ITR2008\
javaw -jar pgditr.jar
set path=C:\Arquivos de programas\Java\jre7\bin;%path%
java -version
pause
exit
A pessoa abre o bat, ele muda para o Java 6, a pessoa pode usar o programa normalmente, quando ele fecha, muda de volta para o Java 7.

Essa bat está com o mesmo "problema". Vai ficar concatenando... vai chegar um momento que vai "estourar a capacidade".

Uma solução seria dar um set com os caminhos completos para ambos os casos. (sem o %path%)

Ou

Criar uma variável para copiar o %path%, daí dar um set somando a variável.

Obs.: Você vai precisar dar uma limpada no seu path, já que vai ter um monte de caminhos repetidos!

Obs2:. Realmente não sei se será preciso mudar também o ClassPath (veja que a versão deu igual, pois o java.exe está igual no path). Se sim, eu ainda não sei como faz para mudar via linha de comando. (sei pelo "Windows" mesmo, lá em "Variáveis de Ambiente" que fica em "Propriedade do Sistema")

No aguardo

Abraços

PELiGRO · 14 de setembro de 2012

O path não concatena com o set path, ele só dura o tempo que janela está aberta na memória, portanto nem precisa voltar o path para o Java 7 com o set path=C:\Arquivos de programas\Java\jre7\bin;%path%, ao fechar a janela ele retorna os valores originais do path, o exit no final do bat é o suficiente.

Também notei que todas as versões do ITR usam o mesmo nome no .jar para o aplicativo principal, então achei melhor tirar o caminho C:\... e somente jogar uma cópia do bat dentro da pasta de cada versão e mudar o atalho na área de trabalho para executar o bat dentro da pasta da sua versão correspondente, também mudei o caminho do java para %programfiles%, vai saber se a pessoa tem mesmo um drive C:... fica assim:

@echo off
set path=%programfiles%\Java\jre6\bin;%path%
java -version
javaw -jar pgditr.jar
exit

Problema resolvido, agora todas as versões do ITR da Receita funcionam corretamente com o mesmo set path e o bat.

Creio que a Receita Federal nem está atentando para este problema, o Java 7 quebra a funcionalidade de algumas versões antigas dos programas da RFB que usam bibliotecas do Java 5 e 6.

Simon Viegas · 14 de setembro de 2012

O path não concatena com o set path, ele só dura o tempo que janela está aberta na memória, portanto nem precisa voltar o path para o Java 7 com o set path=C:\Arquivos de programas\Java\jre7\bin;%path%, ao fechar a janela ele retorna os valores originais do path, o exit no final do bat é o suficiente.
Também notei que todas as versões do ITR usam o mesmo nome no .jar para o aplicativo principal, então achei melhor tirar o caminho C:\... e somente jogar uma cópia do bat dentro da pasta de cada versão e mudar o atalho na área de trabalho para executar o bat dentro da pasta da sua versão correspondente, também mudei o caminho do java para %programfiles%, vai saber se a pessoa tem mesmo um drive C:... fica assim:
@echo off
set path=%programfiles%\Java\jre6\bin;%path%
java -version
javaw -jar pgditr.jar
exit
Problema resolvido, agora todas as versões do ITR da Receita funcionam corretamente com o mesmo set path e o bat.

Creio que a Receita Federal nem está atentando para este problema, o Java 7 quebra a funcionalidade de algumas versões antigas dos programas da RFB que usam bibliotecas do Java 5 e 6.

Como só dura enquanto a janela está aberta, então fica tudo beleza!!!

PS: Em relação ao comando para "voltar o path para o Java 7", está sim concatenando o path temporário, mas o que importa é que o comando funcionaria e não teria problema no contexto, já que a variável volta ao normal ao final. (se não voltasse para o normal como você observou, ia dá problema. Como volta... é só alegria)

Abraços