samedi 27 janvier 2007

Java 7 et la compatibilité ascendante

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

Aucun commentaire: