Problème de déploiement avec javax.swing.event.ChangeListener()

Résolu
ChPortos Messages postés 12 Date d'inscription mercredi 18 octobre 2006 Statut Membre Dernière intervention 30 avril 2008 - 29 avril 2008 à 11:44
ChPortos Messages postés 12 Date d'inscription mercredi 18 octobre 2006 Statut Membre Dernière intervention 30 avril 2008 - 30 avril 2008 à 14:38
Bonjour,


J'ai une applet avec un JTabbedPane dans lequel je souhaitais détecter
le changement d'onglet. J'ai donc sur mon JTabbedPane la ligne :
<!-- BEGIN TEMPLATE: bbcode_code -->

Code :
<!--[if !IE]><--><!----><!--[endif]--><!--[if IE]>
<![endif]-->onglets_Dessins_Zone.addChangeListener(new javax.swing.event.ChangeListener(){
publicvoid stateChanged(javax.swing.event.ChangeEvent e){
if(nbre_ecrans>0){
ChangerEcran();
}
}

<!-- END TEMPLATE: bbcode_code -->Lorsque je lance mon applet grâce à
AppletViewer, aucun problème, mais lorsque je déploie cette applet sur
une page HTML je reçois l'erreur suivante dans la console :
<!-- BEGIN TEMPLATE: bbcode_code -->

Code :
<!--[if !IE]><--><!----><!--[endif]--><!--[if IE]>
<![endif]-->java.lang.NoClassDefFoundError: Onglet_dessins$4
at Onglet_dessins.getOnglets_Dessins_Zone(Onglet_dessins.java:784)
at Onglet_dessins.getPnl_Dessins_Zone(Onglet_dessins.java:768)
at Onglet_dessins.getPnl_Dessins_PanneauPrincipal(Onglet_dessins.java:739)
at Easy_control_web_applet.getPanneau_onglets(Easy_control_web_applet.java:953)
at Easy_control_web_applet.getPaneau_principal(Easy_control_web_applet.java:909)
at Easy_control_web_applet.init(Easy_control_web_applet.java:587)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: Onglet_dessins$4
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 8 more
 

<!-- END TEMPLATE: bbcode_code -->D'où cela provient-il ???


Merci d'avance !

Ch'Portos.


P.S.: La ligne en erreur est celle correspondant à la définition du ChangeListener ...

9 réponses

indiana_jules Messages postés 750 Date d'inscription mardi 9 mars 2004 Statut Membre Dernière intervention 23 décembre 2008 22
30 avril 2008 à 13:58
Salut
oui, il faut que tous ces fichiers class soient présents dans ton Jar. Il existe d'autres alternatives aux classes anonymes et internes, c'est carrérement de construire une classe adaptée à ton listener. Néanmoins, quand tu lis des articles un peu avancé, Sun préconise l'utilisation des classes anonymes pour une meilleure performance, et pour une question aussi de processus.

Donc soit tu les rajoutes dans ton jar (conseil du chef), soit tu crées des classes implémentant ton listener.

Voili voilà

le monde a des idées : la preuve, c'est qu'il y en a de mauvaises
ne comprends pas tout, mais je parle de tout : c'est ce qui compte
3
indiana_jules Messages postés 750 Date d'inscription mardi 9 mars 2004 Statut Membre Dernière intervention 23 décembre 2008 22
29 avril 2008 à 11:52
Salut,
je ne pense pas que cela vienne de ton codage de ton listener, car l'erreur indique qu'il ne connait pas la classe Onglet_dessins$4. Autrement dit, cela correspond certainement à la classe anonyme de ton listener. Du coup, je suppose que ton jar de ton applet de contient pas cette classe (problème de génération).

Essai de regénérer ton jar pour voir, ou de l'ouvrir (c'est un fichier zip, donc tu peux l'ouvrir avec winzip, winrar ...) et voir s'il inclut bien le fichier class "Onglet_dessin$4.class"

Voili voilà

le monde a des idées : la preuve, c'est qu'il y en a de mauvaises
ne comprends pas tout, mais je parle de tout : c'est ce qui compte
0
ChPortos Messages postés 12 Date d'inscription mercredi 18 octobre 2006 Statut Membre Dernière intervention 30 avril 2008
29 avril 2008 à 12:45
Salut,

Mon applet se charge via 3 jar (obligation de ne pas dépasser 64Ko / fichier) et après vérification, j'ai bien ma classe Onglet_dessins.class contenue dans une des jar (le 3ème). J'ai vérifié aussi que ma page HTML appelle bien les 3 jar :
<APPLET CODE=Easy_control_web_applet.class ARCHIVE="Easy_control_web_applet.jar,Easy_control_web_applet2.jar,Easy_control_web_applet3.jar" WIDTH="996" HEIGHT="505"></APPLET>

De plus, dès que je supprime la déclaration du ChangeListener cette erreur disparaît
Enfin, j'ai exactement la même erreur dans une autre classe de la même applet utilisant la même déclaration (enfin déclaration d'un nouveau ChangeListener pour faire autre chose).

Une autre idée ?

Ch'Portos.
0
indiana_jules Messages postés 750 Date d'inscription mardi 9 mars 2004 Statut Membre Dernière intervention 23 décembre 2008 22
29 avril 2008 à 12:48
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
ChPortos Messages postés 12 Date d'inscription mercredi 18 octobre 2006 Statut Membre Dernière intervention 30 avril 2008
29 avril 2008 à 13:01
Le problème : je ne vois pas d'où peut bien venir cette classe "$4", puisqu'elle n'existe nulle part, mais il m'est déjà arriver de voir ce genre d'ajout dans mes stacktraces, surtout lors de l'utilisation de tableaux ou de plusieurs instances d'une même classe (peut-être pour différencier les différents objets ?)
Donc non, je n'ai pas d' "Onglet_dessins$4.class" dans mes jar ...

Ch'Portos.
0
Utilisateur anonyme
29 avril 2008 à 18:45
J'ai déjà eu ce problème avec des classes anonymes. Utilise ANT pour générer ton JAR ou bien ton IDE favori voire les deux.

TUER : http://tuer.tuxfamily.org/tuer.php

yeah! vive java
0
indiana_jules Messages postés 750 Date d'inscription mardi 9 mars 2004 Statut Membre Dernière intervention 23 décembre 2008 22
30 avril 2008 à 08:51
Salut,
petite explication sur la génération des noms de fichiers de type .class. Java procéde de la maniére suivante :
-si classe, classe abstraite ou interface : nomdelaclasse.class
-si classe interne : nomdelaclasse$nomdelasousclasse.class
-si classe anonyme : nomdelaclasse$unchiffre.class ou nomdelaclasse$nomdelasousclasse$unchiffre.class

Autrement, en codant ton listener de la sorte, tu as implicitement générée une classe anonyme, donc il est normale que dans tes sources .java, ce nom ne soit pas apparaissant.
En revanche, si ces .class ne sont pas présents, ton code ne pourra pas fonctionner (car ta classe l'utilise explicitement).

gouessej propose une bonne solution pour la génération de tes jars, mais si tu utilises Eclipse, tu trouveras plein de tutos sur coment faire un Jar via Eclipse.

Voili voilà

le monde a des idées : la preuve, c'est qu'il y en a de mauvaises
ne comprends pas tout, mais je parle de tout : c'est ce qui compte
0
ChPortos Messages postés 12 Date d'inscription mercredi 18 octobre 2006 Statut Membre Dernière intervention 30 avril 2008
30 avril 2008 à 09:17
OK indiana_jules et gouessej, j'utilise effectivement Eclipse, et j'ai un build.xml qui me créée mes JARs automatiquement en fin de compilation (en gros : nettoyage du dossier de destination, copies de 2 fichiers .html et .jpg, création des 3 JARs).

Après vérification, dans le dossier destination de la compilation j'ai effectivement des .class avec des chiffres (qui correspondent effectivement au nombre de fois où j'ai crée un listener de cette manière dans mes différentes classes)

Le problème :
- Suis-je obligé d'ajouter tous ces XXXXXXXXX$Y.class dans mes jars ?
- "en codant ton listener de la sorte," <= y'a-t-il un autre moyen de faire ça pour ne pas générer de classe anonyme (et donc résoudre le premier problème) ?

Merci d'avoir trouvé la raison du problème !

Ch'Portos.
0
ChPortos Messages postés 12 Date d'inscription mercredi 18 octobre 2006 Statut Membre Dernière intervention 30 avril 2008
30 avril 2008 à 14:38
Effectivement, il aurait paru lourd de devoir créer une classe par listener, car chaque listener faisant des actions bien particulières (dépendant de l'élément lanceur)

Pour faciliter l'intégration dans le JAR, j'ai ajouté cette ligne à mon build.wml, hsitoire qu'il ajoute en auto toutes les classes anonymes :

Voilà, merci encore !

Ch'Portos.
0