Discussion :

[LucieDavid]

bonjour,

j'ai un projet d'informatique a faire dans le cadre de ma prépa intégré, qui consiste a créer une messagerie par fichier partagé en java, mais j'ai beau coup de difficultés à le réalisé. je sais qu'il faut que j'utilise les classe FileWriter et Filereader pour écrire et lire dans ce fichier mais je ne comprend pas comment on le partage... est ce que quelqu'un aurait une solution

l'intitule de mon projet est : messagerie par fichier partagé. L’objectif de cette partie est de développer un programme JAVA dont l'exécution sur des terminaux différents va permettre la communication entre deux utilisateurs. Afin d’assurer l’envoi des messages entre ces deux instances du programme JAVA (deux utilisateurs), nous utiliserons un ou plusieurs fichiers textes comme des intermédiaires de communication. En effet, un message envoyé par un utilisateur est stocké dans le fichier avant que le programme ne le récupère et l’affiche au destinataire. L’étudiant pensera à développer tous les mécanismes nécessaires pour la lecture, l’écriture et le traitement des messages échangés. Un répertoire accessible par tous les ordinateurs a été créé sur cette adresse :X(elle a été créer par l'école). Vous penserez à utiliser ce répertoire pour y stocker vos fichiers textes de communication.

[joel.drigo]

Salut,

FileWriter et FileReader sont en effet des solutions parmi d'autres pour écrire dans des fichiers textes. Il en existe d'autres, comme PrintWriter par exemple, ou des spécifiques pour des fichiers structurés (XML, JSON, etc...). C'est d'ailleurs un des premiers choix tu dois faire : la structure des données pour distinguer les messages, et éventuellement sinon connaître leur date (et leur ordre), leur expéditeur, leur destinataire, etc, et donc éventuellement le format des fichiers. Un autre choix de même ordre et lié est : fichier unique ou fichiers multiples, et structure de dossier. Le sujet semble autoriser le multifichier.
Donc il y a un choix à faire.
En cas de fichier unique, lorsqu'un programme écrira dans le fichier, l'autre ne pourra pas l'ouvrir (une exception sera soulevée). Pour gérer le problème, il faudra réessayer en boucle jusqu'à ce ce que ça marche. En cas de fichier unique, la solution du partage inter application me semble plus complexe qu'en multi fichier au premier abord. Pour du mono fichier, je choisirais plutôt une solution avec programme maître intermédiaire. Enfin tout dépend ce qu'on tolère dans le fonctionnement du "client".
En cas de multi fichiers, le souci majeur à priori sera l'ordre des messages : il est difficile de garantir que deux fichiers n'auront pas la même date (le tri devient donc peu utile), et de garantir que deux messages seront effectivement écrits dans le bon ordre. Seulement, on peut aussi ignorer ce problème : à l'échelle humaine, il est peu probable que cela ait une quelconque importance dans un système de chat... Mettre en place une solution avec ID incrémental revient à combiner la solution multi fichiers avec une solution mono fichier, ou à mettre en place un troisième programme intermédiaire. Une solution moins éfficace mais qui peut fonctionner peut être un système de "réservation" :

1. on collecte les fichiers ( par java.io.File.listFiles() par exemple, ou DirectoryStream (voir classe java.nio2.Files, méthode newDirectoryStream), ou Files.walk, etc
2. On détermine à partir de cette liste le prochain nom de fichier
3. on créé ce fichier vide (avec option de non remplacement en cas d'existence (voir les options des méthodes de java.nio2.Files), ce qui réserve ce nom, ou échoue parce qu'il existe déjà
4. si ça échoue on ajoute ce nom à la liste et on recommence au point 2

ça c'est la version non optimisée pour le principe.

Ensuite, une API qui pourrait t'intéresser est tout ce qui "Watching Service", qui te permettra de réagir à des créations ou modifications de fichiers, sans avoir à faire une boucle active de surveillance.

Enfin, toute ces problématiques d'écriture de fichier et d'essais multiples en boucle va introduire des temps d'attente pour l'utilisateur. Pour l'éviter, penser java.util.concurrent.ExecutorService/Executors), SwingWorker (par rapport à l'UI si Swing),

SI le répertoire de stockage est distant, il pourra y avoir des soucis selon le protocole de partage (SMB/SMB2/CICS, NFS...) et il pourra être éventuellement nécessaire de passer par une API spécifique.

[LucieDavid]

Mon projet se fait avec un fichier unique ! Donc en fait on utilise qu’un ordinateur si j’ai bien compris ?! Et qu’est-ce qu’un programme maître intermédiaire ? Et est ce que on ne peut pas créer un fichier, demander de l’ouvrir mettre FileWriter et FileReader et exécuter le programme plusieurs fois la premier fois par exemple le premier utilisateur écrit son message, ensuite on l’exécute de nouveau et la c’est le deuxième utilisateur qui écrit et vice versa à chaque exécution ?!

[joel.drigo]

Donc en fait on utilise qu’un ordinateur si j’ai bien compris ?!

Pas nécessairement. On te donne un dossier partagé (X: dans ton énoncé), à priori sur un serveur distant. Tu peux tester en lançant le programme deux fois sur la même machine ou sur deux machines différentes. Tu peux même tester sans machine distante en simulant l'accès distant (avec un subst sur un dossier local par exemple), en lançant les deux clients sur la même machine bien sûr.

Et qu’est-ce qu’un programme maître intermédiaire ?

Je parlais ici d'un programme qui se charge des manipulations du fichier. Le programme client qui permet de saisir et d'afficher des messages ne lit ni n'écrit directement dans le fichier, mais communique avec le programme maître. C'est comme un serveur, la communication n'étant pas forcément sous forme de service. Mais de toute manière ça ne semble pas être ce qu'on te demande, mais plutôt faire deux programmes qui accèdent au même fichier.

Et est ce que on ne peut pas créer un fichier, demander de l’ouvrir mettre FileWriter et FileReader

Un FileWriter permet d'écrire dans un flux créé à partir d'un fichier. Un FileReader permet de lire un flux créer à partir d'un fichier. Ce sont des opérations exclusives, on ne fait pas les deux à la fois (ce serait d'ailleurs extrêmement complexe de le faire avec deux programmes différents). On écrit le fichier complet (éventuellement, on peut "ajouter" à la fin, donc ouvrir le flux sans supprimer le contenu et écrire les nouveaux caractères à la suite de ceux précédemment écrits), on lit le fichier, complètement ou partiellement.

et exécuter le programme plusieurs fois la premier fois par exemple le premier utilisateur écrit son message, ensuite on l’exécute de nouveau et la c’est le deuxième utilisateur qui écrit et vice versa à chaque exécution ?!

On peut aborder la chose comme ça, oui, mais c'est plutôt fastidieux pour l'utilisateur que d'avoir à lancer le programme à chaque fois qu'on veut écrire un message ou lire un message, non ? Je ne sais pas ce qu'est le but de l'exercice, l'énoncé n'est pas assez explicite pour ça. J'imaginais plutôt que chaque utilisateur lançait son programme et tapait ses messages lorsqu'il en avait envie et que les messages de son interlocuteur s'affichaient dès que ce dernier envoyait son message... un chat classique donc, avec un mode différé permis par le stockage dans le fichier.