Ordre d'appel des listeners

Version imprimable

25/09/2013, 01h03
Modulpro

Ordre d'appel des listeners

Bonjour,

Mon problème est simple, mais je ne suis pas parvenu à trouver une réponse dans le forum, la faq, ou la doc de l'API (même google n'a pas pu me renseigner :cry:)

J'ai un composant (en l'occurrence un JToggleButton) auquel j'ajoute successivement deux itemListener. Expérimentalement, j'ai pu constater que lors du changement d'état du JToggleButton, c'est le code du dernier listener ajouté qui est exécuté en premier. Je me demande donc si l'API garanti toujours cet ordre dans l'appel des méthodes des listeners, ou bien si cela peut changer d'une jvm à l'autre.

Merci d'avance si vous pouvez m’éclairer sur ce point.
Cordialement.
25/09/2013, 02h02
MasterMbg

Bonjour,
peux tu poster le code utilisé pour permettre un bon checking???
25/09/2013, 02h44
tchize_

à défaut d'indication contraire dans les méthodes de JToggleButton, tu dois considérer que rien n'est acquis à ce sujet.

Bonjour,

C'est une très bonne question :)
Lors du clique sur un JToggleButton, la méthode setSelected(boolean b) du model (ToggleButtonModel) envoie une notification (un fireItemStateChanged()) pour que le code du listener soit exécuté....

Voici le corps de cette méthode :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 /** * Notifies all listeners that have registered interest for * notification on this event type. * * @param e the <code>ItemEvent</code> to deliver to listeners * @see EventListenerList */ protected void fireItemStateChanged(ItemEvent e) { // Guaranteed to return a non-null array Object[] listeners = listenerList.getListenerList(); // Process the listeners last to first, notifying // those that are interested in this event for (int i = listeners.length-2; i>=0; i-=2) { if (listeners[i]==ItemListener.class) { // Lazily create the event: // if (changeEvent == null) // changeEvent = new ChangeEvent(this); ((ItemListener)listeners[i+1]).itemStateChanged(e); } } }
On déduit bien que les listeners sont notifiés dans cet ordre : du dernier au premier ajouté au composant.
Donc pour répondre à ta question : oui actuellement le code du JDK (ToggleButtonModel : classe interne de la classe JToggleButton) garanti toujours cet ordre de notifications aux listeners.

29/09/2013, 17h24
joel.drigo

Citation:

Envoyé par awane

On déduit bien que les listeners sont notifiés dans cet ordre : du dernier au premier ajouté au composant.
Donc pour répondre à ta question : oui actuellement le code du JDK (ToggleButtonModel : classe interne de la classe JToggleButton) garanti toujours cet ordre de notifications aux listeners.

Salut,
seul le contrat de la méthode importe (indiqué dans la javadoc de la méthode) : on ne doit jamais se fonder sur une implémentation particulière pour fonder un traitement de ce type : on ne sait jamais comment l'implémentation peut évoluer. C'est typiquement le truc qui fait que ça peut foirer dans des années avec la mise à jour d'un jdk ou openjdk ou autre... ou sur un autre système.
Comme le disait @Tchize_, si le contrat de la méthode ne spécifie rien, on doit partir de principe qu'il n'y a pas d'ordre garanti.
29/09/2013, 17h48
awane

Citation:

Envoyé par joel.drigo

Salut,
seul le contrat de la méthode importe (indiqué dans la javadoc de la méthode) : on ne doit jamais se fonder sur une implémentation particulière pour fonder un traitement de ce type : on ne sait jamais comment l'implémentation peut évoluer. C'est typiquement le truc qui fait que ça peut foirer dans des années avec la mise à jour d'un jdk ou openjdk ou autre... ou sur un autre système.
Comme le disait @Tchize_, si le contrat de la méthode ne spécifie rien, on doit partir de principe qu'il n'y a pas d'ordre garanti.

Salut,

Je suis d'accord avec toi, d’ailleurs j'ai dis "oui actuellement ....." (Le JDK du moment 7)
Mon affirmation est fondée sur une analyse du code actuel ainsi que sur des tests. Si tu as bien compris le problème, ici on parle bien d'un itemListener d'un JToggleButton en passant par ToggleButtonModel..... Je ne parlais pas de quelque chose de générique.
29/09/2013, 21h45
tchize_

Bon, déjà, si tu regarde bien le code, listenerList, c'est pas une ArrayList. C'est une classe interne en sun.quelquechose. Pour le même prix ca te retourne des trucs dans le désordre, trie par ordre naturel ou dans l'ordre inverse ou ça dépend des phase lunaire. On n'est sais rien.

Ensuite, si tu regarde le code dans openjdk, c'est déjà plus le même code. Si tu regarde la jvm version apple, c'est encore autre chose. Etc etc.

On ne peux rien conclure. Tout ce qu'on risque de produire, c'est une code qui tombe en marche.
30/09/2013, 12h07
sinok

@Tchize, par sûr que ce soit une classe sun.*

Plutôt une EventListenerList

Citation:

Envoyé par sinok

@Tchize, par sûr que ce soit une classe sun.*

Plutôt une EventListenerList

oui, et qui justement envoit les évenements dans l'ordre inverse (j'avais regardé dès le début) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
protected void fireStateChanged() {
        // Guaranteed to return a non-null array
        Object[] listeners = listenerList.getListenerList();
        // Process the listeners last to first, notifying
        // those that are interested in this event
        for (int i = listeners.length-2; i>=0; i-=2) {
            if (listeners[i]==ChangeListener.class) {
                // Lazily create the event:
                if (changeEvent == null)
                    changeEvent = new ChangeEvent(this);
                ((ChangeListener)listeners[i+1]).stateChanged(changeEvent);
            }          
        }
    }

