Ainda há quem insista em configurar a variável de ambiente CLASSPATH?

16 de setembro de 2006 4 respostas

Luca 16 de setembro de 2006

Olá

Desde o Java 2 que não é mais necessário configurar a variável de ambiente CLASSPATH.

Aliás, acho até erro grave fazer isto porque a variável de ambiente que serve para um sistema pode atrapalhar outro. Quem aqui nunca teve a necessidade de suportar mais de uma versão de sistema (ou mesmo de Java) em sua própria máquina? Ou quem aqui trabalha com um único sistema?

Gente, por favor: [color=red]Não usem a variável CLASSPATH configurada como variável de ambiente[/color]

Habituem-se a configurar o classpath para cada sistema separadamente seja na sua IDE ou nos arquivos .bat, .sh ou ant que executam os sistemas. É tudo muito simples:

Para compilar, o javac precisa saber onde estão os jars. Para isto se usa a opção -cp ou -classpath com o comando javac ou se configura a IDE para encontrar as classes e libs
Para executar, também é preciso dizer ao java onde estão as classes e para isto se usa a opção -cp ou -classpath com o comando java

E sempre que lerem em algum lugar a palavra CLASSPATH, entendam como sendo a opção -cp (ou -classpath) ou como a configuração da IDE.

[]s
Luca

4 Respostas

Paulo_Silveira 17 de set. de 2006

ou ainda usem o ant…

CLASPATH gera zilhares de problemas a la “jar hell”… em especial que ele pode acabar pegando uma classe de um jar de uma versao e outra classe de outra, debugar isso é praticamente impossivel.

DIE $CLASSPATH, DIE DIE!

fmeyer 17 de set. de 2006

Poderia existir algum utilitario pra fazer distribuicoes de pacotes no caso bibliotecas como existe no linux com apt,

Coloca tudo em um third-part-dir e ja atualiza o classpath. Ia ser interessante chegar no console e digitar

$ jar-get hibernate3 --include_dependencies

outra coisa legal seria vc dar um determidado pacote que esteja faltando e ele te trazer os jars que podem suprir aquele pacote. ex

$ jar-list --package org.hibernate.transaction

seria muito interessante esse repositorio. pra gente nao ter que procurar jars na internet hehehe

o software é simples de fazer. o problema é botar na cabeca de todo mundo pra padronizar a distribuicao de libs.

alguns podem falar que o maven tb faz isso… mas não seria tao flexivel.

Sombriks 17 de set. de 2006

Pelo que eu entendi o problema é $CLASSPATH a nível global.

Usar de scripts para “dar boot” na aplicação não é nenhuma novidade, vide o tomcat.

Agora existir um $CLASSPATH global pode não ser o inferno que se alardea, no caso (no momento improvável) de pequenos programas em java serem distribuídos para algum determinado sistema seria interessante existir algo padrão para buscar os .jar; o problema é justamente que o que produzimos hoje é 70% bibliotecas e 30% ou menos “código próprio”. É por causa desse tipo de tendência que o $CLASSPATH se tornou um tipo de apêndice, que anda causando apendicite,

no sério, configurando um script podemos contornar isso. já que temos uma bolha ao redor da aplicação é melhor cuidar de cada detalhe antes de colocar a coisa toda em produção.

ainda acho uma pena, seria bom resolver todos os problemas do mundo com uma única variável de ambiente…

Mauricio_Linhares 17 de set. de 2006

fmeyer:
seria muito interessante esse repositorio. pra gente nao ter que procurar jars na internet hehehe

o software é simples de fazer. o problema é botar na cabeca de todo mundo pra padronizar a distribuicao de libs.

alguns podem falar que o maven tb faz isso… mas não seria tao flexivel.

E porque então não extender o Maven que já está com meio caminho andado pra fazer isso?

Criado 16 de setembro de 2006

Ultima resposta 17 de set. de 2006

Respostas 4

Participantes 5

4 Respostas

Topicos relacionados