De l'importance de "final" dans le SWT threading model

Ayant pourtant pas mal développé en Java, le threading model très contraignant de SWT m'aura fait découvrir une utilisation du mot clé "final" qui m'était jusqu'à présent totalement inconnue : la même que "const" en C/C++.

Pour ceux qui ne sont pas familiers avec SWT, le modèle de gestion des évènements est le suivant : 1 seul thread reçoit et traite les évènements de l'interface utilisateur. Rien de choquant en soit, sauf que :
- pendant le traitement d'un évènement, il n'y a plus aucun rafraichissement visuel de l'interface.
- ce thread est le seul à pouvoir accéder aux widgets utilisés.

Pour les traitements qui prennent du temps, vous vous dites : un simple curseur sablier pour "notifier" l'utilisateur qu'un traitement est en cours et le tour est joué (comme le ferait un développeur VB débutant). Et bien non, avec SWT c'est totalement insuffisant : si vous passez une autre fenêtre devant votre application à ce moment là, elle reste blanche et n'est pas redessinée ! Totalement inacceptable...la première chose qu'on se dit c'est que l'application est plantée... D'après mes "vieux" souvenirs, corrigez-moi si je me trompe, cette problématique est totalement inconnue des (chanceux) développeurs sous Visual Studio, mais aussi des développeurs Swing. Même si l'interface ne répond plus aux sollicitations de l'utilisateur inquiet, au moins son affichage reste correct.

La solution : le "fork", avec création d'un nouveau thread (et surtout d'un Runnable) qui s'occupera du traitement. Simple, sauf que...Comme il n'est pas le "UI thread", impossible d'appeler la moindre méthode sur les widgets. Bilan, on se retrouve donc avec 2 thread : 1 qui ne gère que l'affichage graphique, et l'autre qui ne peut effectuer que des traitements. Mais il faut bien que ces thread se passent mutuellements des données, sinon on ne va pas arriver à grand chose...

Vous avez donc 2 solutions : la première, vous créez explicitement une classe "Runnable" pour chaque échange. Ca, vous abandonnez rapidement, car ça devient vite ingérable, même pour une application très simple. La seconde, réflexe de développeur Java, vous créez à la volée une classe anonyme "Runnable", sauf que la méthode run() ne prend pas d'arguments et que votre compilateur favori ne vous laisse pas utiliser vos variables locales.

En regardant de plus près le message d'erreur, vous voyez que seules les variables "final" sont autorisées. Personnellement je me suis dit, qu'est-ce que viens faire "final" ici ? Ce n'est pas juste un mot clé pour empêcher la surcharge ou la dérivation ? Et bien non, dans le cas d'une variable non statique, cela indique simplement que fois initialisée elle n'est plus modifiable. Dans le cas de SWT qui nous intéresse, cela permet au compilateur de la rendre utilisable par le 2e thread.

Tout cela est certes un peu contraignant, mais au moins cela force le développeur a distringuer explicitement et correctement le traitement des données et la gestion pure de l'interface utilisateur.

Comments

Popular posts from this blog

3D, multi-core et kernel linux

VoIP, qualité sonore et pipeau marketing...

Le fourre-tout SWT