Você está na página 1de 7

www.devmedia.com.

br
[versão para impressão]
Link original: https://www.devmedia.com.br/artigo-java-magazine-21-caminhos-para-o-classpath/10261

Artigo Java Magazine 21 - Caminhos para o Classpath


Artigo publicado pela Java Magazine edição 21.

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.

No Windows, as duas seqüências a seguir são equivalentes.

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.

Caminhos relativos no classpath


Em um ambiente de desenvolvimento, é usual incluir o diretório corrente (.) no classpath para que
possa compilar e executar classes Java no pacote default (ou seja, classes que não incluem a
declaração package). Também é comum que scripts de inicializaçao de aplicações (por exemplo,
o runide.sh/.bat do NetBeans ou o startup.sh/startup.bat do Tomcat) configurem o classpath fazendo
referência a caminhos relativos como ../lib/jakarta-commons-loggins.jar. Isso permite que a aplicação
seja instalada em qualquer diretório sem que o script precise ser modificado.
Fora essas duas situações não é recomendável utilizar caminhos relativos no classpath, poi isso fará
com que aplicação ora funcione, ora não, dependendo do diretório corrente do usuário.

Classpath e pacotes jar


Quando o classpath faz referência a um diretório, a JVM espera encontrar nele
arquivos.classdescompactados, em subdiretórios que refletiam a estrutura de pacotes definida nas
declarações package das classes. Caso as classes desejadas estejam compactas dentro de um jar¹ ou
zip, este arquivo deverá ser listado no classpath, qualquer que seja a forma utilizada para inicializá-lo.
A JVM trata arquivos jar/zip como um diretório virtual, abrindo o arquivo compactado de forma
transparente e extraindo classes e outros arquivos conforme a necessidade. Se forem utilizados vários
jars que estejam num mesmo diretório, eles devem ser listados um a um. Não adianta usar mascaras
como *.jar.

Configurações a variável de um ambiente CLASSPATH


Com o valor inicial do classpath é na maioria das vezes obtidos de uma variável de ambiente, sua
configuração depende de como o sistema operacional realiza esta tarefa. Vamos descrever as três
opções mais comuns: Windows 98/ME, Windows NT/2000/XP e Linux/Unix.

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.

Figura 1. Configuração de variáveis de ambiente no Windows XP

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):

CLASSPATH=$CLASSPATH:$HOME/classes java MinhaClasse

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.

Erros freqüentes com classpath


Uma quantidade considerável das cartas que recebemos de leitores, reportando dificuldades em
compilar e rodar os exemplos dos artigos da Java Magazine ou seus projetos, provém de problemas na
configuração do classpath. Relacionamos aqui os erros mais freqüentes, seus sintomas e como resolvê-
los. (Alguns são citados também no corpo do artigo, mas constam aqui para que o quadro fique
completo.)

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.

Incluir apenas a pasta que inclui um ou mais jars


Inserir no classpath um diretório que contém pacotes não tem efeito. Dentro e um diretório (e seus
subdiretórios) serão localizados automaticamente apenas arquivos.class.

Esquecer do diretório corrente


O diretório corrente (.) é necessário para que se possa compilar e executar classes no “pacote default”
(que não contenham a declaração package) de modo simples e direto na linha comando.
Caso as classes estejam em algum pacote (ou seja, contenham uma declaração package), deve ser
referenciado o caminho relativo de subdiretórios espelhando a hierarquia de pacotes definida.

Considerar maiúsculas e minúsculas como equivalentes em paths ou nomes


Mesmo que para o seu sistema operacional não faça diferença, o uso de maiúsculas e minúsculas
poderá ser importante para a JVM no momento de comparar nomes de diretórios, arquivos, classes etc.
Outra recomendação: use “CLASSPATH”, em vez de “classpath” ou “Classpath”.

Errar na sintaxe da declaração de variável


Verifique a sintaxe do comando set ou export, de acordo com o seu sistema, e lembre-se que cada SO
utiliza separadores diferentes para listas de diretórios e caminhos no sistema de arquivos. O Windows
utiliza “,” e “\” e o Linux “:” e “/”, por exemplo.
Usa paths relativos
Paths relativos poderão funcionar num momento e deixa de funcionar em outro, de acordo com o
diretório corrente do usuário ou script que inicia a aplicação. Use com cautela.

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.

Você também pode gostar