Mais tous ces échanges montrent bien pourquoi la compréhension du code ne doit pas servir à déduire une implémentation en amont, mais seulement pour comprendre le fonctionnement courant éventuellement.

30/09/2013, 13h27
awane

@Tchize
@joel.drigo

Bien entendu, je retiens :)
30/09/2013, 17h07
Népomucène

@Modulpro
Ta question était seulement une demande de confirmation de comportement de la JVM
ou bien tu as aussi un besoin réel que tes itemListeners s’exécutent dans un ordre précis ?
05/10/2013, 23h02
Modulpro

Bonjour et merci pour vos réponses, désolé de répondre si tard,

Si je résume ce que j'ai compris, l'implémentation actuelle confirme bien les résultats que j'ai obtenu MAIS rien ne garanti que ça n'évolue pas, donc je ne peux pas utiliser ces résultats

Citation:

Envoyé par Népomucène

@Modulpro
Ta question était seulement une demande de confirmation de comportement de la JVM
ou bien tu as aussi un besoin réel que tes itemListeners s’exécutent dans un ordre précis ?

En fait j'ai un conteneur avec plusieurs JToggleButtons dessus. Certains ont déjà été associés à un listener lors de leur création, d'autres non. Pour définir un comportement par défaut, j'ai surchargé la méthode add du conteneur, pour associer un listener à chaque JToggleButton qui est ajouté. Ainsi ceux qui avaient déjà un listener en ont deux, mais c'est le premier qui est appelé en dernier (c'est ce que je cherche, le comportement par défaut est alors "ignoré")

Au vu de vos réponse, (encore une fois, c'est en vous exposant le problème que la solution m'a paru évidente), je ne vais affecter le listener par défaut qu'aux JToggleButtons qui n'en possèdent pas déjà un, en testant le nombre d'éléments renvoyé par AbstractButton.getItemListeners()
06/10/2013, 00h03
tchize_

Citation:

Envoyé par Modulpro

, je ne vais affecter le listener par défaut qu'aux JToggleButtons qui n'en possèdent pas déjà un, en testant le nombre d'éléments renvoyé par AbstractButton.getItemListeners()

Mauvaise idée, aussi. Tu ne peux pas prévoir combien de listener il y à là dedans. En interne, swing enregistre aussi des listenres (que ce soit pour changer ,l'icone, l'apparence, etc)

Vu que tu as déjà affecté des listener à certains boutons, c'est qu'il sont créés différement des autres. C'est à cet endroit là qu'il faut différencier le comportement et rajouter un else addListener(defaultListener)