Fichier Java

[invite73b93f64]

Bonjour, j'ai besoins de votre aide parce que je dois vérifier les ajout ou suppression de fichier dans un certain dossier via un timer. Je dois également déclencher un certains évenement sur le fichier qui a été ajouté ou supprimer (je n'ai pas le droit de déclencher deux fois l'évenement sur le même fichier)le probléme est que je ne voit pas vraiment comment faire.

Voici ce que j'ai fait pour l'instant:

 private  static class MonActionListener implements ActionListener {
    	int nb;
		@Override
		public void actionPerformed(ActionEvent e) {
			String[] listeFile;
			File file = new File ("extension");
			FilenameF fnf= new FilenameF();
			
			listeFile = file.list();
			if (listeFile.length>....)
                       {
                          .......
 
			}
		}
    	
    }

Je voulait vérifier la taille du tableau (listfile) afin de savoir si un fichier a été supprimé ou ajouté, mais étant donner que je dois aussi récuperer le fichier qui a été supprimer (ou ajouter) afin de lui appliquer un évenement, cette méthode ne marche pas.

Je sais que mes éxplications ne sont pas très claire donc n'hesitez pas a poser des questions si vous n'avez pas bien compris.

Merci d'avance
-----

[invite4492c379]

Hello,

si je comprends ce que tu veux à intervalles réguliers :

* tu crées une liste L de fichier présents dans un répertoire donné (sans récursion ?)
* tu compares cette liste avec une précédente L' (que fait-on lors de la première itération ?)
*** pour tous les fichiers dans L mais pas dans L' tu effectues l'action effacement
*** pour tous les fichiers dans L' mais pas dans L tu effectues l'action ajout
* L' devient L


Que se passe-t-il pour :

* on crée le fichier A (le traitement est effectué), puis on l'efface (le traitement est effectué), puis on le recrée : on le traite comme un fichier jamais traité ? on le traite spécialement ?
* les traitement prennent tellement de temps qu'il faudrait déjà relancer un nouveau tour ; on le saute ? on les enchaine ?
* on crée puis on efface immédiatement un fichier entre deux tours : c'est grave ?

[invite73b93f64]

Merci beaucoup pour ton aide, tu a très bien compris ce que je voulait et je te remerci d'avoir proposé une solution. Tes questions sont très pertinante et j'avoue ne me les êtres pas posée du tout -_-

Avant de répondre aux question je vais expliquer ce que fait le programme:

lorsqu'on lance l'application, on a une fenetre dans laquelle on peut taper du texte, en haut a gauche il y a un menu, en selectionnant le menu plugin il y a la liste des "plugin" que l'on peut utiliser (ces "plugins" sont des fichier .class) par exemple il y a le plugin majuscule, qui met le texte en majuscule, le plugin numérique, qui transforme le texte en chiffre ect....Ces plugins sont contenu dans un dossier extension, si pendant l'execution du programme, un plugin est ajouter, il sera automatiquement ajouter dans la liste des plugins (et il pourra être utilisé tout de suite), s'il est éffacé , il sera automatiquement éffacé de la liste des plugin


"on crée le fichier A (le traitement est effectué), puis on l'efface (le traitement est effectué), puis on le recrée : on le traite comme un fichier jamais traité ? on le traite spécialement ?"
Oui on le traite comme un fichier jamais traité

* les traitement prennent tellement de temps qu'il faudrait déjà relancer un nouveau tour ; on le saute ? on les enchaine ?
Pense-tu qu'il soit possible de réglé ce probléme en augmentant le délait nécaissaire a la réactivation de l'evement du timer?

[invite4492c379]

C'est dans le cadre d'un exercice où l'utilisation d'un timer est imposée ?

