Simplifier l'écriture des listeners avec EventHandler

Version imprimable

03/07/2012, 10h45
le y@m's

Simplifier l'écriture des listeners avec EventHandler

Bonjour,

Je viens d'écrire un petit article qui présente la classe EventHandler permettant de simplifier l'écriture de listeners.
:arrow: Simplifier l'écriture des listeners avec EventHandler.

Bonne lecture.

le y@m's
03/07/2012, 10h59
Gueritarish

Merci pour cet article le y@m's :ccool:
03/07/2012, 13h26
deathness

Il y a là un avantage esthétique évident, mais j'avoue que je préfère personnellement éviter de telles surcouches juste pour cette raison.

En effet si le code est destiné a être maintenu par d'autre, j'ai personnellement eu la douleur d'avoir à gérer/comprendre de nombreuses surcouches "inutiles".
03/07/2012, 14h00
Robin56

Comme il a été mentionné en introduction, la raison n'est pas que purement esthétique.
03/07/2012, 14h11
le y@m's

Citation:

Envoyé par deathness

Il y a là un avantage esthétique évident, mais j'avoue que je préfère personnellement éviter de telles surcouches juste pour cette raison.

En effet si le code est destiné a être maintenu par d'autre, j'ai personnellement eu la douleur d'avoir à gérer/comprendre de nombreuses surcouches "inutiles".

En plus de la lisibilité (qui est bien plus que de l'esthétique, surtout quand on maintient du code), la création des listeners avec la classe EventHandler permet aussi de réduire l'empreinte disque et mémoire de son application (particulièrement avec les grandes applications).

J'ai moi aussi fait beaucoup de maintenance de code et la lisibilé, avec la documentation, est un critère primordial. En fait je dirais que le cas de la maintenance de code est le meilleur argument pour l'utilisation de l'EventHandler.

Tu parles de la douleur de maintenir du code avec beaucoup de couches inutiles, ce que je comprends, mais là la "surcouche" est très faible. On est loin d'un gros framework nécessitant plusieurs heures d'apprentissage, c'est une simple classe standard de type factory appréhendable en 5 min grace à notre amie la javadoc.
Le gain de lisibilité (déjà maintenu des classes de plusieurs milliers de lignes avec plusieurs dizaines de classes anonymes, c'est assez douloureux aussi :mouarf:) est quand même très largement supérieur au "coût" ;).
03/07/2012, 14h48
Uther
A noter qu'avec java 8 ça sera faisable bien plus proprement et efficacement grâce aux références de méthode.

Pour reprendre un exemple du tuto:
Code:

1 2 3 4 5 6 7 button.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { helloworld.sayHello(); } });
Deviendra :

Code:

button.addActionListener(helloworld::sayHello);
04/07/2012, 13h15
hwoarang

Merci pour l'article, ca peut etre interessant. Concernant la lisibilité, je pense qu'il suffit de regarder le code pour comprendre comment ca marche. Quoique en lisant l'article, le passage de parametres ne me parait pas tres intuitif. Ceci dit, ca rend le code plus concis, ce qui est bien.
En revanche, on parle d'empreinte mémoire mais on parle bien du jar généré, non ? Si oui, il faudrait voir l'efficacité à l'execution et l'impact sur la consommation de mémoire. C'est efficace à ce niveau la ?

Citation:

Envoyé par Uther

A noter qu'avec java 8 ça sera faisable bien plus proprement et efficacement grâce aux références de méthode.

Ca commence a ressembler à du C++/Csharp. Bref, ce qui voulait etre évité lors de la création du langage, ca, non ?
04/07/2012, 13h27
Uther

En effet, la Java a toujours souhaité éviter certaines fonctionnalités dangereuses du C++ comme les goto, l’héritage multiple, ... Mais il ne me semble pas que Java ait jamais explicitement refusé les références de méthode.

En tout cas par rapport aux classes anonymes et à l'introspection, ça devrait être carrément plus avantageux autant en terme de performances que de lisibilité.
04/07/2012, 13h55
le y@m's

Citation:

Envoyé par hwoarang

En revanche, on parle d'empreinte mémoire mais on parle bien du jar généré, non ? Si oui, il faudrait voir l'efficacité à l'execution et l'impact sur la consommation de mémoire. C'est efficace à ce niveau la ?

Le gain se fait et sur l'empreinte mémoire et sur la taille du jar.

