Depuis que je programme intensivement en Java, il m'arrive régulièrement de pester contre certains comportements ou certaines limitations des API standards et notamment de Swing.
Et quand par curiosité, il m'arrive de vérifier, par exemple, la justification de l'une des limitations de Swing, je trouve la plupart du temps que celle ci est due à l'impossibilité de remettre en cause un choix effectué il y a près de 10 ans à la sortie de la première version.
Cela s'appelle la compatibilité ascendante et les développeurs de Java semblent lui vouer un culte depuis la toute première version du langage.
Le problème c'est qu'en informatique, les choses évoluent. Depuis la sortie de Java 1, des avancées du langage ont ainsi été sous utilisées :
- Depuis son arrivée (java 1.2), l'ArrayList aurait du remplacer le quasiment déprécié "Vector" dans les modèles par défaut fournis par Swing.
- Afin d'uniformiser les conventions de nommage Java qui se sont affinées au fur et à mesure des années, de nombreuses méthodes standards devraient encore être renommées
- L'utilisation de la généricité inclue depuis Java 5 permettrait de simplifier et de sécuriser beaucoup de code
- Certains comportements de certains widgets Swing sont incohérents mais ne peuvent pas être corrigés car de nombreux programmes externes en tiennent compte dans leur propre fonctionnement
...
Mais je ne me leurre pas. Java doit une grande partie de son succès dans le monde professionnel à cette fameuse compatibilité ascendante. C'est cette compatibilité qui rassure les décideurs sur la pérennité de leur investissement.
Aussi, j'ai accueilli assez favorablement la proposition de javalobby d'une API de compatibilité qui semble sur le papier réunir le meilleur des deux mondes : http://www.javalobby.org/java/forums/t88549.html
Maintenant, en lisant les blogs de certains développeurs de Sun, on réalise aussi la masse de tests supplémentaires pour valider une nouvelle version que ferait peser sur Sun ce type de fonctionnement.
Malgré tout, cela me semble un investissement absolument nécessaire pour permettre à Java de dépoussiérer son fonctionnement face à la frénétique plateforme .Net
samedi 27 janvier 2007
dimanche 7 janvier 2007
Mise à jour de JIMS
Nous avons mis à jour assez récemment l'exemple en ligne de JIMS disponible sur le site web de JUMP Informatique.
Nous sommes assez content de cette nouvelle version dans l'équipe de développement de JUMP AMS car elle dévoile un peu plus le potentiel de la solution JIMS.
Elle permet aussi je pense de montrer qu'on peut faire des interfaces jolies et réactives en Java Swing, et même dans le cadre d'applets Java.
Sur nos machines de test, la mise à jour à la demande du graphique et la mise à jour automatique du tableau sont quasi instantanées.
L'exemple mis en ligne montre deux fonctionnalités
- Un graphique permettant la comparaison des performances de fonds face à des indices
- Un tableau permettant de simuler le rendement d'un placement
Théoriquement, l'exemple est censé marcher sur toute machine équipée d'une machine virtuelle Java de la version 5 ou supérieure. Si malgré cela elle ne se lance pas chez vous, n'hésitez pas à nous le signaler à contact@jump-informatique.com
Nous sommes assez content de cette nouvelle version dans l'équipe de développement de JUMP AMS car elle dévoile un peu plus le potentiel de la solution JIMS.
Elle permet aussi je pense de montrer qu'on peut faire des interfaces jolies et réactives en Java Swing, et même dans le cadre d'applets Java.
Sur nos machines de test, la mise à jour à la demande du graphique et la mise à jour automatique du tableau sont quasi instantanées.
L'exemple mis en ligne montre deux fonctionnalités
- Un graphique permettant la comparaison des performances de fonds face à des indices
- Un tableau permettant de simuler le rendement d'un placement
Théoriquement, l'exemple est censé marcher sur toute machine équipée d'une machine virtuelle Java de la version 5 ou supérieure. Si malgré cela elle ne se lance pas chez vous, n'hésitez pas à nous le signaler à contact@jump-informatique.com
lundi 1 janvier 2007
Différences entre la généricité en Java et en C#
Il est connu que, bien que très appréciée par de nombreux développeurs moi compris, l'implémentation de la généricité en Java 5 était pour le moins contestée.
En effet, contrairement à Microsoft avec .Net, Sun a fait le choix de ne pas créer de nouvelles instructions dans sa machine virtuelle pour gérer la généricité dans Java 5. Concrètement, les classes génériques écrites en C# sont instanciées au lancement du programme alors que Java se contente de placer des "Object" et d'ajouter des transtypages exécutables au runtime.
Résultat, en Java, la sacro sainte compatibilité binaire a pu être préservée mais les gains en performances (ajout de transtypages) et en nouvelles possibilités (perte du type original après la compilation) sont plus limitées qu'en C#.
Dans ces deux billets, Ted Neward, illustre certaines faiblesses fonctionnelles de l'implémentaion des génériques en Java. C'est assez technique voir un peu aride mais pour le moins intéressant :
- 1er billet
- 2ème billet
En effet, contrairement à Microsoft avec .Net, Sun a fait le choix de ne pas créer de nouvelles instructions dans sa machine virtuelle pour gérer la généricité dans Java 5. Concrètement, les classes génériques écrites en C# sont instanciées au lancement du programme alors que Java se contente de placer des "Object" et d'ajouter des transtypages exécutables au runtime.
Résultat, en Java, la sacro sainte compatibilité binaire a pu être préservée mais les gains en performances (ajout de transtypages) et en nouvelles possibilités (perte du type original après la compilation) sont plus limitées qu'en C#.
Dans ces deux billets, Ted Neward, illustre certaines faiblesses fonctionnelles de l'implémentaion des génériques en Java. C'est assez technique voir un peu aride mais pour le moins intéressant :
- 1er billet
- 2ème billet
Inscription à :
Articles (Atom)