JSR 385 et Indriya

La lecture d'une documentation technique m'amenait cette semaine à découvrir la JSR 331 qui propose une API pour la modélisation des librairies de programmation par contrainte. Ce domaine a beau être l'un de mes centres d'intérêt, au point d'y consacrer le développement d'une librairie Java sur le sujet, je n'avais pas connaissance d'une quelconque démarche de standardisation. Même si le rachat de Sun Microsystems par Oracle en 2010 a quelque peu brouillé la gouvernance du JCP (Java Community Process), conduisant notamment la fondation Apache à en sortir cette même année, les JSR (Java Specification Request) restent le pilier de la standardisation des API du langage Java. Or le recours aux API standards est un facteur contribuant généralement (hélas pas toujours) à la pérennisation des développements. Il n'est donc jamais inutile de balayer les dernières JSR de temps en temps pour sentir les tendances :  https://www.jcp.org/en/jsr/all?sortBy=date

C'est en suivant le lien ci-dessus en ce samedi 25 mai, que je suis tombé sur la modification d'une JSR en date du vendredi 24 mai qui répond à un problème récurrent du développement d'applications scientifiques: la gestion des unités de mesure.

La JSR 385 est intitulée "Units of Measurement API 2.0". Là encore, la mention à une version 2.0 signifie que je suis passé à côté pendant plusieurs années d'une version 1.0 qui aurait pu m'intéresser. Dans le domaine des applications spatiales, il n'est en effet pas rare de devoir manipuler des mesures ou des "paramètres système" qui correspondent à des grandeurs physiques pour lesquelles des opérations mathématiques ou des conversions sont nécessaires. Il m'est ainsi bien souvent arrivé de redéfinir des concepts telles que "Quantity" ou "Unit" et de déclarer des constantes permettant de convertir des grandeurs physiques ou d'afficher des unités de mesure. Or, il s'agit bien de ce que propose cette API qui fait l'objet d'une implémentation de référence: Indriya (la référence à cette capsule intensité 10 de la marque Nespresso est intentionnelle; n'oublions jamais qu'un développeur est un processus biologique qui "transforme du café en code source").

Devant une telle opportunité, il était bien tentant de se laisser aller à une expérimentation de l'API et de son implémentation de référence. Lors des sessions de partage de bonne pratiques de codage que je dispense au sein de Capgemini, je vante les mérites du recours aux API standards; et pourtant, dans l'exemple que j'utilise pour illustrer les bonnes pratiques, je déclare des constantes de conversion d'unités et j'implémente moi-même ces conversions.

L'exemple qui est proposé est celui d'une horloge que l'on initialise avec un "timestamp" correspondant au nombre de secondes écoulées depuis minuit et avec laquelle on souhaite pouvoir lire les heures, minutes et secondes de l'horaire correspondant. La grandeur physique manipulée ici est celle du temps, grandeur qui est naturellement supportée par la JSR 385. Ci-dessous, un extrait du code de l'implémentation basée sur cette JSR et qui extrait les heures, minutes et secondes d'un horaire.

Exemple de POM pour utiliser la JSR 385 et son implémentation de référence

Illustration de l'usage de l'API JSR 385

L'exemple choisi n'est peut-être pas le meilleur pour illustrer l'intérêt de l'API et de son implémentation de référence. L'algorithme de conversion est en effet beaucoup plus complexe que les simples divisions et modulos nécessaires pour une conversion basée sur des constantes. Néanmoins, elle démontre qu'on peut effectivement abstraire la gestion de grandeurs physiques et expliciter les unités dans lesquelles les données sont manipulées. L'incident ayant causé la perte de la mission Mars Climate Observer que je prends comme exemple pour souligner l'importance d'expliciter les unités au niveau des interfaces montre que l'usage d'une telle API a un réel intérêt pour une mission scientifique.