En effet, en utilisant des classes anonymes, chaque classe donnera un fichier .class supplémentaire (du genre MaClasse$1.class, MaClasse$2.class, etc.). On aura donc autant de .class suplémentaires que de classes anonymes. Cela augmente donc la taille du jar.

Ensuite toutes ces classes doivent être chargées par la jvm pour pouvoir ensuite être instanciées. Cela augmente donc l'empreinte mémoire.

En utilisant l'EventHandler, les classes sont construitent dynamiquement via un proxy, il n'y a donc pas de fichier .class supplémentaire dans le jar.
Ensuite une seule classe est créée (et donc chargée en mémoire) par type de listener ce qui diminue l'empreinte mémoire.

Je n'ai fait aucune mesure pour quantifier le gain. Il est cependant clair qu'il est minime pour de petites applications mais que plus le nombre de listeners augmente, plus il sera significatif ;).
04/07/2012, 15h53
hwoarang

Citation:

Envoyé par Uther

En effet, la Java a toujours souhaité éviter certaines fonctionnalités dangereuses du C++ comme les goto, l’héritage multiple, ... Mais il ne me semble pas que Java ait jamais explicitement refusé les références de méthode.

J'ai failli le dire (mais je me suis censuré) : A quand le goto en java ? :aie:

Citation:

Envoyé par le y@m's

En utilisant l'EventHandler, les classes sont construitent dynamiquement via un proxy, il n'y a donc pas de fichier .class supplémentaire dans le jar.
Ensuite une seule classe est créée (et donc chargée en mémoire) par type de listener ce qui diminue l'empreinte mémoire.

Autant pour le jar, ca me parait normal, autant ca m'etonne qu'une instance ne soit pas créé à chaque utilisation de l'EventHandler. C'est sur, ca ? Parce que ca suppose qu'on doit trainer des references de tous les objets sur lesquels on a mis un listener pour bien router... Ca me parait compliqué (surtout qu'il y a des risques de garder des references sur des objets que le GC ne collectera plus)...

Citation:

Envoyé par hwoarang

Autant pour le jar, ca me parait normal, autant ca m'etonne qu'une instance ne soit pas créé à chaque utilisation de l'EventHandler. C'est sur, ca ? Parce que ca suppose qu'on doit trainer des references de tous les objets sur lesquels on a mis un listener pour bien router... Ca me parait compliqué (surtout qu'il y a des risques de garder des references sur des objets que le GC ne collectera plus)...

Il ne s'agit pas des instance des listeners (il y en a forcément une par listener) mais des classes elle même, des implémentations.

Soit le code suivant
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 ActionListener al1 = new ActionListener() { @Override public void actionPerformed(ActionEvent e) { action1(); } }; ActionListener al2 = new ActionListener() { @Override public void actionPerformed(ActionEvent e) { action2(); } }; System.out.println(al1.getClass()); System.out.println(al2.getClass());
qui affiche quelque chose comme :

Citation:

class test.Test$1
class test.Test$2

Il y a bien deux classes différentes.

Maintenant avec
Code:

1 2 3 4 ActionListener al1 = EventHandler.create(ActionListener.class, this, "action1"); ActionListener al2 = EventHandler.create(ActionListener.class, this, "action2"); System.out.println(al1.getClass()); System.out.println(al2.getClass());
le résultat devient :

Citation:

class $Proxy0
class $Proxy0

Il n'y a plus qu'une seule classe ;).
C'est le nombre d'implémentation qui se limite à un par type de listener, pas le nombre d'instance de listener ;).
Or comme ces classes sont chargées par la jvm (instances de la classe Class<?>), on obtient donc bien une réduction de l'empreinte mémoire en réduisant ce nombre de classes.

04/07/2012, 17h57
hwoarang

Ok, j'avais pas pensé à ce gain. Ca doit pas etre enorme mais c'est toujours ca de pris. Si les performances ne sont pas impactées, ca peut servir en attendant java 8 :D
05/07/2012, 07h53
Uther

Citation:

Envoyé par hwoarang

J'ai failli le dire (mais je me suis censuré) : A quand le goto en java ? :aie:

Le goto existe déjà plus ou moins avec les break sur un label :zoubi: .

Java n'a rien contre intégrer des nouvelles fonctionnalités si elles ne posent pas de problème particulier.
Dans le cas des Références de méthodes, les deux alternatives que sont les classes anonymes et l'introspection sont à la fois plus couteuses en ressources, carrément moins lisibles et source de complexité supplémentaire. Il n'y a pas vraiment de raison de s'y opposer.

Citation:

Envoyé par hwoarang

