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

Programação Java
#1

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:

  1. 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

  2. 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

#2

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!

#3

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.

#4

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, :smiley: 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, :smiley:

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…

#5

[quote=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.[/quote]

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

#6