Le comportement que tu souhaites implémenter peut poser plusieurs problèmes surtout si le repository des plugins est sur le réseau et accessible à plusieurs processus. Si je résume, soit (il y a certainement d'autres solutions mais là je jette à la volée) :

1. tu as un thread qui va gérer une liste de plugins, le menu déroulant lui affiche cette liste. L'action associée au menuitem sera de charger le .class et d'effectuer un traitement sur le texte (sélectionné au préalable je suppose).

2. tu as un thread qui va gérer une liste de plugins et modifier directement le menu déroulant, charger le .point et créer l'action du menuitem. Ensuite lors de l'affichage cette action est déclenchée sur le texte

3. tu n'as pas de thread qui gère la liste des plugin et c'est au moment où l'utilisateur sélectionne le menu déroulant que la liste est créée et les actions créées.

4. tu n'as pas de thread qui gère la liste des plugins, tu gardes en local un cache des plugins disponibles, le menu déroulant utilise les .class de ce cache local et tu permets à l'utilisateur via un menu de rafraichir le cache (update des plugins)

Avec 1 et 2 tu as les problèmes de gestion de thread, synchronisation, accès à une ressource partagée, etc ...
avec 3 et 4 tu t'en affranchis.

Avec 1,2 et 3 tu peux te retrouver dans une situation où un plugin est effacé entre le moment où la liste est créée et le menuitem sélectionné avec des effets de bord assez marrants parfois (l'utilisateur voit le menu clique dessus et on lui dit plus disponible = utilisateur frustré ; le menu déroulant est affiché, l'utilisateur positionne la souris sur un menuitem qui juste avant le clique est effacé ou déplacé du coup une autre action que celle souhaitée est déclenchée = utilisateur frustré).

Avec 4 tu as beaucoup moins de problèmes.

Cela va dépendre de l'énoncé principalement (donc du but de l'exercice).

[A voir en vidéo sur Futura]

[invite73b93f64]

Merci pour ton aide, en effet l'utilisation d'un timer est obligatoire , voici le sujet

----> http://www.fil.univ-lille1.fr/~routi...tp/plugins.pdf
Comme vous pouvez le voir dans le sujet ils aident a faire le programme pas à pas, c'est pour cela qu'au début je me contentais de detecter la supression et l'ajout de fichier

[invite73b93f64]

Grâce a ta méthode j'ai réussi a coder la detection des fichier .class (evidemment il faudra que j'essaye d'enlever les différents bug possible). Maintenant non seulement je dois detecter les .class mais je doit aussi vérifier que ces classes n'appartiennent a aucun package et ont un constructeur sans paramètre... j'ai réussi a trouver comment vérifier le package mais pour le constructeur , j'ai regarder sur internet mais je n'ai rien trouvé qui puisse me permettre de faire cela. Dans le sujet il est écrit qu'il faut charger l'instance avec Class.forName(...) mais je ne vois pas quoi faire après

[invite73b93f64]

Je n'arrive pas a supprimer mon précédent message mais j'ai fini par trouvé

[invite73b93f64]

finalement je n'ai pas trouvé pour la classe, je voulais essayer class.getDeclaredConstructors( ) , mais ca ne fait pas ce que je voulais. est-ce que vous avez une idée de ce qui pourrait m'aider?

Merci d'avance

[invite4492c379]

Tu as jeté un coup d'oeil sur la réflexivité ?
Un plugin (pour être considéré comme un plugin) doit implémenter une interface ...

[invite73b93f64]

Je ne savait pas ce qu'était la reflexivité, donc j'ai chercher un peu et ca m'a amené a ca
--> if (c.getClass().getSuperclass(). equals(Class.forName("Extensio n")))

Mais le probléme c'est que le fichier que je recupere est un .class, je ne sais pas si c'est a cause de cela mais quand je fais c = Class.forName("nomdufichierenE nlevant.class"); ca ne marche pas. Et je n'ai pas le fichier .java correspondant à ces .class . j'ai beau cherché je ne trouve pas de solutions pour régler ce probleme

[invite4492c379]

Malheureusement je ne suis pas assew calé en java pour t'aider plus loin
La réfléxivité est un mécanisme général commun à de nombreux langages.
Dans le pdf que tu as donné en lien, il y a la partie plugins qui détaille :