Ok, j'avais pas pensé à ce gain. Ça doit pas être énorme mais c'est toujours ça de pris. Si les performances ne sont pas impactées, ça peut servir en attendant java 8 :D

Les performances sont impactées car un appel de méthode par introspection est plus lent qu'un appel direct.

A voir si le plus important est la consommation mémoire ou la vitesse de déclenchement des action.

De toute façon dan les deux cas, il est fort probable que la différence ne se remarquera pas.
05/07/2012, 09h20
hwoarang

Citation:

Envoyé par Uther

Dans le cas des Références de méthodes, les deux alternatives que sont les classes anonymes et l'introspection sont à la fois plus couteuses en ressources, carrément moins lisibles et source de complexité supplémentaire. Il n'y a pas vraiment de raison de s'y opposer.

Bah comme raison, je vois au moins la logique du tout objet. Mais bon, je suis d'accord que c'est un débat philosophique plus que technique. Débat qui a d'ailleurs probablement eu lieu lors de la sortie de la premiere version de java (puisque les pointeurs de fonction existaient deja depuis longtemps) et qui a été tranché en faveur des classes anonymes (à l'évidence). Mais bon, on a le droit de changer d'avis. Surtout que comme tu le dis, ca simplifie l'ecriture et la relecture. De plus, des langages plus recents l'utilisent (par exemple csharp)...

Citation:

Envoyé par Uther

DLes performances sont impactées car un appel de méthode par introspection est plus lent qu'un appel direct.

Ca impacte le moment ou on ajoute le listener, ca, c'est sur. Par contre, pour l'execution (qui est à mes yeux le plus important), c'est moins sur. A la lecture de l'article, je dirais que ca a un impact négatif vu comment sont utilisés les parametres. Mais comme précisé, ca doit pas non plus beaucoup jouer...
05/07/2012, 10h18
thelvin

Un petit problème avec ce EventHandler, c'est que du coup le compilateur ne vérifie pas si la méthode "foo" existe. L'erreur se verra à l'exécution, pas à la compilation.

Raison de plus d'y préférer les références de méthode, mais bon, face à l'horreur des classes anonymes, je crois que ce petit défaut sera facilement accepté.
05/07/2012, 11h58
Uther

Citation:

Envoyé par hwoarang

Bah comme raison, je vois au moins la logique du tout objet. Mais bon, je suis d'accord que c'est un débat philosophique plus que technique.

En effet, d'ailleurs la solution retenue pour le références de méthode a pris soin de rester compatible avec la philosophie (presque)tout objet, car la référence de méthode est convertie implicitement en objet au final.

Citation:

Envoyé par hwoarang

Ça impacte le moment ou on ajoute le listener, ca, c'est sur. Par contre, pour l'execution (qui est à mes yeux le plus important), c'est moins sur. A la lecture de l'article, je dirais que ca a un impact négatif vu comment sont utilisés les parametres. Mais comme précisé, ca doit pas non plus beaucoup jouer...

De ce que je comprend, l'introspection intervient au moment du déclenchement de la méthode des listeners, c'est pourquoi ça peut avoir un impact non négligeable dans des cas où il se déclencherait extrêmement souvent.
D'après un petit test fait chez moi un method.invoke() est 30 fois plus lent qu'un appel classique
05/07/2012, 13h51
hwoarang

Citation:

Envoyé par thelvin

Un petit problème avec ce EventHandler, c'est que du coup le compilateur ne vérifie pas si la méthode "foo" existe. L'erreur se verra à l'exécution, pas à la compilation.

J'ajouterais que pour les feignants (comme moi), c'est plus compliqué de suivre le code (on peut pas faire F3 dans Eclipse) :)

Citation:

Envoyé par Uther

D'après un petit test fait chez moi un method.invoke() est 30 fois plus lent qu'un appel classique

J'ai jamais fait de test mais j'aurais pas pensé que c'etait si lent 8O
Je m'attendais à ce que la création de l'objet Method ne soit pas super rapide mais une fois créé, j'aurais pensé que l'invocation ne serait pas lente...
En tout cas, merci pour l'info je garderais ca en tete au besoin...
05/07/2012, 14h14
le y@m's

Citation:

Envoyé par Uther

D'après un petit test fait chez moi un method.invoke() est 30 fois plus lent qu'un appel classique

