[JAVA] Ouvrir un fichier et vérifier sa taille

[Soolfly]

Bonjour,

Je prépare actuellement un projet dans le cadre de mes études, et ce projet doit être développer en Java.

L'application contiendras deux partie, la partie traitement d'un fichier de log (codé en Hexa) et la partie Interface Graphique (J2EE).

Pour l'instant je me concentre sur la partie Traitement de l'application.

Voici le diagramme UML de Séquence, de la partie Traitement de l'application :

Pour l'instant, j'ai codé uniquement une class Java qui charge le driver JDBC pour se connecter à une BDD MySQL.

Mais mon problème actuel, c'est d'avoir une base, un début de code pour ouvrir un fichier en local (import java.io.File ?), de vérifier sa taille, et de lire son contenu.

Est-ce que quelqu'un aurait une idée de code pour que je puisse partir d'une base solide ?

Merci d'avance.

[foetus]

Le Java défonce tout le monde sur la sérialisation:

1. Discover the secrets of the Java Serialization API (Officiel)
   
2. Pour débutant
   
3. Un autre parmi Google
   

Par contre pour la taille des fichiers, est-ce vraiment important?

Par contre niveau performance rien ne vaudra je pense les API Systéme Assembleur C

[fabien29200]

Pour lire un fichier ligne par ligne tu peux faire ça :

try {
try {
reader = new BufferedReader(new FileReader(new File("tonFichier.txt")));

String ligne;
while ((ligne = reader.readLine()) != null) {}

} finally {
	if (reader != null) {

		reader.close();
	}
}

} catch (Exception e) {

e.printStackTrace();
}

[Soolfly]

Merci fabien29200 :)

Ca va m'aider. Par contre juste une petite question supplémentaire si jamais tu connais la réponse :

Comment lire mon fichier en question, sachant qu'il ne contient aucune en-tête, que le contenu est en héxa, et je souhaiterais que ma classe Java lise le fichier tout les 95 caractères (95 char = 1 code d'erreur).

Je m'explique. Voici le fichier hexa en question :

Les 95 caractères sont identifiés et délimités entre les crochets (cf les 7 premières lignes du fichiers)

J'aimerais donc faire en sorte que le code Java lise ce fichier 95 caractères par 95 caractères, et ca sera déjà une bonne chose de faite !

Merci d'avance

[fabien29200]

Dans l'exemple que je t'ai donné, tu lis le fichier ligne par ligne.

Si tu n'as pas de lignes et que tu veux lire 95 caractères par 95 caractères, il n'y a pas besoin de créer un BufferedReader.

Il suffit d'appeler la méthode : read(char[] cbuf, int offset, int length) sur le FileReader.

[foetus]

Un petit exemple limité à 6 caractères au lieu de 95:

package Main;

import java.io.Externalizable;
import java.io.IOException;
import java.io.ObjectInput;
import java.io.ObjectOutput;


public class CodeErreur implements Externalizable
{
private static final long serialVersionUID = 349250398350863596L;

private final byte taille = 6;

public char code[];


public CodeErreur () {
	code = new char[taille];

	for (byte nocase = 0; nocase < taille; nocase++) {
		code[nocase] = 0;
	}
}


// Constructeur par recopie
public CodeErreur (char init[]) {
	code = new char[taille];

	for (byte nocase = 0; nocase < taille; nocase++) {
		code[nocase] = init[nocase];
	}
}


public String toString() {
	String chaine = new String();

	for (byte nocase = 0; nocase < taille; nocase++) {
		chaine += code[nocase];
	}

	return chaine;
}


@Override
public void readExternal(ObjectInput in) throws IOException,
	ClassNotFoundException {

	for (byte nocase = 0; nocase < taille; nocase++) {
		code[nocase] = in.readChar();
	}
}


@Override
public void writeExternal(ObjectOutput out) throws IOException {
	for (byte nocase = 0; nocase < taille; nocase++) {
		out.writeChar(code[nocase]);
	}
}

}

Fichier CodeErreur.java, package Main

package Main;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;


