J'ai vérifié que la redirection de la sortie fonctionne avec javaw
:
javaw -cp ... mypath.MyClass ... arguments 1>log.txt 2>err.txt
Cela signifie que si l'application Java imprime quelque chose via System.out ou System.err, cela est écrit dans ces fichiers, comme c'est le cas avec l'utilisation de java (sans w
). Surtout au début java
le JRE peut écrire des erreurs de démarrage (classe non trouvée) sur le tuyau de sortie des erreurs. A cet égard, il est essentiel de connaître les erreurs. Je suggère d'utiliser la redirection de la console dans tous les cas si javaw
est invoquée.
En revanche, si vous utilisez
start java .... 1>log.txt 2>err.txt
Avec la console Windows start
la redirection de la sortie de la console ne pas travailler avec java
ni avec javaw
.
Explication de la raison pour laquelle il en est ainsi : Je pense que javaw
ouvre un processus interne dans l'OS (adéquat en utilisant la classe java.lang.Process), et transfère une redirection de sortie connue à ce processus. Si aucune redirection n'est donnée sur la ligne de commande, rien n'est redirigé et le processus interne démarré pour javaw
n'a pas de sortie console. Le comportement de java.lang.Process est similaire. La machine virtuelle peut utiliser cette fonctionnalité interne pour javaw
aussi.
Si vous utilisez 'start', la console Windows crée un nouveau processus pour Windows afin d'exécuter la commande après le démarrage, mais ce mécanisme n'utilise pas de redirection donnée pour le sous-processus démarré, malheureusement.
6 votes
C'est parce que Windows a cette fâcheuse habitude de lancer un véritable Terminal (qui ne devrait même pas être appelé "Terminal"...) au premier plan dès que vous lancez un programme avec
java -cp ...
. Comme presque personne ne le souhaite,javaw
est le choix qui permet de faire disparaître cette fenêtre gênante.