Posts

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

3D, multi-core et kernel linux

La dernière édition de la Java Specialists' Newsletter [Issue 135] parle de la possibilité avec Java 5 de mesurer les cycles CPU alloués par thread. Le sujet est surement passionnant (si on fait de la programmation parallèle), mais c'est surtout l'anecdote racontée qui m'a plue : Un des geek présents fait le malin avec son portable dual-core et son bureau Linux à effets 3D. Ce sont 2 des sujets "chauds" du moment : la guerre des processeurs dual-core (maintenant qu'on commence à stagner en fréquence) et les bureaux 3D (ou comment Linux/OpenGL fout une belle claque à Vista/DirectX...pendant que MacOSX rigole doucement). Ils testent donc sur son poste le programme Java, et surprise, les performances sont celles d'un mono-core ! Par chance, un admin système est présent, jette un oeil sur la configuration et lui indique qu'il a oublié d'installer un kernel multi-processeur... Et oui, une telle anecdote, ça ne peut faire sourire qu'un geek dan

Le fourre-tout SWT

En plein développement de ma première application SWT, je ne suis pas vraiment dépaysé de Swing, mais après seulement quelques heures, j'ai déjà envie d'étriper celui qui a eu l'idée de mettre toutes les constantes dans une classe unique : org.eclipse.swt.SWT Je veux bien accepter (difficilement) que des méthodes prennent un simple int pour préciser un type d'objet, mais qu'au moins les types autorisés soient isolés dans une classe correspondante (bon, là c'est pas hyper clair, mais un exemple devrait aider). Si on considère la méthode notifyListeners, qui prend en argument un type d'évènement (int) et un évenement générique (Event), et bien il faut partir à la pêche dans la classe SWT pour trouver la bonne constante. Bilan : passage obligé par la doc :-( La 1e fois je me suis égaré en mettant un SWT.SELECTED au lieu de SWT.Selection... N'aurait pas été plus simple (et propre) d'utiliser une classe interne SWT.Event qui aurait contenu les diff

VoIP, qualité sonore et pipeau marketing...

ZDNet a publié récemment un article sur l'amélioration de la qualité sonore pour les communications VoIP ( VoIP: les opérateurs travaillent àl'amélioration de la qualité d'écoute - Actualités - ZDNet.fr ). En bref, ils nous disent : - la qualité en VoIP est moins bonne qu'en téléphonie classique. - les codecs G.711 et G.729 utilisés ne sont pas très bons. - les codecs "large bande" comme le G722 et le G.729.1 vont améliorer les choses. Ca tient difficilement la route ce raisonnement : notre bonne vieille téléphonie commutée utilise le G.711 (qui requiert 64kbit/s), et sa qualité convient parfaitement à tout le monde (étant donné qu'on le cite toujours comme référence). Quant au G.729, il est effectivement moins bon, mais est utilisé par certains FAI pour économiser de la bande passante : il ne consomme que 8kbit/s au lieu de 64. Et les fameux codecs large bande ? A part pour améliorer la qualité d'écoute des musiques d'attente des Hotline des F

i18n, Java et Eclipse

ou l'internationalisation en 3 clics. Après avoir pesté de si nombreuses fois contre la traduction incomplète de certaines applications, je décide de m'y mettre pour une nouvelle application SWT que je viens de commencer. Quelques minutes de recherche dans Google, et hop, un mini tutoriel chez Sun : A Quick Example (The Java™ Tutorials > Internationalization > Introduction) OK, c'est aussi simple que ce à quoi je m'attendais: une classe de ressources à écrire, les fichiers de traduction et hop, le tour est joué. Il reste quand même la tâche ingrate de mettre en place l'appel systèmatique aux ressources... Eclipse doit bien pouvoir gérer ça tout seul quand même ? Et oui ! L'item magique est dans le menu Source : "Externalize String". Le wizard trouve toutes les chaînes que vous avez codées en dur. Quelques clics pour choisir celles que vous voulez traduire (ou non) et Eclipse se charge du reste. Il ne reste plus qu'à écrire les fichiers

GreenSkol 2.0

Bon, promis, cette fois-ci c'est pour de bon ! J'avais bien tenté l'expérience du blog il y a quelques mois, mais ça avait vite tourné court. Trop de choses à faire surement...ou trop de flemme ! Cette fois-ci je m'y remet et je vais essayer de m'y tenir. J'espère que mes prochains messages seront plus intéressants que celui-ci (on peut difficilement faire plus inintéressant), mais bon, il faut bien commencer par quelque chose, mon arrivée à Toulouse mérite bien ça ;-)