public class Main
{

static public void main(String ...args) {
	try {
		// Écriture de 2 Codes Erreurs dans le fichier "fichierlog.txt"
		char ccode1[] = {'A', 'B', 'C', 'D', 'E', 'F'};
		char ccode2[] = {'U', 'V', 'W', 'X', 'Y', 'Z'};
		CodeErreur code1 = new CodeErreur(ccode1);
		CodeErreur code2 = new CodeErreur(ccode2);

		FileOutputStream ofstream = new FileOutputStream("fichierlog.txt");
		ObjectOutputStream oostream = new ObjectOutputStream(ofstream);

		try {
			oostream.writeObject(code1);
			oostream.writeObject(code2);
			oostream.flush();
		} finally {
			try {
				oostream.close();
			} finally {
				ofstream.close();
			}
		}

		// Lecture des 2 Codes Erreur
		FileInputStream ifstream = new FileInputStream("fichierlog.txt");
		ObjectInputStream iostream = new ObjectInputStream(ifstream);
		CodeErreur code = new CodeErreur();

		try {
			code = (CodeErreur) iostream.readObject();
			System.out.println(code);
			code = (CodeErreur) iostream.readObject();
			System.out.println(code);
		} finally {
			try {
				iostream.close();
			} finally {
				ifstream.close();
			}
		}
	} catch (IOException exception) {
		exception.printStackTrace();
	} catch (ClassNotFoundException cnfe) {
		cnfe.printStackTrace();
	}
}
}

Fichier Main.java, package Main

/!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\

Avec ce code, tu peux lire X caractères par X caractères. Même plus que cela: objet par objet.

Mais si tu ouvres ton fichier où sont écrit tes objets, tu peux voir qu'ils ne sont pas contigües

/!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\ /!\

Édit: Eclipse quelle sous-saleté moisie

[Mcpanch]

Apparemment ça a pas encore été répondu, donc pour checker la taille du fichier :

File file = new File("c:/temp.txt");

long byteSize = file.length();

//divisé par 1024 pour des KB

long kbSize = byteSize / 1024;

[Charles.w]

Édit: Eclipse quelle sous-saleté moisie

Le jour ou Eclipse sera un bon IDE, ca se saura...pour le moment, c'est juste un hideux

PS : NetBeans User depuis la v3.5

PS2 : Promis j'arrête de troller

[Mcpanch]

@Charles.w

Ouais tu trolles, et c'est pas bien !

