De nombreux logiciels sont actuellement réalisés en Java. Cependant, et cela pose un problème vis-à-vis du but évoqué ci-dessus, ces logiciels font de plus en plus appel à des bibliothèques externes, pas forcément présentes chez les utilisateurs. Le premier exemple que j'ai rencontré était une version précédente du site de télédéclaration des impôts, qui demandait l'installation d'une bibliothèque spécifique de cryptographie dans un répertoire système...

Le toolkit graphique SWT est actuellement très à la mode. J'ouvre une parenthèse pour m'interroger sur cette incapacité de Java à se trouver un toolkit convenable : d'abord AWT, puis Swing, et maintenant la mode est à SWT ! Mais le plus gênant avec ce nouveau toolkit, c'est qu'il n'est pas livré par défaut avec Java, mais avec Eclipse. Aussi, celui qui veut distribuer un logiciel utilisant SWT doit-il le plus souvent distribuer également des versions de SWT pour les principales plate-formes.

Les choses peuvent encore s'aggraver. Le logiciel jUploadr utilise SWT, y compris des fonctionnalités récentes reposant sur la bibliothèque Cairo, par exemple pour la rotation des images. Si justement on essaye de tourner une image et que SWT-Cairo ne fonctionne pas, le programme se termine par une exception. Je regrette que les auteurs n'ont pas prévu un mécanisme de rattrapage pour ce problème qui semble se produire dans de nombreuses configurations.

Ma palme du coup tordu revient à ASM, qui nécessite pour être compilé Ant, mais attention, pas n'importe quelle version : pour une raison mystérieuse, une version trop récente provoquait des problèmes subtils.

Moralité ? Nous n'avons pas fini d'entendre parler des problèmes de bibliothèques dynamiques et du fameux syndrome « le logiciel A nécessite la bibliothèque L version 1.3, mais le logiciel B veut la version 1.4 et on ne peut pas installer sans contorsions à la fois la version 1.3 et la version 1.4 de L ».