Nous avons notre propre thread "event loop" qui centralise les accès à dbus. On s'arrange pour ne pas faire de traitements trop longs dedans, seulement distribuer les évènements vers d'autres threads.
Il s'agit d'un thread Java qui appelle via JNI les fonctions de la libdbus native, ce qui fait qu'on a peu de code natif à maintenir.
Utiliser GDBus nous aurait contraint à une boucle d'évènement native basée sur la GLib, et du coup à faire beaucoup plus de choses en C ou C++ (langages que j'apprécie beaucoup, mais là on parle d'un projet en Java). Avec JNIDbus, un projet Java peut utiliser DBus sans avoir besoin d'ajouter aucun code natif et de façon plutôt confortable (puisque les messages sont automatiquement convertis en objets Java). Je ne suis pas certain qu'on serait arrivé à la même chose avec une boucle d'évènement native, je pense que chaque application aurait nécessité d'intervenir dessus et du coup on ne pourrait pas vraiment dire que c'est une API Java s'il faut écrire du JNI pour s'en servir.
[^] # Re: libdbus et multithreading
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Communiquer avec D-Bus en Java avec JNIDBus. Évalué à 3.
Nous avons notre propre thread "event loop" qui centralise les accès à dbus. On s'arrange pour ne pas faire de traitements trop longs dedans, seulement distribuer les évènements vers d'autres threads.
Il s'agit d'un thread Java qui appelle via JNI les fonctions de la libdbus native, ce qui fait qu'on a peu de code natif à maintenir.
Utiliser GDBus nous aurait contraint à une boucle d'évènement native basée sur la GLib, et du coup à faire beaucoup plus de choses en C ou C++ (langages que j'apprécie beaucoup, mais là on parle d'un projet en Java). Avec JNIDbus, un projet Java peut utiliser DBus sans avoir besoin d'ajouter aucun code natif et de façon plutôt confortable (puisque les messages sont automatiquement convertis en objets Java). Je ne suis pas certain qu'on serait arrivé à la même chose avec une boucle d'évènement native, je pense que chaque application aurait nécessité d'intervenir dessus et du coup on ne pourrait pas vraiment dire que c'est une API Java s'il faut écrire du JNI pour s'en servir.