Discussion :

[Disixlis]

Bonsoir tout le monde j'apprend je java depuis peu et je code un petit rpg. J'ai réalisé ihm/gameplay/logique. En soit le jeu est déjà fonctionnel mais pour sont évolution je veux évidemment éviter de devoir le recompiler à chaque ajout/maj mineure. Je passe donc par la sérialisation/désérialisation (qui au passage est beaucoup plus simple que le c++ avec boost ! ). Pour ce coter c'est réglé. Maitenant j'ai voulu créer une nouvelle méthode permettant de récupérer les adresses où ce trouve mes objet sérialisé pour par la suite pouvoir les chargé.
J'ai donc un fichier SpellIndex contenant :

Code :

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

1
2
3
4
 
src/data/spells/s_01.dat
src/data/spells/s_02.dat
src/data/spells/s_03.dat

Une méthode récupérant les adresses qui renvoie un vecteur de string :

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
16
17
18
19
20
 
public static Vector<String> getRessource(RessourceType resType) throws IOException 
	{
		Vector<String> ressources = new Vector<String>();
 
		if (resType == RessourceType.SPELL) 
		{
			File file = new File("src/data/SpellsIndex");
			BufferedReader br = new BufferedReader(new FileReader(file));
			String line = new String();
 
			while ((line = br.readLine()) != null) 
			{
				ressources.addElement(line);
			}
			br.close();
		}
 
		return ressources;
	}

Et dans mon main j'ai mit ceci pour tester :

Code :

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

1
2
3
4
5
6
7
8
9
 
SpellLoader sl = new SpellLoader();
 
Vector<Spell> spells = new Vector<Spell>();
 
spells = sl.loadAll(tools.getRessource(RessourceType.SPELL));
 
for( int i = 0; i < spells.size(); i++ )
	System.out.println(spells.get(i).name());

Le problème c'est que j'ai trois sort et sur les trois il ne m'affiche que les deux dernier.
Je peux ajouter autant de ressources que je souhaite mais malgré tout il n'affichera jamais le premier sort.

J'ai beau chercher je vois pas d'erreurs :/ je m'y prend surement mal pour chargé les adresses mais comme je ne connais pas trop le Java, je suis un peu perdu sur le coup ^^"

Votre aide est la bien venu

Probléme résolue, en debug j'avais modifier une boucle pour qu'elle commence à 1 x)

[joel.drigo]

Salut,

Je ne vois pas trop où est le problème de devoir recompiler en cas d'évolution (ce n'est pas une opération très lourde et compliquée), mais admettons.

Sinon 2 choses :