Je ne sais pas comment tu as fait ton test mais je n'ai absolument pas autant de différence.
Pour un traitement de 100ms, l'invocation par classe anonyme est de 100ms et avec l'EventHandler 120ms.
Pour un traitement de 200ms, l'invocation par classe anonyme est de 100ms et avec l'EventHandler 220ms.
Donc le surcoût est relativement faible.
Tu n'aurais pas fait une boucle par hasard ? (dans ce cas effectivement c'est normal que la différence soit si grande)

Citation:

Envoyé par hwoarang

J'ai jamais fait de test mais j'aurais pas pensé que c'etait si lent 8O
Je m'attendais à ce que la création de l'objet Method ne soit pas super rapide mais une fois créé, j'aurais pensé que l'invocation ne serait pas lente...
En tout cas, merci pour l'info je garderais ca en tete au besoin...

Ce qui compte c'est l'expérience utilisateur. Même un x30 peut ne pas être un problème.
Une invocation de 10ms, avec un facteur de x30 devient 300ms. Cela peut rester acceptable pour un clic bouton.
Tout dépendant de l'utilisation, il ne faut pas avoir peur d'allonger un peu un temps d'exécution si celui-ci reste acceptable (non perçu par l'utilisateur, en dessous de limites contractuelles, etc.).
05/07/2012, 14h15
Uther

Citation:

Envoyé par hwoarang

Je m'attendais à ce que la création de l'objet Method ne soit pas super rapide mais une fois créé, j'aurais pensé que l'invocation ne serait pas lente...

Avec la création de l'objet Method on passe à environ 300 fois plus lent ;)

Citation:

Envoyé par Uther

Avec la création de l'objet Method on passe à environ 300 fois plus lent ;)

Oui mais pourquoi tu crées un objet Method ?
Ce n'est pas ce que va faire l'EventHandler. L'EventHandler va se servir des string pour récupérer les méthodes sur les objets (target pour l'action et event pour la propriété).

Fait le test en comparant vraiment ce dont il est question (l'appel à la méthode du listener) ;).

Voici par exemple le code de mon test :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
public class Test {
 
    public void doAction(Object source) {
        try {
            Thread.sleep(200);
        } catch (InterruptedException ex) {
            Logger.getLogger(Test.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
 
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        final Test test = new Test();
        ActionListener al1 = new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                test.doAction(e.getSource());
            }
        };
        ActionListener al2 = EventHandler.create(ActionListener.class, test, "doAction", "source");
        ActionEvent evt = new ActionEvent(test, 0, null);
 
        long start = System.currentTimeMillis();
        al1.actionPerformed(evt);
        long elapsed = System.currentTimeMillis() - start;
        System.out.println("Anonymous, elapsed = " + elapsed);
 
        start = System.currentTimeMillis();
        al2.actionPerformed(evt);
        elapsed = System.currentTimeMillis() - start;
        System.out.println("EventHandler, elapsed = " + elapsed);
    }
}

05/07/2012, 14h27
Robin56

Citation:

Envoyé par thelvin

Un petit problème avec ce EventHandler, c'est que du coup le compilateur ne vérifie pas si la méthode "foo" existe. L'erreur se verra à l'exécution, pas à la compilation.

En effet, c'est l'un des points qui me bloque le plus dans son utilisation.
05/07/2012, 14h29
le y@m's

Citation:

Envoyé par Robin56

Citation:

Envoyé par thelvin

Un petit problème avec ce EventHandler, c'est que du coup le compilateur ne vérifie pas si la méthode "foo" existe. L'erreur se verra à l'exécution, pas à la compilation.

En effet, c'est l'un des points qui me bloque le plus dans son utilisation.

Je suis aussi d'accord avec ce point, c'est vrai que c'est un peu frustrant de se rendre compte à l'exécution qu'on a fait une faute de frappe dans le nom de la méthode (vive les tests unitaires :)).
05/07/2012, 14h30
Uther

Citation:

Envoyé par le y@m's

Je ne sais pas comment tu as fait ton test mais je n'ai absolument pas autant de différence.
...
Tu n'aurais pas fait une boucle par hasard ? (dans ce cas effectivement c'est normal que la différence soit si grande)

Ce que j'ai mesuré est seulement la différence 10 million d'appel à un invoke() et autant d'appels direct a la méthode pour se faire une idée générale de la différence de vitesse entre appel direct et introspection.

On est d'accord que si on fait des appels ponctuels à un traitement qui dépasse de toute façon quelques dizaines de millisecondes, ce qui sera généralement le cas, on se fiche royalement de la différence.

Citation:

Envoyé par le y@m's