* charger une classe par Class.forName()
* utiliser Class.isAssignableFrom()

Tu as essayé ?

[invite73b93f64]

j'ai réussi a detecter la classe (en ajoutant le dossier contenant les .class au classpath), apparement la condition que je voulais utiliser pour vérifier que la super classe était Extension ne marche pas, j'ai aussi éssayer if (c.isAssignableFrom(Class.forN ame("Extension"))). Mais ca ne marche pas non plus

[invite73b93f64]

J'ai réussi a faire 2 conditions,

if (interfaces[0].getName().equals("application .extensions.Extension") && p.getName().equals("default package"))

Mais je ne sais toujours pas comment faire pour vérifier que le constructeur n'a aucun paramétre.

[invite73b93f64]

Je pense avoir réussi mais je trouve mon code asser...je sais pas pourquoi mes les else false a répétitions me genes.

public boolean accept(File arg0, String name) {
		// TODO Auto-generated method stub
		/* Class[] ctorArgs2 = new Class[3]; */
		String name2;
		if ((name.endsWith(".class"))) {
			name2 = name.replaceAll(".class", "");
			name2.trim();
			Class<?> c = null;

			try {

				c = Class.forName(name2);
			} catch (ClassNotFoundException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}

			if (c != null) {
				Constructor<?>[] listeconstru = c.getConstructors();
				Class<?>[] tabloparam = listeconstru[0].getParameterTypes();
				int nbparam = tabloparam.length;
				Class[] interfaces = c.getInterfaces();

				Package p = c.getPackage();

				if (interfaces.length>0 && interfaces[0].getName().equals("application.extensions.Extension")&& p == (null)) {
				//	System.out.println("Le fichier " + name2 + " est acceptée");
					return true;
				}
				else
				{
					return false;
				}
			}
			else
			{
			return false;
			}
		}
		else {
		return false;
		}
	}

[invite4492c379]

Hello,

je ne sais pas s'il y avait plus simple ... mais les imbrications de if/else sont courantes dans les codes où on essaye de faire une gestion exhaustive des erreurs (enfin en objet en général les blocs try sont souvent très courant aussi).

[invitea0ecda6e]

Une autre version si tu n'aimes pas les imbrications de if-else:

public boolean accept(File arg0, String name) {
		// TODO Auto-generated method stub
		/* Class[] ctorArgs2 = new Class[3]; */
		String name2;
		
		if (! (name.endsWith(".class"))) {
			return false;
		}

		name2 = name.replaceAll(".class", "");
		name2.trim();
		Class<?> c = null;

		try {
			c = Class.forName(name2);
		} catch (ClassNotFoundException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}

		if (c == null) {
			return false;
		}

		Constructor<?>[] listeconstru = c.getConstructors();
		Class<?>[] tabloparam = listeconstru[0].getParameterTypes();
		int nbparam = tabloparam.length;
		Class[] interfaces = c.getInterfaces();

		Package p = c.getPackage();

		if (!(interfaces.length>0 && interfaces[0].getName().equals("application.extensions.Extension")&& p == (null))) {
			return false;
		}

		// System.out.println("Le fichier " + name2 + " est acceptée");
		return true;
		
	}

[invite7863222222222]

Mais je ne sais toujours pas comment faire pour vérifier que le constructeur n'a aucun paramétre.

comme ça

private boolean hasSimpleConstructor(Class clazz){

	try{
		clazz.getConstructor(new Class[]{});
	}
	catch(NoSuchMethodException e){
		return false;
	}
	
	return true;
}

[invite7863222222222]

pratiquement pareil mais mieux :

private boolean hasSimpleConstructor(Class clazz){

	try{
		clazz.getConstructor();
	}
	catch(NoSuchMethodException e){
		return false;
	}
	
	return true;
}

[Tryph]

Salut,

