Discussion :

[jadey]

Hello les gens,
Mon besoin est de lire le contenu d'un fichier.
J'ai les deux méthode suivantes pour lire le contenu d'un fichier ligne par ligne (je ne peux pas utiliser un objet Scanner apparu depuis java 5):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
public static StringBuffer readAFile(String filePath) {
		StringBuffer result = new StringBuffer();
 
		try {
			//		   Création du flux bufférisé sur un FileReader, immédiatement suivi par un 
			//		   try/finally, ce qui permet de ne fermer le flux QUE s'il le reader
			//		   est correctement instancié (évite les NullPointerException)
			BufferedReader buff = new BufferedReader(new FileReader(filePath));
 
			try {
				String line;
				//		   Lecture du fichier ligne par ligne. Cette boucle se termine
				//		   quand la méthode retourne la valeur null.
				while ((line = buff.readLine()) != null) {
					//System.out.println(line);
					result = result.append(line);
				}
			} finally {
				//		   dans tous les cas, on ferme nos flux
				buff.close();
			}
		} catch (IOException ioe) {
			//		   erreur de fermeture des flux
			System.out.println(
				"Erreur sur com.projet.util.FileOperation.readAFile(String) -->"
					+ ioe.toString());
		}
		return result;
	}
 
	public static String readFile(String theFileName) {
		InputStreamReader flog = null;
		LineNumberReader llog = null;
		String myLine = null;
		String myConcatLines = "";
		try {
			flog = new InputStreamReader(new FileInputStream(theFileName));
			llog = new LineNumberReader(flog);
			while ((myLine = llog.readLine()) != null) {
				// --- Ajout de la ligne au contenu
				myConcatLines += myLine;
			}
		} catch (Exception e) {
			// --- Gestion erreur lecture du fichier (fichier non existant, illisible, etc.)
			System.out.println(
				"Erreur sur com.projet.util.FileOperation.readFile(String) -->"
					+ e.toString());
		}
		return myConcatLines;
	}

Toutes les deux marchent sur une machine windows faisant tourner WAS 5.1 en JDK 1.4 (environnement de dev)
Ce code lève une exception

Code :

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

sun.io.MalformedInputException

lorsqu'il tourne sur la machine de prod sous unix avec WAS 6 et JDK 6
Je ne peux pas déboguer sur la machine de prod pour savoir à quel niveau ça bug malheureusement.
Que signifie cette exception ?

Merci pour toutes vos contributions.

[nu_tango]

Salut,



Il est plutôt conseillé en général de monter son environnement de dev avec les mêmes versions de JDK et du serveur d'application qu'à la cible (ie la Production). Ca évite d'avoir des mauvaises surprises lors des mises en Prod... Mais tu n'as peut-être pas le choix ?

Pourrais-tu nous afficher la stackTrace complète de ta MalformedInputException ainsi que nous préciser de quel Unix il s'agit (HP-UX, AIX, Solaris, *BSD,...)

A+

[tchize_]

Code :

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

BufferedReader buff = new BufferedReader(new FileReader(filePath));

Il y a un erreur là. A chaque fois que vous construisez un Reader, précisez un encodage explicite, sinon, l'encodage utilisé dépendra de la configuration de l'environnement hote, ce qui, dans 99% des cas, n'est pas le comportement désiré.

[jadey]

Mais tu n'as peut-être pas le choix

exacte.

Pourrais-tu nous afficher lastackTrace complète de ta MalformedInputException ainsi que nous préciser de quel Unix il s'agit (HP-UX, AIX, Solaris, *BSD,...)

pour la stack demain à la première heure. Pour la distribution c'est un AIX.

Il y a un erreur là. A chaque fois que vous construisez un Reader, précisez un encodage explicite

comment expliquer le fait qu'il y ait le même soucis sur la deuxième méthode?
P.s:c'est un code issu de la FAQ qu'il faudrait corriger éventuellement.

[nu_tango]

Salut,

tchize_ a raison, il faut définir l'encodage utilisé par le fichier :

Code :

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

