Escolar Documentos
Profissional Documentos
Cultura Documentos
br
[versão para impressão]
Link original: https://www.devmedia.com.br/artigo-java-magazine-21-caminhos-para-o-classpath/10261
Esse artigo faz parte da revista Java Magazine edição 21. Clique aqui para ler
todos os artigos desta edição
Atenção: por essa edição ser muito antiga não há arquivo PDF para download.Os artigos dessa
edição estão disponíveis somente através do formato HTML.
Primeiros Passos
Caminhos para o Classpath
Saiba porque ocorrem problemas com classpath e como resolvê-la
Uma das maiores dificuldade do iniciante em Java é a configuração do classpath, que é necessária para
localizar APIs, bibliotecas e outras componentes como drivers JDBC. Praticamente toda aplicação Java
de sistemas Web a ferramentas de geração de relatórios Toolkits gráficos alternativos, e mesmo
aplicação distribuída com EJB, exige a configuração do classpath.
O que é o classpath?
Pode se disser que “classpath” é um nome curto para a propriedade de sistema java.class.path, cujo
valor (um String) pode ser obtido com System.getProperty(“java.class.path”).
A finalidade do classpath é indicar para a máquina virtual Java onde localizar os byte-codes das classes
instaladas no computador.
Sua sintaxe consiste de uma lista de diretórios ou pacotes jar/zip separados por um caractere que varia
de acordo com o sistema operacional. Sistemas Windows utilizam o ponto-e-vírgula enquanto sistemas
Unix como o Linux usa dois-pontos. Deve ser considerada também a variação do separador de
diretórios nas diferentes plataformas.
Inicializando o classpath
A JVM pode iniciar a propriedade java.class.path de três maneiras:
1. A partir da variável de ambiente CLASSPATH do sistema operacional.
2. A partir da opção de linha de comando –cp ou –classpath do comando java.
3. A partir do atributo Class-path no arquivo MANIFEST.MF de um pacote jar.
A forma mais comum é utilizar o valor da variável de ambiente Classpath. No Linux as três
seqüências de comandos a seguir são equivalentes, pois inicializam a variável e depois iniciam uma
JVM:
1. >java-cp.:/usr/java/classes Exibe.java
2. >export CLASSPATH=.:usr/java/xpto.jar/usr/java/classes
>java Exibe.java.
3. >CLASSPATH=.:/usr/java/xpto.jar:/java/classes
>java.Exibe.java.
1. >java-cp.,:c:\java\xpto.jar;c:\java\classes Exibe.java
2. >set CLASSPATH=.,:c:\java\xpto.jar;c:\java\classes
>java Exibe.java
Foram mostrados apenas dois comandos para o Windows porque não há sintaxe equivalente para o
segundo comando Linux.
Modificando o classpath
Uma aplicação pode modificar o seu próprio classpath (ou melhor, o classpath da JVM em que está
rodando, possivelmente afetando outras aplicações em execução dentro da mesma JVM). Isso desde
que a política de segurança em efeito o permitia. O default é permitir essa configuração, mas servidores
de aplicação e containers web geralmente mudam a política para impedir a alteração direta.
O código a seguir é um exemplo de como modificar o classpath via programação:
System.setproperty(“java.class.path”,
“.:/usr/java/xpto.jar:/usr/java/classes”)
Algumas aplicações podem inicializar seu próprio classpath incluindo todos os pacotes em um
determinado diretório (o que é bastante comum em servidores J2EE), ou aceitar como parâmetro o
caminho para um jar ou zip contendo, por exemplo, um driver JDBC.
Pacotes executáveis
Um pacote jar é executável quando um “manifesto” (arquivo texto MANIFEST/MANIFEST.MF)que inclui o
atribuo Main-Class. A existência desse arquivo permite que o jar seja executado diretamente pela JVM
com um comando simples por exemplo java-jar aplicações.jar. Este é o caso da ferramenta CASE
ArgoUML (argouml.org), por exemplo, e muitas outras aplicações Java distribuídas como jars.
Pacotes executáveis sempre inicializaram seu classpath a partir do atributo Class-Path de seu próprio
arquivo de manifesto, ignorando tanto a variável de ambiente CLASSPATH quanto as opções de linha de
comando -classpath ou –cp. Em outros tipos de pacotes jar (não executáveis), o valor do atributo é
adicionado ao valor da variável de ambiente ou a opção de linha de comando.
Windows 98/ME
No Windows 98/ME, variáveis de ambiente têm seus valores configurados usando o comando SET
nome=valor. Não pode haver espaços antes nem depois dos sinais de igual e nome de seguir as
restrições usuais para nomes de variáveis Java, ou seja, não incluir acentos, espaços, operadores
aritméticos etc. Apenas os “sublinhados” (_) e o hífen são seguros. Maiúscula e minúscula são
diferenciadas no nome variável (mesmo que seu sistema ignore essa diferença).
Caso o valor contenha espaços, ele deve ser fornecido entre aspas. Por exemplo:
Set CLASSPATH=
“.;c:\minhas classes;c:\commons\commons-http-client.jar”
Um problema muito comum no Windows ocorre quando são utilizados scripts .bat ou executáveis
nativos para iniciar aplicativos Java. Muitos deles montam o valor do classpath a partir de valores de
outras variáveis de ambiente e argumentos de linha de comando e não lidam corretamente com o
espaço em branco nos nomes de pastas. Isso faz com que algumas classes não consigam ser localizada
pela JVM. Por isso é recomendável não utilizar espaços, acentos e outros símbolos nos nomes de
pacotes e diretórios a serem incluso no classpath, incluindo localizações padrões do sistema, como
“Arquivos de Programas” e “Documents and Settings”
Modoficaçoes aditivas ao classpath, ou seja, que apenas acrescentam novas pastas ou pacotes sem
sobescrever o valor anterior da variável, podem ser feitas referenciando-se o valor anterior da variável
com a sintaxe %nome%, como no exemplo a seguir:
setCLASSPATH=%CLASSPATH%;c:\minhas_classes
O comando set tem efeito apenas sobre programas executados a partir do mesmo prompt de
comandos; não afeta programas iniciados por meio de atalhos na área de trabalho (ou pelo
menu iniciar). Também não afeta outros prompts de comandos que sejam abertos posteriormente.
Modificações permanentes devem ser feitas acrescentando-se os comandos set no arquivo
c:/autoexec.bat.
Windows NT/2000/XP
Versões mais recentes do Windows utilizam o mesmo comando set, com sintaxe e restrições idênticas
às de versões anteriores.
Entretanto, os sistemas operacionais derivados do NT não utilizam mais o arquivo c:\autoexec.bat. As
variáveis de ambiente são baseadas em valores armazenados no registro do sistema e configurados
pelo botão Variáveis de Ambiente, dentro da aba “Avançado” das propriedades do “Meu Computador”;
ou então seguindo o mesmo caminho a partir do ícone “Sistema” do Painel de Controle Veja a Figura
1.
São definidos dois grupos de variáveis: variáveis de sistema, cujos valores valem para todos os
usuários operando o computador, variáveis de usuário, que afetam apenas o ambiente do usuário
corrente. O primeiro grupo pode ser configurado apenas por administradores locais, mas valores
definidos no segundo sobrepõem os do primeiro. Dessa forma, qualquer usuário tem plena capacidade
de configurar o seu próprio ambiente, inclusive redefinindo configurações feitas pelo administrador.
Modificações na configuração de variáveis de ambiente realizada na tela “Propriedades de sistema” não
exigem reinicialização ao contrário do que acontece no Windows 98/ME. Note ainda que programas que
já estejam em execução não são afetadas por alterações no classpath. Após uma mudança será
necessário fechá-los e abrir novas instância de prompts de comando, editores de texto etc.
Linux e Unix
Sistemas Unix e seus derivados (incluindo o Linux) utilizam o comando nome=valor para definir
variáveis no shell corrente. Só que estas variáveis não são parte do ambiente, a não ser que
sejam exportados. Isso é feito com o comando export, caso o seu shell seja compatível com o Bourne
Shell (/bin/sh), por exemplo o bash do Linux. E possível combinar a inicialização e a exportação de uma
variável em um único, como em :
exportClasspath=
.:/home/lozano/classes:/usr/local/commons/commons-http-client.jar
Caso seja necessário utilizar o valor de outras variáveis ou fazer modificações aditivas sobre a variável,
utilize “$”:
exportCLASSPATH=$CLASSPATH:$HOME/classes
Uma alternativa à extorsão é definir a variável na linha de comando que inicia o aplicativo. Isso define a
variável apenas para o aplicativo (e seus subprocessos):
Variáveis de ambiente são herdados apenas por processo filhos do shell onde foram definidas. Portanto
o comando export não afeta aplicações iniciadas por lançadores (ícones da área de trabalho), que
qualquer que seja o desktop utilizado, e as mudanças são perdidas quando o shell é encerrado.
Modificações permanente devem ser feitas diretamente no arquivo /etc/profile ou em um script
qualquer sob diretório /etc/profile.d.
Estas mudanças afetam todos os usuários que se logarem depois de realizada as modificações. Podem
também ser utilizados os arquivos .profile ou .bash_profile no diretório “home” do usuário. Neste caso
as modificações afetam apenas ao próprio usuário, a partir do seu próximo logon.
Conclusão
Vimos aqui como configurar o classpath, tanto a partir do código Java, quanto utilizando os recursos do
sistema operacional, respondendo a perguntas freqüentes de muitos leitores da Java Magazine e
desenvolvedores Java do modo geral.
É fundamental para o desenvolvedor Java saber configurara o classpath do seu sistema, ou classpath
para execução de uma aplicação. Sem este conhecimento não é possível utilizar APIs externas ao J2SE,
como as de servlets EJBs, nem frameworks como o Hibernate ou drivers JDBC, para citar apenas alguns
componentes.
Usar máscaras
Não funciona usar *.jar para incluir no classpath todos os pacotes jar em um diretório. Os arquivos
devem ser incluídos um a um.
Usar a variável de ambiente para configurar uma aplicação que roda dentro de um servidor
ou IDE
Na maioria dos casos, os script de inicialização de servidores como o Tomcat e JBoss configuram do
zero seus próprios classpaths, para evitar conflitos com outras versões de bibliotecas instaladas no
sistema.
Mesmo que o servidor de aplicações em si utilize o classpath do sistema operacional, ele não irá passar
esta configuração para as aplicações hospedadas. Isso dá ao desenvolvedor controle sobre as versões
das bibliotecas utilizadas por suas aplicações. IDEs costumam fazer a mesma coisa,mas para cada
projeto.