j'avais un prof qui nous répétait sans cesse qu'une fonction ne devrait avoir qu'une seule instruction return à la fin, que c'était bien mieux pour la compréhension du code et autres arguments que j'ai oublié.
et du coup, j'ai tendance à ne pas trop aimer mettre plusieurs return comme ça.

à la place, je positionne plutôt une variable que je renvoie à la fin, à l'occasion de la seule instruction return de ma fonction... mais en fait, ça revient au même.

dans ton code par exemple, je commencerais par déclarer une variable "retVal" et de la positionner à false.
ensuite je positionnerais cette variable à true dans le cas ou tout s'est bien passé (à la place de ton "return true").
et à la fin je retournerais la variable plutôt qu'une valeur en dur.

ainsi on économise tout les "else {return false;}" et le comportement reste le même:
la variable que tu retournes à la fin étant à false par défaut, si une erreur survient avant que tu la positionnes à true, c'est forcément false qui sera renvoyé.

a+

edit: oups, j'avais pas vu la 2e page. x:

[invite7863222222222]

j'avais un prof qui nous répétait sans cesse qu'une fonction ne devrait avoir qu'une seule instruction return à la fin, que c'était bien mieux pour la compréhension du code et autres arguments que j'ai oublié.
et du coup, j'ai tendance à ne pas trop aimer mettre plusieurs return comme ça.

Moi j'aime bien, car ca renforce encore plus l'important de l'instruction d'échappement laquelle dans l'équivalence de Church Turing, a été prouvé comme l'équivalence du raisonnement par l'absurde : http://www.pps.jussieu.fr/~krivine/a...s/fonctpro.pdf.

Tu peux répondre cela à ton prof, s'il t'embête :P.

Si tu penses à développer avec cela en tête, à savoir que l'instruction d'échappement, est un outil à part entière et très puissant, je peux t'assurer que t'arriveras pas à faire du code plus lisible que ca.

[Tryph]

ca fait bien longtemps que je n'ai plus de prof, et que je trouve quand même les séries de return dans une fonction très inélégantes et peu claires.

exemple avec le bout de code en #14: on a 4 instructions return dont 3 renvoient false et 1 renvoie true.
on voit bien dans quel cas on renvoie true, c'est l'enchainement positif de tous les tests.
mais pour ce qui est des return false, c'est tout de suite moins clair puisqu'il faut retourner voir plus haut, et pour chaque else{return} à quelle condition il correspond. encore là ça va la fonction est plutôt courte, mais pour croiser régulièrement dans mon boulot des fonction de 200/300 lignes (voire plus) avec ce genre de structures avec des if-else et des return, et ou il faut remonter 100 lignes pour voir à quel cas correspond le return en question, je peux te dire que c'est super chiant.
pour peu que l'indentation soit mal faite, et c'est l'enfer...

je trouve que fixer une valeur par défaut en début de fonction, la modifier seulement quand c'est nécessaire et la renvoyer en fin de fonction est bien plus clair, lisible et compréhensible pour le gars qui arrive derrière celui qui a écrit le code.
dans ce cas précis, c'est false tout le temps... sauf quand dans le cas ou on met la variable à true et dans ce cas, la condition correspondante est juste au dessus. ça fait moins de questions à se poser.

bon après je suppose que c'est surtout une question de gout...

[invite7863222222222]

ca fait bien longtemps que je n'ai plus de prof, et que je trouve quand même les séries de return dans une fonction très inélégantes et peu claires.

exemple avec le bout de code en #14: on a 4 instructions return dont 3 renvoient false et 1 renvoie true.
on voit bien dans quel cas on renvoie true, c'est l'enchainement positif de tous les tests.
mais pour ce qui est des return false, c'est tout de suite moins clair puisqu'il faut retourner voir plus haut, et pour chaque else{return} à quelle condition il correspond. encore là ça va la fonction est plutôt courte, mais pour croiser régulièrement dans mon boulot des fonction de 200/300 lignes (voire plus) avec ce genre de structures avec des if-else et des return, et ou il faut remonter 100 lignes pour voir à quel cas correspond le return en question, je peux te dire que c'est super chiant.
pour peu que l'indentation soit mal faite, et c'est l'enfer...

