juin
2006
Un article de adiGuba
Les applications Java de type « desktop » souffre d’un gros défaut : elles ne s’intègrent pas facilement dans l’environnement du système d’exploitation. Je ne parle pas ici de l’apparence de l’application, puisqu’on peut très facilement utiliser le LookAndFeel du système d’exploitation, mais plutôt de son interaction avec le système et les autres applications…
Bien souvent, pour effectuer des opérations toutes simples avec des API systèmes spécifique, il faut soit passer par des librairies tierces, soit utiliser du code natif avec JNI. Avec toute la difficulté que cela peut engendrer…
La prochaine version de Java devrait corriger certains de ces problèmes…
On a ainsi put découvrir il y a quelques temps l’existence d’une API pour afficher une icône dans la zone de notification du système (les icônes à coté de l’horloge sous Windows) : New System Tray Functionality in Mustang.
Aujourd’hui, le portail SDN nous présente une nouvelle API permettant d’appeler le navigateur ou le logiciel de messagerie par défaut du système, et d’ouvrir un fichier avec son application associé : Using the Desktop API in Java SE 6 (Mustang).
Toutefois, derrière ces API sommes toutes banales, on peut voir un changement assez important dans la politique de Sun concernant Java. En effet, les deux principales classes de ces APIs comportent une méthode indiquant si le système supporte ou pas la fonctionnalité : SystemTray.isSupported() et Desktop.isDesktopSupported().
Cela implique qu’il reste à la charge du développeur d’utiliser un système alternatif si le système d’exploitation ne supporte pas ces notions.
Pourquoi un changement ? Tout simplement parce que je ne pense pas que ces API aurait été intégré en standard il y a quelques années, puisque Sun voulait que le fonctionnement des applications Java soit 100% identiques d’un système à l’autre. AWT a d’ailleurs été largement limité pour répondre a ce besoin (c’est à dire que les fonctionnalités qui n’était pas disponibles sur les principaux systèmes n’étaient pas utilisée). Or ce n’est plus le cas ici puisque le développeur doit gérer la présence (ou non) de tel ou tel fonctionnalité…
Il semble désormais que Sun aurait mis de l’eau dans son vin, et finalement c’est une bonne chose…
Note : Pour ceux que cela intéresse, ces fonctionnalités proviennent du projet JDIC, qui peut être utilisé en tant que librairie externe…
1 Commentaire + Ajouter un commentaire
Tutoriels
Discussions
- Classes, méthodes private
- Recuperation du nom des parametres
- Possibilité d'accéder au type générique en runtime
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- jre 1.5, tomcat 6.0 et multi processeurs
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- [ fuite ] memoire
- Définition exacte de @Override
- Difference de performances Unix/Windows d'un programme?
J’imagine également que la plupart des systèmes d’exploitation gèrent désormais ces fonctionnalités. (linux, mac, windows)