Oui mais pourquoi tu crées un objet Method ?
Ce n'est pas ce que va faire l'EventHandler. L'EventHandler va se servir des string pour récupérer les méthodes sur les objets (target pour l'action et event pour la propriété).

Fait le test en comparant vraiment ce dont il est question (l'appel à la méthode du listener) .

C'était juste pour info, et c'est pour cela que je ne l'avait pas précisé à la base
Je me doute bien que le Event handler doit avoir déjà récupéré l'objet Method qu'il utilise lors de l'instanciation.
05/07/2012, 14h39
le y@m's

Citation:

Envoyé par Uther

Citation:

Envoyé par le y@m's

Je ne sais pas comment tu as fait ton test mais je n'ai absolument pas autant de différence.
...
Tu n'aurais pas fait une boucle par hasard ? (dans ce cas effectivement c'est normal que la différence soit si grande)

Ce que j'ai mesuré est seulement la différence 10 million d'appel à un invoke() et autant d'appels direct a la méthode pour se faire une idée générale de la différence de vitesse entre appel direct et introspection.

On est d'accord que si on fait un appel ponctuel à un traitement qui dépasse quelque centaines de millisecondes, ce qui sera généralement le cas, on se fiche royalement de la différence.

Ah je comprends mieux ta différence de temps d'exécution. Comme tu l'avais formulé ce n'était pas évident du tout que tu avais fait ton test dans une boucle. Ca laissait plutôt à penser qu'il s'agissait d'un simple appel, d'où mon étonnement :).

Donc oui avec une boucle il vaut mieux éviter l'utilisation de l'EventHandler, mais dans un cas d'utilisation simple la différence reste négligeable ;).
05/07/2012, 15h00
hwoarang

Citation:

Envoyé par le y@m's

Je ne sais pas comment tu as fait ton test mais je n'ai absolument pas autant de différence.
Pour un traitement de 100ms, l'invocation par classe anonyme est de 100ms et avec l'EventHandler 120ms.
Pour un traitement de 200ms, l'invocation par classe anonyme est de 100ms et avec l'EventHandler 220ms.
Donc le surcoût est relativement faible.
Tu n'aurais pas fait une boucle par hasard ? (dans ce cas effectivement c'est normal que la différence soit si grande)

Ce qui est interessant c'est de savoir la différence de temps d'execution entre un appel de fonction via l'EventHandler et via un appel direct. Et ca ne dépend pas du temps de traitement qui sera fait dans la fonction cible. Pour le tester, il faut effectivement faire une boucle.

Citation:

Envoyé par le y@m's

Ce qui compte c'est l'expérience utilisateur. Même un x30 peut ne pas être un problème.
Une invocation de 10ms, avec un facteur de x30 devient 300ms. Cela peut rester acceptable pour un clic bouton.
Tout dépendant de l'utilisation, il ne faut pas avoir peur d'allonger un peu un temps d'exécution si celui-ci reste acceptable (non perçu par l'utilisateur, en dessous de limites contractuelles, etc.).

Oui, on est d'accord. Et dans le cas de l'EventHandler, comme c'est une réaction à un evenement utilisateur, un temps de réaction de 5 ms ou de 150ms (valeurs prises au pif) ne fait pas une grosse différence. Mais dans un cas plus général, par rapport à la reflexion, c'est quand meme interessant à savoir qu'il y a une aussi grosse différence.
05/07/2012, 15h50
le y@m's

Citation:

Envoyé par hwoarang

Ce qui est interessant c'est de savoir la différence de temps d'execution entre un appel de fonction via l'EventHandler et via un appel direct. Et ca ne dépend pas du temps de traitement qui sera fait dans la fonction cible. Pour le tester, il faut effectivement faire une boucle.

Le test dépend de ton cas d'utilisation. Pour l'EventHandler le cas d'utilisation est justement de ne pas l'utiliser dans une boucle. Du fait de la reflexion on sait déjà qu'il y aura un surcoût pour chaque appel et donc que son utilisation dans une boucle est à proscrire. Donc ce n'est pas très utile de faire ce test puisqu'on sait déjà qu'on aura des perfs minables et qu'on ne choisira pas cette solution (EventHandler pour le cas d'une boucle).

Ce qui est interessant par contre c'est de connaitre le surcoût pour le cas d'utilisation, c'est à dire sur un appel simple ;).

Après on peut toujours faire le test avec une boucle mais bon ya pas vraiment de surprise ^^.

Fuseau horaire GMT +2. Il est actuellement 19h14.

Partenaire : Hébergement Web