Réglage de la machine virtuelle Java ligne.séparateur
Personne n'a trouvé un moyen de spécifier la Java line.separator
propriété sur VM de démarrage? Je pensais à quelque chose comme ceci:
java -Dline.separator="\n"
Mais cela ne veut pas interpréter le "\n" comme caractère de saut de ligne. Des idées?
Pouvez-vous essayer \r\n
OriginalL'auteur | 2010-09-14
Vous devez vous connecter pour publier un commentaire.
Essayez d'utiliser
java -Dline.separator=$'\n'
. Cela devrait faire l'affaire, au moins dans bash.Voici un essai:
Remarque:
L'expression
$''
utilise le Bash fonction ANSI-C Citant. Il développe des anti-slash-des caractères d'échappement, ainsi$'\n'
produit un saut de ligne (code ASCII 10) caractère, entourés de guillemets simples. Voir le manuel de Bash, section 3.1.2.4 ANSI-C Citant.Je peux voir comment cela pourrait être utile, par exemple, un test de scénario.
Merci, c'résolu à partir de la ligne de commande. Cela ne fonctionne toujours pas à partir à l'intérieur de la course de config de l'IDE Eclipse, mais ce n'est pas important.
OriginalL'auteur aioobe
À combler le fossé entre aioobe et Bozho réponses, moi aussi je ne vous le conseille réglage de la
line.separator
paramètre de démarrage de la JVM, comme cela peut être fatale à de nombreuses hypothèses fondamentales de la JVM et le code de bibliothèque fait à propos de l'environnement en cours d'exécution. Par exemple, si une bibliothèque dont vous dépendez s'appuie surline.separator
afin de stocker un fichier de config dans une croix-plate-forme de façon, vous avez juste cassé ce comportement. Oui, c'est un cas limite, mais qui le rend d'autant plus infâme lorsque, des années à partir de maintenant, un problème ne se posent, et maintenant tout votre code dépend de ce tweak en place, tandis que vos bibliothèques sont (bien) en supposant qu'il ne l'est pas.Cela dit, parfois, ces choses sont hors de votre contrôle, comme lorsqu'une bibliothèque s'appuie sur
line.separator
et ne fournit aucun moyen pour vous de remplacer ce comportement de manière explicite. Dans un tel cas, vous êtes coincé substitution de la valeur, ou quelque chose de plus douloureux comme le re-mise en œuvre ou de la correction du code manuellement.Pour ces cas limités, il est possible de remplacer
line.separator
, mais nous avons à suivre deux règles:Ces deux exigences sont bien servis par
AutoCloseable
et la try-with-resources syntaxe, j'ai donc mis en place unPropertiesModifier
classe proprement fournit à la fois.Mon cas d'utilisation était avec
Fichiers.write()
, ce qui est très pratique la méthode, sauf qu'il s'appuie explicitement surline.separator
. En enveloppant l'appel àFiles.write()
je peux proprement spécifier le séparateur de ligne que je veux utiliser, sans risquer d'exposer cela à toutes les autres parties de mon application (prendre note de cours, que ce n'est toujours pas thread-safe).OriginalL'auteur dimo414
Je ne ferais pas ça si j'étais vous. La ligne de séparation de la plate-forme, et doit le rester. Si vous voulez écrire uniquement sous windows ou linux uniquement les fichiers, définir un
UNIX_LINE_SEPARATOR
constante quelque part et l'utiliser à la place.Je remercie si vous considérez que d'autres personnes ne sont pas seulement stupide, mais ont leurs raisons. La mienne, qu'un programme Java est appelé à partir d'un script shell. Le script shell utilisé stdout de l'application Java et les processus. Si vous exécutez le script à partir de Cygwin, Java utilise Windows des sauts de ligne. Cependant, ce qui provoque des problèmes dans le script. Donc, j'aimerais changer Javas de ligne par défaut.séparateur dans le cas où il est lancé à partir de Cygwin.
tout d'abord, vous pourriez avoir partagé ces informations dans la question. Deuxièmement, quel est si spécial à propos de shell-script qui ne peut pas être programmé en Java? Il ne semble pas raisonnable pour moi d'avoir un linux de logiciel java, qui vous aiment courir avec Cygwin. Soit de fournir un
.bat
fichier (comme Tomcat, par exemple), ou déplacer les fonctionnalités à une classe Java. Et enfin, je ne considère pas quelqu'un de stupide. Mais les gens sont souvent inexpérimentés.Juste assez. Je suis juste à l'appui d'un co-développeur ici qui traite avec certains logiciels existants. Par conséquent, il n'y a pas beaucoup de décisions de ma part. Je suis juste le gars pour Java questions. Et vous êtes mon gars compliqué Java questions. 😉
OriginalL'auteur Bozho