Discussion :

[flzox]

Bonjour,
je sais que le problème de la lecture de fichiers dans un jar à déjà été abordée, mais malgrés tout je ne trouve pas la solution à mon problème.

J'ai crée une petite appli et j'ai besoin de lire et ecrire dans fichier texte qui se trouve à la racine de mon projet (j'utilise eclipse).
Pour écrire dans mon fichier j'utilise un RandomAccessFile :

Code :

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

1
2
RandomAccessFile raf = new RandomAccessFile(path, "r");
String line = raf.readLine();

Pour lire je fais ça :

Code :

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

1
2
3
4
5
FileWriter fw = new FileWriter(path, append);
BufferedWriter bufferW = new BufferedWriter(fw);
PrintWriter pw = new PrintWriter(bufferW);
String line;
pw.println(line)

Donc tout ça c'est bien parce que ça marche quand j'execute depuis Eclipse, mais si je crée un Jar et que je le lance, il ne trouve pas le fichier (IOException).
Y a-t-il un autre moyen que de passer par un inputStream, parce que j'aimerais éviter de réecrire tous les passages de lecture et écriture de fichier.

Merci pour votre aide

[menuge]

Si tu veux être sûr de ton coup, passe par un path absolu et non relatif. Et teste avec un path de fichier codé en dur

[the-gtm]

http://java.developpez.com/faq/java/...mentRessources

[flzox]

J'ai résolu le problème pour la lecture, mais l'écriture ne marche pas.
J'ai cru lire quelque part que l'on ne pouvait pas écrire dans un fichier txt qui se trouve dans un jar. Si c'est vrai y'a-t-il une solution alternative, sinon ben ... comment on fait ?
pour info pour l'instant je fais ça :

Code :

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

1
2
3
4
5
 
FileOutputStream fo = new FileOutputStream(path);
PrintWriter pw = new PrintWriter(fo);
String line = (String)al.get(i);
pw.append(line+"\n");

[spekal]

Oui, tu ne peux pas écrire dans un jar, ou, plus exactement, ce n'est pas la bonne approche.

Tout ce qui est écriture / lecture nécessite l'accés à quelque chose de local, donc sur le disque dur où s'exécute l'appli. Il n'y a pas beaucoup d'échapatoire. Donc, à un moment ou à un autre, d'une manière ou d'une autre, il faut que tu demandes à l'utilisateur : Madame / Mademoiselle / Monsieur, veuillez m'indiquer s'il vous plaît l'endroit où je puis sauvergarder mes données.

Avec un peu de politesse et de savoir-vivre, une fois que c'est fait, tout devient plus facile...

[flzox]

Non en fait c'est un fichier texte qui contient une liste d'attributs succeptible d'évoluer pendant la session utilisateur. Mais celui ci n'a pas besoin de savoir ou il est.
Est-il possible de mettre le fichier et le jar dans un même dossier et de faire les allez-retour sur ce fichier comme ça ?
Si je sais par avance que le fichier est toujours dans le meme dossier que le jar je peux faire un chemin en dur type "./monFichier.txt" ? (bon j'ai essayé ça marche pas apparement).

[bouye]

Pour la lecture, pour par exemple lire la configuration par defaut, tu t'y prends mal. Normalement en utilisant le mecanisme de chargement du CLASSPATH, associe a un chemin relatif, tu peux acceder sans probleme a ton fichier qu'il soit dans un JAR (la version de production) ou pas (la version de devellopement dans Eclipse).

Code :

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

1
2
3
4
5
6
7
8
9
10
ClassLoader loader = getClass();
URL fileURL = loader.getResource(...);
// Si url == null alors fichier non-trouve car chemin non-correct ou fichier pas sur le CLASSPATH en general.
InputStream in = url.openStream();
try {
  ...
}
finally {
  in.close();
}

Quant a l'ecriture, dans la mesure du possible mieux vaut ecrire dans un fichier externe au JAR ou carrement d'utiliser l'API de Preferences (elle est faite pour ca apres tout).

[spekal]

Oui, l'API des Preferences (java.util.prefs) semble la mieux indiqué, sauf qu'elle n'est pas en rapport avec une session, mais avec un utilisateur ou un système. Si cela te convient malgré tout alors c'est l'idéal ; sinon tu ne peux pas échapper à la politesse.

En particulier, la combine de retrouver le répertoire du jar pour écrire le fichier dedans est piégée, car il arrive couramment que le repertoire dans son ensemble ne soit pas accessible en écriture.

Une combine souvent pratiquée pour éviter la politesse est de créer un répertoire caché dans le répertoire utilisateur ; mais elle n'est pas simple à manier, car il n'y a rien dans l'API standard pour cacher un fichier de façon portable.

[BoudBoulMan]

Moi pour écrire un fichier dans un jar... je dézipperais le fichier, j'écrirerais dessus puis je le rézipperais dans l'archive et je supprimerais le fichier dézippé.

Pour gérer les archives, il y a le package java.util.zip
et j'ai trouvé un tuto à cette adresse: http://www.supinfo-projects.com/fr/2...n_zip_en_java/

[bouye]

Ceci peut poser des problemes si le JAR doit etre signe...
Ensuite/De plus sur certains systemes (Windows) le JAR peut etre verouille/locke pendant son utilisation, ce qui empeche son ecriture.

, sauf qu'elle n'est pas en rapport avec une session, mais avec un utilisateur ou un système.

J'avoue ne pas bien comprendre la difference, mais cela vient probablement que je n'ai jamais fait d'appli "de session".
Tu peux de toute maniere stocker les infos de la session en cours dans les Preferences aussi en utilisant l'ID de la session actuelle pour les distinguer entre elles. Idem si on utilises un fichier texte centralise (plutot qu'un fichier propre a chaque session).

Code :

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

1
2
3
4
5
6
7
8
 
myApp/
         SessionID1/
                        param1/
                        param2/
         SessionID2/
                        param1/
                        param2/

Que ce soit dans les Preferences ou un ou plusieurs fichiers texte, il faut quand meme verifier que tu ne vas pas creer un nombre infini d'ID de sessions.

Apres sur un ordi local avec des applis locales, de toute maniere tout sera toujours lie a un compte utilisateur.

[BoudBoulMan]

Ceci peut poser des problemes si le JAR doit etre signe...

Seulement s'il s'agit d'une applet et s'il est lancé par JavaWebStart... sinon s'il est exécuté directement sur l'ordi de l'utilisateur, il a tous les droits.

Ensuite/De plus sur certains systemes (Windows) le JAR peut etre verouille/locke pendant son utilisation, ce qui empeche son ecriture.

Pourrais-tu m'expliquer pourquoi parce que, à ce que j'en sais, si on exécute un fichier dans un jar (ou tout autre archive), ce fichier est dézippé et mis dans un dossier temporaire, il ne devrait donc pas y avoir de problèmes d'accès à l'archive.

[bouye]

Seulement s'il s'agit d'une applet et s'il est lancé par JavaWebStart... sinon s'il est exécuté directement sur l'ordi de l'utilisateur, il a tous les droits.

Non, cela va bien au-dela d'une simple Applet :
- tu as besoin de signer tes JARs pour les meme raison pour Java Web Start.
- pour une compagnie autant que pour des particuliers qui distribuent des applis "serieuses" il est TRES TRES interessant de faire signer son Jar. Cela rajoute un niveau de "confiance" avec les clients.

ce fichier est dézippé et mis dans un dossier temporaire

A ma connaissance tout se passe en memoire au contraire... et il n'est meme pas sur du tout que le fichier soit dezippe d'une maniere quelconque (au contraire dans les notes techniques ils parlent de compression supplementaire pour que l'empreinte memoire de la JVM soit plus petite/restreinte. J'ignore cependant s'il s'agit de compression des .class dejare ou pas). De plus utiliser le disque pour une decompression serait comme s'attacher un boulet au pied en terme de performances.

Mais la on parlait de modifier le fichier texte et de le RE-INCLURE dans le JAR... ce qui casse la signature et peut ne pas fonctionner si le JAR est verouille contre l'ecriture.

[BoudBoulMan]

Non, cela va bien au-dela d'une simple Applet :
- tu as besoin de signer tes JARs pour les meme raison pour Java Web Start.
- pour une compagnie autant que pour des particuliers qui distribuent des applis "serieuses" il est TRES TRES interessant de faire signer son Jar. Cela rajoute un niveau de "confiance" avec les clients.

J'ai dit que si tu veux avoir accès aux fichiers locaux, tu dois signer ton jar s'il s'agit d'une applet ou s'il est lancé par le Java Web Start (même si le jnlp a plus de droits qu'une applet).

Si ton jar est lancé sur l'ordi directement, il n'a besoin d'aucune signature pour accéder aux fichiers. J'ai déjà créé une application de traitement de texte et je n'ai jamais eu à signer le jar, je lance javaws et hop ça marche.

C'est que s'il est lancé sur internet qu'il faut qu'il soit signé.

A ma connaissance tout se passe en memoire au contraire...

Ok, au temps pour moi

[bouye]

Je n'ais pas dis le contraire, mais il y a bien d'autre avantages a faire signer son fichier JAR, y compris s'il s'agit d'une application locale. Cela peut aider nottament le client a verifier que l'appli n'a pas ete bidouillee en verifant sa signature et son certificat. Ce n'est pas qu'un simple probleme d'obtenir des droits d'acces a certaines operations pour les Applet ou les applis Web Start.

Tu notteras que de plus en plus d'application telechargeables sur le Net, pas forcement en Java, et meme souvent OpenSource ou au contraire fournies par des editeur prives, le sont egalement pour eviter justement la distribution d'applications detournees et (potentiellement) verolees ou "wormees". D'ou le message de demande d'acceptation de la signature et de verification du certificat quand l'utilisateur lance l'application.