Messages
du sujet
Petit arrangement n°2 |
Saturnin
Membre depuis : 20 janv. 2008
Messages : 5
|
20 janv. 2008 à 17:08
Chapitre 10 - Interfaces utilisateur avec Swing
page 196
Exemple com/eteks/outils/ChargeurRessource.java
j'ai dû remplacer :
Class classe = getClass();
return new ImageIcon(classe.getResource(this.base + icon));
par :
return new ImageIcon (this.getClass().getResource(this.base + icon));
car Eclipse me disait "Class is a raw type. References to generic type Class<T> should be parameterized"
est ce correct ?
quoi qu'il en soit pourriez vous m'expliquer l'intention de la ligne
Class classe = getClass(); puis de ...classe.getResource...
j'aurais mieux compris si ça avait été Class classe = this.getClass(); encore que je ne sois pas sûr... d'ailleursdans ce cas Eclipse me dit toujours "Class is a raw type. References to generic type Class<T> should be parameterized"
et pourriez vous m'expliquer l'utilisation de la methode java.lang.Object.getClass() à laquelle il me semble que je ne comprends rien lorsqu'elle est utilisée par un objet de classe java.lang.Class<T> qui en hérite de java.lang.Object
|
Saturnin
Membre depuis : 20 janv. 2008
Messages : 5
|
20 janv. 2008 à 18:00
Finalement j'ai détaillé les choses comme ça car je préfère un code détaillé car plus facile à comprendre donc à maintenir :
public ImageIcon getIcon (String paramicon)
{
String adresse;
adresse = this.base + paramicon;
Class<?> classe;
classe = this.getClass();
URL url;
url = classe.getResource(adresse);
ImageIcon imageicon;
imageicon = new ImageIcon(url);
return imageicon;
}
|
Manu
Ville : Paris / France
Membre depuis : 29 avr. 2003
Messages : 394
|
20 janv. 2008 à 19:34
C'est pareil que pour votre petit arrangement n°1, c'est un avertissement et en aucun cas une erreur.
Et je ne changerai probablement pas ce code même dans la prochaine version du livre, car ça complique trop le code à mon avis et la généricité n'est disponible que depuis Java 5 (donc Class<?> ne compile pas sous Java 1.4).
Au passage, comme mentionné en haut de la page 38, ajouter "this." devant "getClass()" n'a aucun intérêt en Java, car getClass() fait forcément appel à une méthode de la classe !
Comme expliqué pages 162 et suivantes, chaque instance de la classe java.lang.Class est un objet qui représente la classe d'un objet. C'est à dire qu'à la classe "java.lang.String" correspond une instance de java.lang.Class qui la représente, à la classe "java.lang.Integer" correspond une instance de java.lang.Class qui la représente, et ainsi de suite pour chaque classe Java chargée en mémoire.
La classe java.lang.Class a de très nombreuses méthodes (citées en partie page 164) qui permet d'interroger le nom d'une classe, sa super classe, ses méthodes... Elle a aussi une méthode getResource qui permet de charger un fichier comme le fait la JVM pour un fichier .class, c'est-à-dire un fichier faisant partie du classpath. C'est très pratique car ça permet de regrouper ensemble toutes les classes d'un programme et ses fichiers annexes comme des icônes ou des fichiers de traduction ; cet ensemble peut-être soit dans un dossier si ce dossier est cité dans le classpath, soit dans un fichier .jar si c'est ce fichier .jar qui est cité dans le classpath.
En espérant vous avoir éclairé... --- Manu (moderator/modérateur)
|
Saturnin
Membre depuis : 20 janv. 2008
Messages : 5
|
21 janv. 2008 à 17:52
Concernant EditeurTexte.java p195 j'ai apporté qq petites modifications.
Dans EditeurTexte.java :
ChargeurRessource chargeur =
new ChargeurRessource ("/img/");
Mon fichier de compilation a cette tête là :
javac -sourcepath ../src -d ../classes ../src/<package>/*.java
del ..\classes\img\*.*
rd ..\classes\img
md ..\classes\img
copy ..\src\img\*.gif ..\classes\img
jar -cfM ../lib/Swing.jar -C ../classes .
javadoc -sourcepath ../src -d ../doc <package>
Mon fichier d'execution a cette tête là :
java -classpath ../classes <package>.EditeurTexte
ou bien cette tête là :
java -classpath ../lib/Swing.jar <package>.EditeurTexte
J'ai écrit <package> à la place du nom de mon package pour des raison de confidentialité.
Quoi qu'il en soit je me retrouve avec une aborescence complète dans mon fichier d'archive :
Swing.jar
|-- <package> -- *.class
|-- img -- *.gif
Juste un petit souci.
A la compilation je dois confirmer l'effacement del ..\classes\img\*.* en tapant Y pour yes et je n'arrive pas à trouver comment on écrit l'option pour pas avoir à confirmer l'effacement.
J'aurais jamais cru que je serais embêté par une commande dos en developpant du Java ! :)
|
Manu
Ville : Paris / France
Membre depuis : 29 avr. 2003
Messages : 394
|
22 janv. 2008 à 20:49
> A la compilation je dois confirmer l'effacement del ..\classes\img\*.* en tapant Y pour yes
> et je n'arrive pas à trouver comment on écrit l'option pour pas avoir à confirmer l'effacement.
En tapant "help del" vous auriez eu la réponse : il suffit d'ajouter l'option l'option /Q .
A l'occasion, regardez aussi Ant ; c'est plus pratique à mon avis. --- Manu (moderator/modérateur)
|