Communiquer avec D-Bus en Java avec JNIDBus

Avec mes collègues chez Viveris, on s’est dit qu’on aimerait bien faire plus de logiciel libre. On a donc monté un « groupe opensource » dont le but est d’identifier les projets pour lesquels on peut publier tout ou une partie du code sous licence libre, et aussi de contribuer aux outils et bibliothèques qu’on utilise le plus.

Il y a quelques mois je vous présentais QTestFramework, depuis on a également pu contribuer au dissecteur 0MQ pour Wireshark et un outil pour le boundary scan JTAG.

On vient de publier il y a quelques jours une bibliothèque Java pour communiquer en D-Bus.

Sommaire

• Contexte
  • D-Bus
  • JNI
  • Solutions existantes et leurs limitations
• JNIDBus
  • Historique
  • Utilisation

Contexte

D-Bus

D-Bus est un système de communication inter-processus utilisé sous GNU/Linux. Le projet a été lancé par des développeurs de Red Hat au sein de Freedesktop. Il a été intégré dans GNOME 2 et KDE 4, et aujourd’hui il est utilisé par de très nombreux composants d’un système GNU/Linux : systemd, NetworkManager et PulseAudio, par exemple. Il y a même une implémentation dans le noyau Linux lui‑même.

JNI

JNI (Java Native Interface) est une API qui permet d’interfacer du code tournant dans une machine virtuelle Java avec du code natif. Cela nécessite d’écrire (en C ou C++) des wrappers qui vont manipuler la pile de la JVM pour récupérer les arguments et pousser les valeurs de retour, et éventuellement accéder aux objets Java manipulés. Les méthodes ainsi implémentées peuvent ensuite être appelées depuis le code Java de façon transparente.

Solutions existantes et leurs limitations

Freedesktop propose DBus-Java, mais il n’y a pas eu de version publiée depuis 2009. La dernière version a besoin de Java 7 pour fonctionner. De plus, cette bibliothèque implémente le protocole D-Bus en Java, ce qui risque de poser des problèmes d’interopérabilité avec l’implémentation en C.

Il existe bien une version mise à jour de la bibliothèque qui corrige au moins le premier problème, cependant l’API n’utilise pas les nouvelles fonctionnalités de Java et c’est bien dommage.

JNIDBus

Historique

Dans le cadre d’une migration d’un de nos logiciels depuis Java 7, nous avons découvert que DBus-Java ne prenait pas en charge les versions plus récentes. Nous aurions pu nous contenter d’une mise à jour de cette implémentation, mais il y avait beaucoup de code à reprendre dedans et de toute façon, l’API ne nous convenait pas.

En effet, dbus-java représente les messages D-Bus par des « tuples » génériques, ce qui est assez peu pratique à utiliser et rend le code illisible. De plus, les API sont bloquantes et cela nous contraignait à utiliser une réserve (pool) de fils d’exécution qui complexifiait encore le logiciel.

L’ensemble des ces défauts et l’absence d’alternative viable nous ont poussé à développer notre propre alternative, en essayant de répondre a toutes les problématiques.

Afin de ne pas réimplémenter le protocole D-Bus nous voulions utiliser la bibliothèque libdbus-1. L’écosystème Java possède deux manières d’appeler du code natif : JNI et JNA, ce dernier étant écarté pour des raisons de performances et de complexité des bibliothèques de liaison (bindings) à écrire.

Enfin, la dernière contrainte était de réduire le code natif au strict minimum, afin de limiter la complexité de ce dernier qui est très difficile à tester unitairement.

Utilisation

La base de JNIDBus est la sérialisation d’objet Java. La signature du message est décrite dans une annotation.

Exemple pour un message contenant une chaîne de caractères et un entier :

@DBusType(
    /* Pour plus d’info sur le format de la signature, référez vous
     * à la documentation D-Bus
     */
    signature = "si",

    /* Donne le nom des propriétés contenant les données du message,
     * dans notre cas la chaîne de caractères est contenue dans la
     * propriété nommée « string » et l’entier dans le champs « integer »
     */
    fields = {"string","integer"}
)
public class StringMessage extends Message {
    /* Les champs seront accédés au travers de ses setters et
     * getters qui devront respecter la convention "setXxx"/"getXxx"
     */
    private String string;
    private int integer

    public String getString() { ... }
    public void setString(String string) { ... }

    public int getInteger() { ... }
    public void setInteger(int string) { ... }

}

L’appel de méthodes distantes est transparent grâce a l’utilisation de proxy Java, il suffit de décrire l’interface de l’objet et de donner le nom de son bus pour pouvoir l’appeler. Toute méthode distante retourne un PendingCall auquel on doit attacher un listener pour être notifié de l’arrivée du résultat.

JNIDBus permet également d’exposer des méthodes distante par le biais de handlers. Un handler est simplement une classe annotée décrivant et implémentant les méthodes distantes, les signatures sont inférées grâce aux types d’entrées et de sorties. Les handlers seront exécutés dans la boucle d’évènements, il est donc primordial d’éviter tout appel bloquant ou toute tâche lourde. Afin de tout de même pouvoir effectuer ces tâches lourdes, les handlers gèrent un type de retour asynchrone (Promise).

Exemple d’un handler pour un signal et un appel :

@Handler(
    /* pour plus d’information référez vous à la documentation D-Bus
     */
    path = "/some/object/path",
    interfaceName = "some.dbus.interface"
)
public class SomeHandler extends GenericHandler {
    @HandlerMethod(
        //le nom exposé a D-Bus peut être différent du nom de la méthode Java
        member = "someSignal",
        type = HandlerType.SIGNAL
    )
    //Ici notre signal n’a aucun paramètre, on utilise donc le singleton EmptyMessage
    public void someSignal(Message.EmptyMessage emptyMessage) { ... }

    @HandlerMethod(
        member = "stringSignal",
        type = HandlerType.METHOD
    )
    public SomeOutput someCall(SomeInput input) { ... }
}

Comment enregistrer le handler auprès de D-Bus :

//connection au bus
Dbus receiver = new Dbus(BusType.SESSION,"my.bus.name");
//instanciation
SomeHandler handler = new SomeHandler();
//ajout, JNIDBus lancera une exception si le handler n’est pas valide
this.receiver.addHandler(handler);

Le langage Kotlin est pris en charge par le biais d’un artefact Gradle supplémentaire définissant des extensions qui suspendent l’appel de fonction et offrant la possibilité d’avoir des handlers qui facilitent la mise en place de cette suspension :

//il faut enregistrer la classe qui se chargera d’invoquer les méthodes qui suspendent
KotlinMethodInvocator.registerKotlinInvocator()

@Handler(path = "...", interfaceName = "...")
class CallHandler : KotlinGenericHandler() {

    @HandlerMethod(member = "suspendingCall", type = MemberType.METHOD)
    suspend fun suspendingCall(emptyMessage: Message.EmptyMessage): SingleStringMessage {
        //coroutines are awesome
        delay(2000)
        return SingleStringMessage().apply { string = "test" }
    }
}

Aller plus loin

• Projets opensource chez Viveris (73 clics)
• JNIDBus sur GitHub (55 clics)
• D-Bus sur Wikipédia (37 clics)