Discussion :

[Invité]

Bonjour,

Dans un Jlabel, j'aimerais afficher la valeur d'une variable d'environnement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Title1.setText("JAVA_HOME = " + System.getenv("JAVA_HOME"));

En exécutant le script, j'obtiens :

java.lang.Error: getenv no longer supported, use properties and -D instead: JAVA_HOME

Quelqu'un pourrait il m'éclairer sur le -D ... ?!

Merci d'avance

[in]

javadoc ->

Deprecated. The preferred way to extract system-dependent information is the system properties of the java.lang.System.getProperty methods and the corresponding getTypeName methods of the Boolean, Integer, and Long primitive types. For example:

String classPath = System.getProperty("java.class.path",".");


if (Boolean.getBoolean("myapp.exper.mode"))
enableExpertCommands();

pour le -D man java ou help java devrait suffire. mais tu n'en a pas besoin je pense ...

[xavlours]

Bonjour,

le -D, là je ne sais pas. Peut-être appeler le programme avec

java -D un_repertoire fichier_main

En tout cas, pour ce que tu cherches, c'est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.getProperty("java.home");

Ou quelque chose de proche.

[professeur shadoko]

En tout cas, pour ce que tu cherches, c'est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.getProperty("java.home");

Ou quelque chose de proche.

C'est effectivement plus portable.
ceci dit getEnv est revenu en odeur de sainteté avec J2SE5 (mais bien lire la doc!)
pour le -D c'est une mise en place de variable nommée dans l'environnement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
java -Dcouleur=rose_bonbon monpackage.MaClasse

[adiGuba]

Salut,


Pour information : getenv() avait été déprécié car il posait des problèmes de portabilité, puisque les système ne gère pas de la même manière les variable d'environnement (notamment concernant la prise en compte de la casse).

En remplacement il était conseillé d'utiliser des variables systèmes Java que l'on passe avec l'option -D, par exemple si on veut passer la valeur de JAVA_HOME, on ferait sous Windows :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

java -DJAVA_HOME=%JAVA_HOME% ...

et sous Unix/Linux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

java -DJAVA_HOME=$JAVA_HOME ...

Que tu récupères ensuite de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String javaHome = System.getProperty("JAVA_HOME");

Il est à noter toutefois que la méthode getenv() a été réintroduite dans Java 5.0, car cette solution alternative est souvent plus "complexe" à mettre en oeuvre comparer aux "problèmes de portabilité" de getenv()...

a++

[Invité]

Salut,

Heu le :

java -DJAVA_HOME=%JAVA_HOME%;

Je dois le mettre où dans mon prog ? Pas trop compris

J'ai testé ceci :
Runtime.getRuntime().exec("cmd.exe /c java -DJAVA_HOME=%JAVA_HOME%");

Et en faisant getProperty("JAVA_HOME") j'obtiens null.

Merci !

[adiGuba]

Je dois le mettre où dans mon prog ? Pas trop compris

Lorsque tu appelles ton programme (sur la ligne de commande, dans ton batch... cela dépend de la manière dont tu le lances...)

Runtime.getRuntime().exec("cmd.exe /c java -DJAVA_HOME=%JAVA_HOME%");

Normal %JAVA_HOME% ne marche pas en Java : c'est une syntaxe du shell du système. Tu dois faire ceci avant l'appel de ce programme...

Mais dans ce cas là pourquoi ne pas faire directement, comme cela a été dit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.getProperty("java.home");

a++

PS : pourquoi as-tu besoin de JAVA_HOME ???

[Invité]

En fait il n'y a pas que JAVA_HOME, j'ai besoin de pas mal de variables d'environnement système comme PATH, SQLPATH etc... dans mon programme

Avant j'utilisais un fichier ANT + properties et il suffisait de faire :
<property environment="env"/> et d'y accéder avec env.JAVA_HOME par exemple.

Mais là je suis obligée de passer par JAVA.

Je ne trouve pas le moyen d'accéder à mes variables système sans passer par ant.

Voilà

[xavlours]

Oui, on a été un peu confus.
Pour avoir la valeur de la variable d'environnement JAVA_HOME (qui contient le nom du répertoire dans lequel est installé le JDK), il suffit d'appeler dans ton programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String javaHomeEnvironmentVariable = System.getProperty("java.home");

Il est également possible de passer des propriétés supplémentaires au programme à son lancement. Si tu veux par exemple passer une variable qui s'appelle foo et dont la valeur est bar, il faut exécuter le programme ainsi (si tu le lances à partir d'une console) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

java -Dfoo=bar MaClasseMain

. Si tu utilises un environnement de développement dans lequel tu cliques pour exécuter le programme, il faut trifouiller la configuration.

Cela n'a rien à voir avec le lancement d'un programme externe avec Runtime.exec() !

[bouye]

Salut,
Il est à noter toutefois que la méthode getenv() a été réintroduite dans Java 5.0, car cette solution alternative est souvent plus "complexe" à mettre en oeuvre comparer aux "problèmes de portabilité" de getenv()...

Etonnant ... moi j'appele surtout le fait de l'avoir deprecie precedement : une grosse bourde faite sans reflechir.

Dans le meme genre de revirrement apres couts on a eut droit a des trucs comme JFrame.add().......................... ou comment rendre la vie des programmeurs plus compliquee sous le pretexte d'etre juste 100% correct dans l'usage d'une API (note : trop de rigueur tue la rigueur).

Histoire de raler un peu plus, certaines methodes deprecated l'ont ete car la maniere dont elle accedaient au systeme sous-jacent n'etait pas correct blablabla : et ben dans ce cas, dans les maj ulterieures il suffisait de rectifier cette maniere (!), pas de deprecier la methode !

LTN, je ne peux que te conseiller de passer sous Java 5 (ou de rester avec une version dans laquelle cette methode n'est pas depreciee). Sinon... depuis ton programme tu executes une commande systeme qui liste toutes les proprietes (ex: set) et tu parses manuellement le contenus du flux associe a la sortie standard de cette commande pour trouver toutes les variables. Evidement tu perds en portabilite.

[Invité]

LTN, je ne peux que te conseiller de passer sous Java 5 (ou de rester avec une version dans laquelle cette methode n'est pas depreciee). Sinon... depuis ton programme tu executes une commande systeme qui liste toutes les proprietes (ex: set) et tu parses manuellement le contenus du flux associe a la sortie standard de cette commande pour trouver toutes les variables.

Merci

[afrikha]

D'après la javadoc, il vaut mieux passer par getProperty

It is best to use system properties where possible

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
title1.setText(System.getProperty("java.home");

[EDIT]ahhh, doublement grillé