22 novembre 2009

D’une JRE à l’autre

Le projet Mojo publie ce week-end les signatures des diverses JRE, à utiliser avec le plugin animal-sniffer.

Kezako-qu’est-ce-donc ?

Mine-sniffer-rat_1378314iAnimal Sniffer est un outil que l’on doit à Kosuke Kawaguchi, également créateur de Hudson et développeur chez SUN de JAXB et JAX-WS, enfin un gars bien occupé quoi. L’objectif de ce truc au nom improbable est de vérifier qu’un programme Java utilise uniquement des API qui seront disponibles au runtime.

 

Comme le compilateur javac vous autorise à cibler une JRE (option target) différente de celle qui compile, il n’est pas exclu d’utiliser des classes ou méthodes qui ne seront pas fournies par le runtime – gloups. Animal Sniffer va donc contrôler tout ça pour nous. On peut donc vérifier qu’on utilise pas de méthodes spécifiques au runtime Java6 en utilisant le compilo JDK6 et en ciblant Java 5 !

Mais animal Sniffer peut aller plus loin, car en pratique chaque JRE a ses petites extensions. Il est par exemple bien tentant d’utiliser la classe com.sun.binary.Base64, ce qui posera bien évidement quelques soucis si le runtime est un JRockit ou un IBM JDK !

Le projet Mojo est donc en train de nous publier les signatures de toutes les JRE, IBM JDK et Apache Harmony comprises, dans les versions courantes (1.3, 1.4, 5, 6).

Dans le même esprit, pour le développement d’un plugin Google App Engine sur Mojo (délaissé depuis, manque de temps et %#@! de SDK – contributions are welcome), j’ai utilisé animal sniffer et une signature spécifique pour valider la non-utilisation des API du JRE qui ne sont pas supportées sur cet environnement un peu particulier.

Super, mais encore ?

Prenons un instant pour nous intéresser au JDK7, “OpenJDK”. Contrairement aux précédentes version de Java, il n’est pas piloté par une JSR bien cadrée, mais vit sa vie en opensource, avec ce que ça implique d’innovations, mais aussi de conflits divers et de retards – encore 6 mois dans la vue :)

Alors qu’on pouvait en principe se baser sur la JSR Java6 pour définir les API accessibles, que fera t-on avec les implémentations de Java7 autres que OpenJDK ? Bien sur, elles sont sensées être compatibles, mais comment définir si un élément d’OpenJDK est une implémentation spécifique ou bien un élément officiel de la plateforme ?

Animal Sniffer pourra répondre à cela : en validant l’utilisation exclusive des API de l’environnement cible, il nous évitera un NoSuchMethodError qui fait bien mal sur le serveur de production.

2 commentaires:

ehsavoie a dit…

Est ce qu'une comilation avec le bon rt.jar ne te garantit pas la même chose (bon ok c'est pas super clean mais quand tu dois produire des artefacts différnts selon la JVM car tu fais du XML ....)

nicolas deloof a dit…

C'est la solution que j'utilisais jusqu'ici. Elle a l'inconvénient que tu dois toi même composer le bootclasspath de ton JDK cible, ce qui ne se réduit pas au rt.jar (sans parler des JDK sans rt.jar comme celui d'IBM)