(Mais bon c'est pas faux en même temps )

[Nicky5]

Le jour ou Eclipse sera un bon IDE, ca se saura...pour le moment, c'est juste un hideux

PS : NetBeans User depuis la v3.5

+1 Utilisé sur un projet pharmaceutique, j'ai senti la différence !!!!

[fabien29200]

Perso, j'ai essayé Netbeans au boulot, viré au bout d'une heure.

Beaucoup trop lent comparé à Eclipse.

Disons, qu'avec Eclipse, il faut passer un peu de temps pour installer les plugins, comprendre son fonctionnement (ainsi que les intéractions entre les différents plugins) mais ensuite, ça reste le meilleur IDE que j'ai essayé.

[foetus]

Perso, j'ai essayé Netbeans au boulot, viré au bout d'une heure.

Beaucoup trop lent comparé à Eclipse.

Disons, qu'avec Eclipse, il faut passer un peu de temps pour installer les plugins, comprendre son fonctionnement (ainsi que les intéractions entre les différents plugins) mais ensuite, ça reste le meilleur IDE que j'ai essayé.

En septembre 2010 j'ai installé NetBeans. Constat: toutes les 5 minutes, il mettait 7-8 minutes pour faire une réorganisation/ optimisation ou je ne sais pas quoi:

[Charles.w]

NB : Ceci n'est pas un troll

Lors de l'utilisation de maven, NetBeans indexe le contenu des répositories...histoire de proposer une autocomplétion digne de ce nom dans les POMs...après, il parse aussi toutes les classes histoire de retrouver certains patterns de commentaires pour constuire des listes de tâches...c'est activé par défaut, mais c'est désactivable...suffit d'aller dans les préférences

Pour moi, Eclipse c'est pour les gens sous Windows / linux qui veulent un truc qui ne marche pas out of the box...et NetBeans c'est un peu comme le Mac...c'est pour ceux qui ont passé l'age de tout configurer ou de se prendre la tête à savoir quel est le meilleur IDE...pour se concentrer sur ce qu'ils sont sensé faire : leur travail !

Après, je pourrais discuter du comment du pourquoi NetBeans est mieux gaulé qu'Eclipse...et en quoi la plateforme de NetBeans est plus intellectuellement satisfaisante que celle d'Eclipse...ou encore en quoi la communauté Eclipse est fermée au changement ou aux nouvelles idées pendant des heures (demandez à RedHat et à PetalsLink ce qu'ils pensent de l'éditeur BPEL d'Eclipse...impossible de faire autre chose que de la correction de bugs sans risquer de se faire retirer ses droits de commit...ou presque...alors que tout le monde s'accorde à dire que la chose est l'une des pire choses qui soit jamais arrivées à l'Homme*)...mais bon...

* non non, je ne force pas le trait...ou si peu

[fabien29200]

De mon expérience, Netbeans c'est bien si t'as un projet avec 3-4 classes.

Au taf j'ai plusieurs projets avec des milliers de classes. Bah, rien que sur un seul, Netbeans, il rame grave.

Quand on a pris l'habitude d'avoir ses "Call hierarchy" en moins de 5 secondes et son petit "Open Resource" qui est pour ainsi dire instantané, c'est rédhibitoire de passer à un IDE qui n'arrive pas à le faire.

[Charles.w]

Si tu as besoins d'avoir plusieurs milliers de classes dans ton éditeur c'est que ta base de code est pourrie...si tu fais un code modulaire avec des interfaces bien définies et de l'injection de dépendances bien pensée...je suis désolé, mais je ne vois pas pourquoi on aurait besoin de plusieurs milliers de classes dans son éditeur.

Après, même sur une base de code pourrie (pas testable, code pas bien compartimenté, développeur qui verrouille sa base de code (pourquoi passer par des interfaces, injecter ses dépendances proprement ou documenter...c'est tellement mieux sans )...itou), je n'ai jamais eu de problèmes avec NetBeans...avec des projets Maven Eclipse ne remonte jamais la version du code qui est effectivement utilisée...alors que NetBeans si (enfin pour être précis remonte par introspection les classes si elle ne sont pas chargées dans l'éditeur ou que la bonne version du projet n'est pas chargée dans l'éditeur)...et si un éditeur ne me balance pas les bonnes versions de classes...désolé, ce n'est pas un bon éditeur

[fabien29200]

Ben quand tu bosses sur des grosses applications, tu tournes généralement dans le millier de classes.

Genre sur une CRM avec tout le code métier, la présentation, les appels base de données ... ça monte vite.

Je comprends pas trop ton histoire de code ... Dans Eclipse, si tu coches l'option de télécharger les sources des paquets Maven, tu as les sources correspondant à ta classe.

[Charles.w]

Et le code d'un ESB c'est lourd aussi (110 000 lignes de codes effectives, 85 000 lignes de commentaires, pour quelques milliers de classes...hors librairies tierces)...pourtant on n'a jamais besoin d'avoir toutes les sources dans son éditeur...

Après, le support de Maven dans Eclipse à longtemps été catastrophique...donc peut être que le problème que je cite à été corrigé...après, il est vrai qu'Eclipse ne recompile pas tous le projet (juste les classes modifiées), mais ce support n'est pas complet...notamment lorsqu'on supprime des classes...donc au final, je ne sais pas si cette option est vraiment bonne

Enfin on peut tergiverser pendant des heures...maven permet à tout un chacun d'utiliser son éditeur favori et c'est tant mieux...

[fabien29200]

Le truc, c'est qu'avec Eclipse, il faut plusieurs années avant de vraiment bien le maîtriser.

Du coup, on hésite un peu à switcher d'IDE

[Charles.w]

Pareil pour NetBeans et certains de ses raccourcis historiques à 5 mains