Version imprimable
Bonjour,
Dans un Jlabel, j'aimerais afficher la valeur d'une variable d'environnement :
En exécutant le script, j'obtiens :Code:Title1.setText("JAVA_HOME = " + System.getenv("JAVA_HOME"));
Quelqu'un pourrait il m'éclairer sur le -D ... ?!Citation:
java.lang.Error: getenv no longer supported, use properties and -D instead: JAVA_HOME
Merci d'avance :D
javadoc ->
pour le -D man java ou help java devrait suffire. mais tu n'en a pas besoin je pense ...Citation:
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();
Bonjour,
le -D, là je ne sais pas. Peut-être appeler le programme avecEn tout cas, pour ce que tu cherches, c'estCitation:
java -D un_repertoire fichier_main
Ou quelque chose de proche.Code:System.getProperty("java.home");
D'après la javadoc, il vaut mieux passer par getProperty
Citation:
It is best to use system properties where possible
[EDIT]ahhh, doublement grillé :aie: :DCode:
2
C'est effectivement plus portable.Citation:
Envoyé par xavlours
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:
2
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 :
et sous Unix/Linux :Code:java -DJAVA_HOME=%JAVA_HOME% ...
Que tu récupères ensuite de la manière suivante :Code:java -DJAVA_HOME=$JAVA_HOME ...
Code: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++
Salut,
Heu le :
java -DJAVA_HOME=%JAVA_HOME%;
Je dois le mettre où dans mon prog ? Pas trop compris :oops:
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 !
Lorsque tu appelles ton programme (sur la ligne de commande, dans ton batch... cela dépend de la manière dont tu le lances...)Citation:
Envoyé par LTN
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...Citation:
Envoyé par LTN
Mais dans ce cas là pourquoi ne pas faire directement, comme cela a été dit :
a++Code:System.getProperty("java.home");
PS : pourquoi as-tu besoin de JAVA_HOME ???
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 :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:String javaHomeEnvironmentVariable = System.getProperty("java.home");
. Si tu utilises un environnement de développement dans lequel tu cliques pour exécuter le programme, il faut trifouiller la configuration.Code:java -Dfoo=bar MaClasseMain
Cela n'a rien à voir avec le lancement d'un programme externe avec Runtime.exec() !
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à :roll:
Etonnant :roll: ... moi j'appele surtout le fait de l'avoir deprecie precedement : une grosse bourde faite sans reflechir.Citation:
Envoyé par adiGuba
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.
Merci :)Citation:
Envoyé par bouye