Após atualizar o SDK de 1.4.1 p/1.4.2 o mecanismo de extensão parou de funcionar e com isso descobri q na execução (ao menos no Windows), é usado o JRE do sistema (geralmente em C:Arquivos de ProgramasJavasoftj2re1.4.2_03) e na compilação é usado o JRE residente no %JAVA_HOME% (pasta designada pelo usuário na instalação).
Desagradáveis soluções:
copiar os JAR’s de extensão para ambos subdiretórios jrelibext
usar %classpath% que já é imensa atualmente
modificar a configuração (pouco aconselhável) via registradores em:
HKEY_LOCAL_MACHINESOFTWAREJavaSoftJava Runtime Environment1.4…
Optei pela 3a. mas estou receioso. Alguma sugestão ou comentário? Isto tbm ocorre em outras plataformas/OS’s ?
Dificilmente existe a necessidade de colocar coisas no classpath, muito menos no jrelibext, por sinal, no segundo só é interessante usar com providers, como para JCE, JCA, sockets, nio, jax, etc, o resto colocar ali é pedir para ter dor de cabeça.
Nas máquinas em que eu mantenho um configuração sadia do java, umas 4-5 hoje em dia, não uso $CLASSPATH nem o jrelibext para nada. E tem uma máquina que roda toneladas de programas java diferentes.
Não sei se entendi bem sua mensagem porque há algumas informações truncadas como por exemplo usar JRE para compilar. Assim vou falar de forma genérica.
Uma das versões do J2SDK1.4.1 tinha um bug (em algumas versões do Windows) no Plugin que mesmo depois de desinstalado continuava aparecendo no painel de controle. Neste caso os incomodados limpavam o Registry.
Geralmente antes de instalar um novo J2SDK é de bom alvitre (mas não obrigatório) desinstalar o anterior. Infelizmente eu as vezes preciso usar diferentes J2SDK e preciso de arquivos .bat para configurar as variáveis de ambiente para cada um deles na hora de executar a apicação que precisa deles.
Não sei mais porque tanta gente aqui do GUJ usa a variável de ambiente CLASSPATH permanente. Antigamente, mas muito antigamente, a gente usava isto. Hoje não sei mais para que serve. Acho que desde o início de 2001 não tenho mais CLASSPATH nas minhas variáveis de ambiente permanente. Sugestão: use uma IDE tipo Eclipse e use o ant.
A instalação do J2SDK copia arquivos para 2 diretórios:
C:\Arquivos de programas\Java\j2re1.4.2_03
(Com Java 1.3.1 era no C:\Arquivos de programas\JavaSoft\JRE\1.3.1_09)
e
E:\j2sdk1.4.2_03 (Meu JAVA_HOME)
Não há nenhum problema nisto. O que é preciso é acertar o PATH para por exemplo PATH=%JAVA_HOME%\bin;%PATH%
Valeu! Bons argumentos, mas de fato existe muita jar q merece ser extensão permanente, por exemplo; BeanShell, JRegex, MySQL connector, diversas L&F, etc…
O mecanismo de extensão foi concebido p/isso além de reduzir o uso de classpath (tanto como variável de sistema como opção de execução/compilação), mas nesta última versão d produção do SDK não funciona como nas anteriores q sempre foram desinstaladas de forma apropriada desde a versão 1.2.
A idéia é simples: “o jar é acima da média e será muito usado? vai pra extensão”, ou seja; armazena-se o jar na pasta de extensão únicamente, evitando-se aborrecimentos com cp/classpath/etc, que conforme a ocasião precisam ser usados tbm.
Não faz uso de $CLASSPATH? realmente é opcional, mas seu uso não implica em má qualificação do ambiente, é apenas uma comodidade.
Usamos muito o Ant que não se recente de “tasks” prolixas, usar ‘cp’ ou mecanismo de extensão é irrelevante no seu desempenho, mas na hr de criar scripts é uma brisa…
Éra conhecido q existem dois JRE’s nas instalações d J2SDK e o JAVA_HOME como parte do path em nada contribui p/solucionar o problema, na compilação/execução apenas oq está configurado nos registros do Windows é considerado.
O que interessa de fato, é que foi reconfigurado via alteração de registros, não se sabendo a principio se há conseqüências ruins.
Colocar jars adicionais no diretório ext é valido e comumente faço isto em deployment remoto através de applets assinadas. Execução com jre encontra direitinho.
Você deve ter tido algum problema na instalação do Java. Eu trabalhava em uma aplicação que com muita freqüência exigia instalação do Java. Algumas vezes encontrei problemas. Uma vez em um notebook incrementado de um diretor o JRE não funcionou de jeito algum.
Já passei por casos em que precisei eliminar na mão todas as referências ao Java no registry e depois reinstalar.
Não acredito que versão mais nova não usa o jre\lib\ext pois aqui no meu no mínimo sempre tem o javax.comm
De http://java.sun.com/j2se/1.4.2/install-windows.html[list]
Private vs. public J2RE - Installing the Java 2 SDK installs a private Java 2 Runtime Environment and optionally a public copy. The private J2RE is required to run the tools included with the Java 2 SDK. It has no registry settings and is contained entirely in a jre directory (typically at C:\Program Files\j2sdk1.4.2\jre) whose location is known only to the SDK. On the other hand, the public J2RE can be used by other Java applications, is contained outside the SDK (typically at C:\Program Files\Java\j2re1.4.2), is registered with the Windows registry (at HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft), can be removed using Add/Remove Programs, might or might not be registered with browsers, and might or might not have java.exe copied to the Windows system directory (making it the default system Java platform or not).
[/list]
Um meio radical que já precisei fazer é alterar o registry HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft na mão.
Confirmado, a versão 1.4.2_03 usa sim.
Numa instalação “redonda” hipotéticamente, os jars residentes em apenas um dos JRE’s seriam usados tanto p/executar como p/compilar mas aqui apenas éra possível esta última.
Lamentavelmente não há info detalhada na documentação e de fato isso pode ser uma inovação, dado que no forum da Sun existem mais threads queixosas a respeito. Não reputaria como um bug, mas deveriam alertar sobre o fato.
Obrigado pela atenção, valeu!