je trouve que fixer une valeur par défaut en début de fonction, la modifier seulement quand c'est nécessaire et la renvoyer en fin de fonction est bien plus clair, lisible et compréhensible pour le gars qui arrive derrière celui qui a écrit le code.
dans ce cas précis, c'est false tout le temps... sauf quand dans le cas ou on met la variable à true et dans ce cas, la condition correspondante est juste au dessus. ça fait moins de questions à se poser.

bon après je suppose que c'est surtout une question de gout...

Non non je vous confirme que c'est pas une question de gout, comme je vous le dit c'est une prise de conscience qui devrait au code suivant :

public boolean accept(File arg0, String name) {
		// TODO Auto-generated method stub
		/* Class[] ctorArgs2 = new Class[3]; */
		String name2;
		if ((name.endsWith(".class"))) {
			name2 = name.replaceAll(".class", "");
			name2.trim();
			Class<?> c = null;

			try {

				c = Class.forName(name2);
			} catch (ClassNotFoundException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}

			if (c != null) {
				Constructor<?>[] listeconstru = c.getConstructors();
				Class<?>[] tabloparam = listeconstru[0].getParameterTypes();
				int nbparam = tabloparam.length;
				Class[] interfaces = c.getInterfaces();

				Package p = c.getPackage();

				if (interfaces.length>0 && interfaces[0].getName().equals("application.extensions.Extension")&& p == (null)) {
				//	System.out.println("Le fichier " + name2 + " est acceptée");
					return true;
				}
			}
		}
		return false;

	}

Haaa... c'est mieux hein ?

Après soit la prise de conscience se fait, soit pas, c'est vous qui voyez.

[invite4492c379]

Hello,

Dans le monde professionnel il y a surtout une contrainte à respecter : le «coding standard», les goûts ou préférences personnels sont à oublier.

[invite7863222222222]

les goûts ou préférences personnels sont à oublier.

Oui mais non en pratique, les développeurs non plus, ne sont pas des robots.

[invite4492c379]

Oui mais non en pratique, les développeurs non plus, ne sont pas des robots.

Quel est le rapport ?

[invite7863222222222]

Quel est le rapport ?

Ben Qtout est dit.

[invite4492c379]

Ben Qtout est dit.

Tout projet qui atteint une certaine importance (très subjectif) et impliquant plus de deux personnes (toujours aussi subjectif) est obligé (objectif) de définir des règles pour pouvoir bénéficier d'un cycle de vie pérenne.
Ce n'est absolument pas un frein à quoi que ce soit, mais effectivement c'est souvent mal perçu par les pondeurs de code si c'est imposé sans contexte et sans explications.

[invite7863222222222]

Tout projet qui atteint une certaine importance (très subjectif) et impliquant plus de deux personnes (toujours aussi subjectif) est obligé (objectif) de définir des règles pour pouvoir bénéficier d'un cycle de vie pérenne.
Ce n'est absolument pas un frein à quoi que ce soit,

Je ne peux qu'approuver, ni un frein aux goûts ou préférences personnels, notamment. Tout dépend finalement, de la rigidité des dites règles.

[invite4492c379]

Qui peuvent beaucoup différer d'une personne à une autre ... ce qui peut être dangereux dans le cadre d'un projet impliquant plus d'une personne ...
Ensuite si il s'agit d'un pet project, chacun fait comme bon lui semble, choix du langage, du paradigme, de l'IDE, ...

[invite7863222222222]

Qui peuvent beaucoup différer d'une personne à une autre ... ce qui peut être dangereux dans le cadre d'un projet impliquant plus d'une personne ...

C'est pourquoi il existe des outils automatiques qui permettent aux développeurs, de converger vers une uniformité du code.