Discussion :

[bruno_nono]

Bonjour,

Après quelques recherches sur google, je n'ai pas trouvé de réponses, donc je me tourne vers mon forum préféré habituel

Je pense que je cherche "mal" sur google, d'où le manque de réponse concrète.

En faite, je travaille sur un projet, et j'aimerai créer dans mon dossier classpath
un fichier contenant des chemins de fichiers exemple
cheminFichier.conf
chemin1 = C://d1//d2/f1.txt

etc...
et ensuite dans l'application Java appelé le chemin1 (son contenu).
Je me rappelle avoir déjà utilisé cette méthode sur un projet, mais je ne me rappelle plus exactement sa mise en place. Et je n'arrive pas à exprimer en deux mots clés mes besoins sur google!

Pouvez-vous m'aider pour mettre en place cette structure , et est-ce possible ? (cela se trouve sur l'autre projet comme c'était du j2ee et cela tapait sur un serveur est surement différent que ce que je souhaite mettre en place en java "simple" (via eclipse)

edit: de la même manière j'utilise beaucoup de valeur clé qui sont utilisés dans des treemap et qui sont liées à des fichiers. Or j'utilise ces clés un peu partout dans mon application, dans le classpath, puis je mettre des clé associé à des valeurs afin de changer une seule fois dans l'application la valeur d'une de mes clés sans avoir à les modifier dans toute l'appplication ?


Merci!

[hwoarang]

Pour acceder à un fichier contenu dans ton archive :

Code :

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

getClass().getResource(path)

a+

[bruno_nono]

static Object someObject = new Object();
someObject.getClass().getResource(path)

(car je l'appelle dans un contexte static)

Cependant, comment accéder à un champs de ce fichier
chemin1 = "...."
chemin2 = "..."

Merci

[tchize_]

Qu'est-ce que tu entends par "ton dossier classpath"
Qu'est-ce que tu entend par "appeler le chemin 1 (son contenu)"
J'ai pas trop compris otn histoire de clé, mais pour éviter uen maintenance inutile, il vaux mieux créer des constante dans une classe ou une interface, voir utiliser des enum quand ça se justifie, et utiliser ces constantes dans le reste du code.

[bruno_nono]

Qu'est-ce que tu entends par "ton dossier classpath"
Qu'est-ce que tu entend par "appeler le chemin 1 (son contenu)"
J'ai pas trop compris otn histoire de clé, mais pour éviter uen maintenance inutile, il vaux mieux créer des constante dans une classe ou une interface, voir utiliser des enum quand ça se justifie, et utiliser ces constantes dans le reste du code.

1)Dossier classpath :
mon dossier sous eclipse qui se nomme "classpath" ou j'ai mis le fichier de config pour les log4j.

2) appeler le chemin 1 (son contenu)
En gros je souhaite créer mon fichier filesDir.conf
ce fichier contiendra des lignes du type :
chemin_1 = "D://....."
chemin_2 = "E://...."
etc...
et je souhaite quand j'appelle le fichier filesDir.conf (avec la réponse ci-dessus) que je puisse accéder au champs "chemin_1" et qu'il me renvoie "D://...."

Pour le système de clé, pareil: key.conf
clé_1 = "value_1"

et qu'il me renvoie value_1 quand j'accède clé_1 de key.conf .

La question étant : comment accéder à cette valeur.

Par rapport à ton retour:
De nombreuses classes ont besoin de ces clés, si je créer une interface avec des énum l'ensemble de classes vont devoir implémenter cette interface: cela me dérange au niveau de la programmation: est-ce une pratique "jolie", d'un point vue code ?? => pendant ma formation, on m'a rabâché qu'utiliser des variables globales était "mauvais" synonyme de mauvais programmeur

[hwoarang]

Ce que je comprends de ta demande :
- Tu veux embarquer un fichier dans ton archive jar et l'utiliser pour stocker des données.
- Tu veux pouvoir acceder au contenu de ton fichier