1. File file = new File("src/data/SpellsIndex");Je suppose que tu comptes déployer ton programme, sous forme de jars (tu peux distribuer le jar principal contenant tes classes compilées et un second jar avec tes fichiers), pas sous forme de sources, ou sous forme de pleins de .class. Pour l'accès aux fichiers de ressources, on n'utilise pas File qui permet d'accèder à des fichiers. Il n'y a pas de fichiers dans les jars. Donc avec File, ça ne fonctionnera pas. Pour y accèder, on utilise Class.getResource() ou Class.getResourceAsStream().
   
   

   Code :

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

   1
   2
   3
   4
   5
   6
   try(BufferedReader br = new InputStreamReader(LeNomDeTaClassIci.class.getResourceAsStream("/data/SpellsIndex")) {
   	String line = null;
           while ((line = br.readLine()) != null) {
                ressources.addElement(line);
           }		
   }

   Idem pour chacun des .dat.
2. Vector est une classe obsolète. Utilise plutôt une List (par exemple ArrayList).

A noter que pour éviter les problèmes d'index, quand tu n'as pas besoin de traiter d'index dans la boucle, tu peux utiliser un foreach qui simplifie l'écriture :

Code :

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

1
2
for( Spell spell : spells )
	System.out.println(spell.name());

Voire mieux la méthode forEach de List :

Code :

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

spells.forEach(spell-> System.out.println(spell.name()));

Ou un stream

Code :

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

spells.stream().map(Spell::name).forEach(System.out::println);

[tchize_]

Ou un stream

Tant qu'on parle de Stream, ton code de lecture sera vachement plus facile avec java 8 aussi

Code :

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

1
2
3
try(BufferedReader br = new InputStreamReader(LeNomDeTaClassIci.class.getResourceAsStream("/data/SpellsIndex")) {
	return br.lines().collect(Collectors.toList());		
}

Code :

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

1
2
3
4
5
6
			String line = new String();

			while ((line = br.readLine()) != null) 
			{
				ressources.addElement(line);
			}

petites infos pour débutant:

• inutile d'initialiser une variable à une valeur que tu va immédiatement écraser dans ta boucle.
• si tu te retrouve à appeler explicitement le constructeur de String dans ton code, tu fais vraisemblablement une erreur car tu n'en a pas besoin. La jvm se charge déjà de les appeler avec les chaines de caractères statiques que tu lui fournis dans le code et pour ce qui est dynamique, c'est presque toujours retourné par des méthodes que tu appelle (Reader, StringBuilder, ...). Le seul cas parfois utilisable est le new String(char[]) quand on construit le char[] dynamiquement. Bref "new String" dans le code -> alerte rouge

Code :

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

1
2
3
4
 
String a1 = "aaaa" ; // bien
String a2 = "aaaa" ; // la jvm va réutiliser la String d'au dessus puisque c'est la même constante
String a3 = new String("aaaa"); // ça fait le même qu'au dessus mais avec un objet inutile en plus dans la mémoire

[hwoarang]

Je ne vois pas trop où est le problème de devoir recompiler en cas d'évolution (ce n'est pas une opération très lourde et compliquée), mais admettons.

C'est vrai que s'il a des joueurs non développeurs, c'est bien de pouvoir modifier certains parametrages sans avoir à tout recompiler. Typiquement, la quantité de dommages que font les sorts dans son exemple.

Pour y accèder, on utilise Class.getResource() ou Class.getResourceAsStream().

Pour ma culture personnelle, j'ai remarqué qu'à chaque fois que tu proposes d'utiliser ces méthodes, tu utilises toujours la classe ou elle est utilisée (ici, LeNomDeTaClassIci.class.getResourceAsStream("/data/SpellsIndex")). De mon coté, j'aurais tendance à utiliser Object.class.getResourceAsStream("/data/SpellsIndex") afin de pouvoir copier/coller et de faire la meme chose partout. Connais-tu un avantage/inconvénient à utiliser l'une plutot que l'autre ?

[joel.drigo]

C'est vrai que s'il a des joueurs non développeurs, c'est bien de pouvoir modifier certains parametrages sans avoir à tout recompiler. Typiquement, la quantité de dommages que font les sorts dans son exemple.

S'il ne s'agit que de données, je préfère nettement utiliser des fichiers de données plutôt que la serialisation/deserialisation de classes, qui pour moi, ne devrait servir qu'à transmettre entre deux systèmes des instances par un protocole de type "texte". Ensuite, si on veut pouvoir rendre évolutif un programme par l'ajout de programme (donc par des joueurs developpeurs), il y a toujours la solution de type plug-in.

Pour ma culture personnelle, j'ai remarqué qu'à chaque fois que tu proposes d'utiliser ces méthodes, tu utilises toujours la classe ou elle est utilisée (ici, LeNomDeTaClassIci.class.getResourceAsStream("/data/SpellsIndex")). De mon coté, j'aurais tendance à utiliser Object.class.getResourceAsStream("/data/SpellsIndex") afin de pouvoir copier/coller et de faire la meme chose partout. Connais-tu un avantage/inconvénient à utiliser l'une plutot que l'autre ?

A ce sujet je te suis. En réalité, je dévellope depuis 10 ans surtout du Eclipse RCP. Pour les ressources de type image, localisation, ou ce genre, qu'on met dans un dossier à part, "relatif" à la racine, j'utilise plutôt l'accès par les méthodes de l'activator, ou par le paramétrage de plug-in (manifest, extensions...), donc sans mention de classe (c'est le framework qui gère). Sinon, j'utilise les ressources pour paramétrer les classes, et là, je préfère les gérer en relatif, par rapport à la classe, pour pouvoir réutiliser dans un autre package/plugin par refactorisation ou copier/coller, sans avoir à me soucier d'adapter le path (surtout que ce n'est pas traité par la refactorisation automatique). Mais c'est vrai que dans l'exemple le chemin est absolu. C'est plus par habitude/reflexe que j'ai indiqué "LeNomDeTaClass".

[hwoarang]

S'il ne s'agit que de données, je préfère nettement utiliser des fichiers de données plutôt que la serialisation/deserialisation de classes, qui pour moi, ne devrait servir qu'à transmettre entre deux systèmes des instances par un protocole de type "texte". Ensuite, si on veut pouvoir rendre évolutif un programme par l'ajout de programme (donc par des joueurs developpeurs), il y a toujours la solution de type plug-in.

Oui, j'aurais aussi plutot été vers un fichier de config. Mais à la lecture du post initial, j'ai l'impression que c'est le but de la manip. Ceci étant dit, je peux me tromper...

A ce sujet je te suis. En réalité, je dévellope depuis 10 ans surtout du Eclipse RCP. Pour les ressources de type image, localisation, ou ce genre, qu'on met dans un dossier à part, "relatif" à la racine, j'utilise plutôt l'accès par les méthodes de l'activator, ou par le paramétrage de plug-in (manifest, extensions...), donc sans mention de classe (c'est le framework qui gère). Sinon, j'utilise les ressources pour paramétrer les classes, et là, je préfère les gérer en relatif, par rapport à la classe, pour pouvoir réutiliser dans un autre package/plugin par refactorisation ou copier/coller, sans avoir à me soucier d'adapter le path (surtout que ce n'est pas traité par la refactorisation automatique). Mais c'est vrai que dans l'exemple le chemin est absolu. C'est plus par habitude/reflexe que j'ai indiqué "LeNomDeTaClass".

Ok, merci pour l'info.

[adiGuba]

Salut,


Attention car il y a quand même une différence entre LeNomDeTaClassIci.class.getResource() et Object.class.getResource() : le ClassLoader utilisé n'est pas le même.

Dans une application "standalone" cela n'a pas beaucoup d'importance et cela revient au même.
Mais si notre code tourne dans une application serveur ou autre, il est possible que Object.class.getResource() ne trouve pas la ressource...

Donc il est bien préférable d'utiliser une classe qui sera stocké dans le même jar que les ressources.


a++