1
2
3
4
5
6
Charset charset = Charset.forName("ISO-8859-1"); // par exemple
BufferedReader buff = null;
InputStreamReader isr = null;
	try {
		isr = new InputStreamReader(new FileInputStream(filePath), charset);
		buff = new BufferedReader(isr);

sinon tu va dépendre des variables locales LC_ALL ou LANG du serveur. (fr_FR.UTF8 par exemple)

comment expliquer le fait qu'il y ait le même soucis sur la deuxième méthode?

Sur la deuxième méthode c'est pareil, il faut rajouter le charset utilisé dans ton FileInputStream :

Code :

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

1
2
Charset charset = Charset.forName("ISO-8859-1"); // par exemple
flog = new InputStreamReader(new FileInputStream(theFileName), charset);

A+

[Logan Mauzaize]

Il n'y a que moi que ca choque de voir des System.out pour une application en production ? Encore pire la stacktrace est jetée à la poubelle, je voudrais pas traiter les points supports de cette application ...

[jadey]

Code :

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

java.nio.charset.Charset

n'existe pas sur cet environnement (JDK 1.4.1 b0344.02)
J'attends la stacktrace. J'espère pouvoir voir plus clair après et être en mesure de vous presenter des elements susceptible de m'aider un peu plus.

[jadey]

Je n'aurais visiblement pas recours à la trace. Vos conseils se sont avérés judicieux et ont résolu le problème.

Code :

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

new InputStreamReader(new FileInputStream(theFileName), ConstantsFacturation.CHARSET_UTF8);

Merci.

[tchize_]

Il n'y a que moi que ca choque de voir des System.out pour une application en production ? Encore pire la stacktrace est jetée à la poubelle, je voudrais pas traiter les points supports de cette application ...

Si il n'y avait que ça Non fermeture des stream, catch sur "Exception", utilisation de jdk1.4 qui n'est plus supporté en environnement de dev (il a du être déterré de quelque part)

Code :

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

java.nio.charset.Charset

n'existe pas sur cet environnement (JDK 1.4.1 b0344.02)

Ben faudra mieux ouvrir les yeux:
http://javasearch.developpez.com/j2s...t/Charset.html

Since:
1.4

De toutes facons, utilisez un jdk encore supporté, pas un machin antédéluviens qui date de matusalem. Votre environnement de prod est en java6 et vous êtes occupé de vous couper de tous les avantage apporté par java 5 et 6 en plus d'augmenter drastiquement vos risque d'erreur lors de la mise en prod.

[Logan Mauzaize]

Si il n'y avait que ça Non fermeture des stream, catch sur "Exception", utilisation de jdk1.4 qui n'est plus supporté en environnement de dev (il a du être déterré de quelque part)

Pas mieux

De toutes facons, utilisez un jdk encore supporté, pas un machin antédéluviens qui date de matusalem. Votre environnement de prod est en java6 et vous êtes occupé de vous couper de tous les avantage apporté par java 5 et 6 en plus d'augmenter drastiquement vos risque d'erreur lors de la mise en prod.

Dans des grosses boîtes (surtout les gros industriels) il est hors de question de changer de plateforme, ce n'est d'ailleurs pas toujours possible : exemple un avion.
Là j'ai un client qui me demande une analyse concernant l'utilisation d'une JRE 1.6 avec une application codée/compilée avec le JDK 1.5 car ion intègre un COTS codé/compilé avec le JDK 1.6 Je ne sais même pas par où commencer (tout idée/suggestion est la bienvenue)

[tchize_]

un peu hors sujet, mais le premier point à regarder est la liste des incompatibilités et changements mise en place par oracle. Normalement, meme une applicaiton jdk1.4 est capable de tourner sur java 6, tant qu'elle bidouille pas là ou elle est pas censée bidouiller (JNI, apis sun.*, etc). Après, je m'inquiéterais pas trop, il n'y a pas de gros changement entre les deux.De toutes façons, sun a toujours gardé une compatibilité d'exécution avec les anciennes version (pas une compatibilité de compilation cependant, avec l'ajout des nouveaux mot clés :p)


Maintenant pour le cas de jadey, c'est son poste dev qui est en java 1.4, la prod est en java 6, donc je vois pas pourquoi il traine son dev en 1.4
Les avions tournent pas que je sache sur du java :p
Et de toutes facons, dans une grosse boite, faut bien expliquer au manager que, comme il est en 1.4, c'est un outils non maintenu. On ne garde pas un outil en production si celui-ci peut irrémédiablement casser du jour au lendemain, à moins d'être suicidaire. Faut lui prévoir un plan de sortie. Et en 2012, ce sera la fin des contrat de maintenace buisness sur java 1.4. Or, vu les bug très sérieux trouvé dans cette jvm et dans d'autres, se maintenir à jour est un minimum.

[Logan Mauzaize]

Effectivement avoir un poste de développement utilisant Java 1.4 alors que la production est en Java 1.6. C'est vraiment bancale.

Que tu ne saches pas ! Les avions embarquent des applications Java, tout comme les satellites Bien sûr ce ne sont pas des commandes de vol.

Dans une grosse boîte tu dois convaincre ton chef de projet (parfois également le directeur de projet), son intermédiaire (parfois le chef de l'intermédiaire), (avec un peu de chance t'as pas d'autres intermédiaire), le service achat/produit/commercial, le client.
Si la demande arrive déjà jusqu'au bout de la chaîne t'as de la chance. D'ici là que la demande soit validée, commandée, achetée, développée, testée, déployée. La demande est déjà devenue obsolète.

Concernant la fin du support business (que ce soit Java ou pas) est bien à l'heure actuelle le seul facteur déterminant (Exemple à mon boulot du passage de Solaris 8 à Solaris 10). Encore qu'on nous demande de maintenir des applications Web fonctionnant sous Windows 2000/IE 6. En revanche dans le sens inverse ils sont pro-réactifs. On a eu la demande du support IE9 le lendemain de sa sortie

[tchize_]

Dans une grosse boîte tu dois convaincre ton chef de projet (parfois également le directeur de projet), son intermédiaire (parfois le chef de l'intermédiaire), (avec un peu de chance t'as pas d'autres intermédiaire), le service achat/produit/commercial, le client.
Si la demande arrive déjà jusqu'au bout de la chaîne t'as de la chance. D'ici là que la demande soit validée, commandée, achetée, développée, testée, déployée. La demande est déjà devenue obsolète.

Oui, mais ça c'est le problème des stackeholder. C'est du java 4, ça pete, ben tant pis pour eux.

Si tu veux accélérer, fait leur la démonstration sur un serveur en production, de ce qui se passe quand on entre le chiffre magique

Ici on a 3 JVM qui ont migré dans l'heure qui a suivi la publication du correctif d'oracle

[jadey]

quand on entre le chiffre magique

Pas mal je garde ça sous le coude