Un petit exemple valant mieux que 1000 mots :

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
      try
      {
         URL u = getClass().getResource("/res/fich1.txt");
         BufferedReader br = new BufferedReader(new InputStreamReader(u.openStream()));
         String str;
         do
         {
            str = br.readLine();
            System.out.println(str);
         } while(str != null);
      }
      catch (Exception ex)
      {
         ex.printStackTrace();
      }

Mais comme dit par tchize_, c'est plus simple est plus maintenable de faire un tableau de strings qui contiendrait le contenu de ton fichier.

a+

[gailuris]

De nombreuses classes ont besoin de ces clés, si je créer une interface avec des énum l'ensemble de classes vont devoir implémenter cette interface: cela me dérange au niveau de la programmation: est-ce une pratique "jolie", d'un point vue code ?? => pendant ma formation, on m'a rabâché qu'utiliser des variables globales était "mauvais" synonyme de mauvais programmeur

Non, pas besoin d'implémenter l'interface ou la classe contenant des constantes, il faudra l'importer par contre (pour pouvoir les utiliser avec du "MonInterface.MA_CONSTANTE").
Les variables globales c'est pas joli, les constantes par contre, je ne vois pas ce qu'il y a de choquant.

[tchize_]

pour lire facilement un fichier de la forme clé=valeur, utilise la classe Properties.

On t'as dit que els variable global c'est mal, et c'est vrai, mais on t'as surement aussi dit qu'il faut FACTORISER ton code pour éviter les répétition. En l'occurence, l'utilisation de constance contenant le nom de tes clés est une chose importance.

On ne v pas faire, par exemple, dans un code, trois fois

String cheminConfiguration = properties.getProperty("configurationPath");

mais on fera

public static final String CONF_KEY = "configurationPath";

puis 3 fois
String cheminConfiguration = properties.getProperty(CONF_KEY);

Ca évite les erreur de faute de frappe. Le compilateur peut vérifier que qu'il n'y a pas de faute à CONF_KEY, il ne peux pas vérifier qu'il n'y a pas de faute à "configurationPath". Il est donc une bonne pratique que tes clés, quand elle doivent être utilisée dans un fichier externes, soient des constantes, ca facilite la maintenance et diminue les risques d'erreur.

[bruno_nono]

Les variables globales c'est pas joli, les constantes par contre, je ne vois pas ce qu'il y a de choquant.

Quelle est la différence ?
-> une constance est une variable globale fixe ?

Code :

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

1
2
3
4
5
6
7
 
public Interface Constante{
  public static String CHEMIN1 = "D://...";
}
 
 //dans une classe qui a besoin de la valeur de chemin1, par exemple : 
loadFile(Constante.CHEMIN1);

Si j'ai bien compris . .

[bruno_nono]

Ok merci tchize_

C'est ce que je recherchais d'après mes souvenirs.

Merci aux autres membres (cela me fait plusieurs point de vue)

Reste maintenant à créer le fichier properties, pour cela je pense qu'il y a un tutoriel sur le site !

Merci :-)

[tchize_]

Quelle est la différence ?
-> une constance est une variable globale fixe ?

quand on oublie pas le "final" dans la ligne, oui

[bruno_nono]

validation:

hum... cependant dans une même classe le mot clé ne revient qu'une fois.

Exemple:

j'ai deux classes, Class1 et Class2 qui doivent utiliser le mot clé "configurationPath"

configurationPathest défini dans un fichier files.config qui contient
configurationPath=D://confke.txt


Dans chacune de ces deux classes, j'ai une méthode par exemple load(String path)

J'invoque, comme tu l'a spécifié, la class Properties: j'appelle donc la méthode load de cette manière :

Code :

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

1
2
3
4
5
6
7
8
 
FileInputStream f = new FileInputStream("files.properties" ); 
Properties properties = new Properties(); 
properties.load(f); 
load(properties.getProperty(configurationPath));
 
//au lieu de
load("D://confke.txt");

==> DU COUP, au lieu d'une ligne de code pour chaque classe, j'en ai 4,
soit 6 de plus.
Cependant: si je veux modifier le chemin je le fais qu'une seule fois au lieu de 2:

Ai-je bien implémenter ta solution ?


et si j'utilise plusieurs fois CONF_KEY dans UNE MÊME CLASSE alors je fais :

Code :

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

1
2
3
 
public static final String CONF_KEY = "configurationPath";
String cheminConfiguration = properties.getProperty(CONF_KEY);

[bruno_nono]

Code :

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

1
2
3
 
FileInputStream f = new FileInputStream("files.properties" ); 
FileInputStream f = new FileInputStream("//files.properties" );

ne fonctionnent pas (pourtant le fichier est bien dans le dossier classpath qui est dans le build path car log4j fonctionne correctement)

mais

Code :

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

 FileInputStream f = new FileInputStream(".//classpath//files.properties" );

fonctionne (je pensais que quand le dossier était dans le build path, il n'y avait pas besoin de spécifier le chemin.)


au final: à chaque fois que je veux une clé ou un chemin de fichier, je fais :

Code :

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

1
2
3
4
 
Properties properties = new Properties(); 
properties.load(new FileInputStream(".//classpath//files.properties"));
traitementFichier(properties.getProperty(ConfigInterface.PATH_KEY));

(dans ce cas là pourquoi utiliser la classe Properties ? On pourrait définir directement ds la constante PATH_KEY le chemin.)

[tchize_]

pour charger ce qui se trouve dans le classpath, on utilise une de ces méthodes

Code :

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

1
2
3
4
URL u = getClass().getResource()
InputStream is = getClass().getResourceAsStream()
URL u = getClass().getClassLoader().getResource()
InputStream is = getClass().getClassLoader().getResourceAsStream()

jamais un fileinputstream, qui lui est destiné aux fichier présent sur le système, pas au classpath.

[bruno_nono]

Ok! j'avais vu la solution avec la classe URL.

Pour mon problème suite à vos réponses, j'ai deux solutions possibles:

- créer un fichier file.properties avec key=valeur
=> utiliser la classe Properties et faire appel aux méthodes détaillées ci dessus

- créer une interface avec des constances KEY = valeur
=> faire appel à Interface.KEY

Pour ma part, je vais utiliser la deuxième solution plus rapide à utiliser => en deux mots j'accède à la valeur de la clé.

Y a t' il une raison qui me ferait préférer la solution 1 ?

[tchize_]

si les valeur doivent etre configurable pour le client / utilisateur.

[bruno_nono]

Merci !

edit pour les futurs utilisateurs de la solution: Utiliser

Code :

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

Thread.currentThread()

dans un contexte static devant les méthodes proposées ci-dessus

[bruno_nono]

Je viens grâce à vous de réaliser une optimisation dans la gestion des clés, cependant j'ai perdu en contre partie du temps de calcul

Avant optimisation, je faisais une boucle d'1 million contenant le code suivant

Code :

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

1
2
3
4
 
if(current_individual.getType().equals("xyz"))){
// traitement 
}

Cela me prenait 36 minutes, maintenant avec :

Code :

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

1
2
3
			if(current_individual.getType().equals(prop_keys.getProperty(KEY_IND))){
// traitement 
}

Cela me prend 1h15m

avec :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public static final String KEY_IND;
public static final Properties prop_keys = new Properties();
static{
	KEY_IND= "xyz";
	try{
			prop_keys.load(Thread.currentThread().getClass().getResourceAsStream("/keys.properties"));
	}catch(IOException io){
			System.err.print("Error in file keys.properties : open or locked");
		}
	}

L'accès à une constante prend donc beaucoup plus de temps (selon le nombre d'appel) si je crée une variable

Code :

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

 local = prop_keys.getProperty(KEY_IND);

Je gagne du temps mais cela reste toujours plus long.

Reste à savoir pour le programmeur / client s'il préfère un code "optimisé" et perdre en temps de calcul ou l'inverse.
edit: La solution pour éviter de perdre du temps consiste à initialiser dans le champ static directement :
par exemple

Code :

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

KEY_IND = prop_keys.getProperty("xyz");

ce qui a pour effet d'appeler qu'une seul fois getProperty au lieu de .. fois