OSHI : une bibliothèque Java pour interroger le système sans dépendances natives

Un besoin récurrent : interroger le système sans écrire de code natif

Tout développeur Java a un jour besoin de connaître la version de l'OS, le nombre de cœurs, la mémoire disponible ou la température du processeur. Le faire directement en Java est impossible sans passer par des appels natifs, et chaque plateforme a ses propres API. OSHI répond à ce problème en fournissant une interface unique qui masque les différences entre Windows, macOS, Linux et plusieurs variantes d'UNIX. La bibliothèque ne nécessite pas l'installation de bibliothèques natives supplémentaires, ce qui simplifie le déploiement. Elle s'adresse aux développeurs d'outils de supervision, de moniteurs système, de logiciels de diagnostic ou de jeux qui veulent afficher des statistiques matérielles.

Deux accès natifs, une même API

OSHI propose deux implémentations pour accéder aux informations natives. La première, oshi-core, utilise JNA (Java Native Access) et supporte JDK 8 et plus. La seconde, oshi-core-ffm, utilise l'API Foreign Function & Memory du JDK et exige JDK 25 ou plus. Les deux implémentations partagent les mêmes interfaces définies dans oshi-common. Vous pouvez donc écrire votre code une fois et choisir l'implémentation au moment de la compilation, ou inclure les deux et laisser OSHI sélectionner la meilleure au runtime via SystemInfoFactory.create(). Le tableau dans le README indique que si les deux sont présentes, l'implémentation FFM est choisie sur JDK 25+, sinon JNA. Cette séparation est un choix de conception qui permet de migrer progressivement vers FFM sans casser le code existant.

Une implémentation sans accès natif pour Linux et NetBSD

En plus des deux implémentations natives, oshi-common contient une troisième implémentation appelée oshi.nativefree. Elle lit uniquement les fichiers procfs, sysfs, sysctl et les sorties de commandes. Elle ne nécessite aucun accès natif, ce qui évite d'ajouter le flag --enable-native-access et élimine l'avertissement du JDK. Cependant, elle ne couvre que Linux et NetBSD. Si vous visez uniquement ces plateformes et que vous voulez une bibliothèque légère, cette option est intéressante. Mais elle ne convient pas pour Windows ou macOS, où il faudra utiliser une des implémentations natives.

Installation et premiers pas avec Maven ou Gradle

Pour utiliser OSHI, il suffit d'ajouter la dépendance oshi-core (ou oshi-core-ffm) à votre projet. Les dépendances transitives, y compris oshi-common et JNA, sont résolues automatiquement. Si vous gérez les JAR manuellement, le README recommande de télécharger l'archive oshi-dist attachée à chaque release, qui contient tous les JAR nécessaires. Après avoir ajouté la dépendance, vous créez une instance de SystemInfoProvider : SystemInfoProvider si = SystemInfoFactory.create();. Cette fabrique choisit automatiquement la meilleure implémentation selon votre classpath et votre JDK. Vous pouvez aussi instancier directement oshi.SystemInfo (JNA), oshi.ffm.SystemInfo (FFM) ou oshi.nativefree.SystemInfo. Ensuite, vous récupérez les composants : HardwareAbstractionLayer hal = si.getHardware(); CentralProcessor cpu = hal.getProcessor(); OperatingSystem os = si.getOperatingSystem();. Pour un rapport complet, le README suggère de cloner le dépôt et d'exécuter la méthode main de SystemInfoTest.

Configuration : oshi.properties et GlobalConfig

OSHI permet de configurer certains paramètres via le fichier oshi.properties, situé dans oshi-common/src/main/resources. Vous pouvez aussi manipuler ces paramètres via la classe GlobalConfig ou via les propriétés système Java. Le point important est que cette configuration doit être effectuée au démarrage. Le README est explicite : la configuration n'est pas thread-safe et OSHI ne garantit pas de relire la configuration pendant l'exécution. Si vous changez une propriété après le démarrage, le comportement est indéfini. Cela impose une discipline : centraliser la configuration au tout début du programme, avant toute création de SystemInfo. C'est une contrainte à connaître, surtout si vous développez une application modulaire où plusieurs composants pourraient vouloir ajuster les paramètres.

Limites et cas où OSHI n'est pas le bon choix

OSHI couvre un large éventail de fonctionnalités, mais il a des limites. La première est la couverture des capteurs : le README précise que les températures, vitesses de ventilateurs et tensions ne sont disponibles que sur certains matériels. Sur Windows, pour obtenir les informations de capteurs, il faut ajouter la dépendance optionnelle jLibreHardwareMonitor, dont les DLL sont sous licence MPL 2.0. Cette dépendance n'est pas incluse par défaut. Deuxième limite : l'implémentation nativefree ne fonctionne que sur Linux et NetBSD. Si vous devez supporter macOS, il faut utiliser JNA ou FFM. Troisième limite : la configuration n'est pas thread-safe, donc toute modification dynamique des paramètres est à proscrire. Enfin, si vous travaillez avec un JDK antérieur à 25, l'implémentation FFM est indisponible. Il faut alors rester sur JNA, qui supporte JDK 8 et plus. Pour des plateformes non listées (par exemple certains systèmes embarqués), OSHI ne fournit aucune garantie.

Alternative : écrire vos propres appels JNA ou utiliser des API natives

L'alternative principale à OSHI est d'écrire vos propres appels JNA ou FFM pour chaque plateforme. C'est plus de travail, mais cela vous donne un contrôle total sur les données récupérées et les coûts de performance. Par exemple, pour lire la température CPU sous Linux, vous pourriez lire directement le fichier /sys/class/thermal/thermal_zone0/temp. Pour les statistiques réseau, vous pourriez lire /proc/net/dev. Cette approche vous évite la couche d'abstraction d'OSHI, mais vous devez gérer les différences entre les distributions et les versions du noyau. OSHI automatise cette gestion, mais vous n'avez pas la main sur les détails d'implémentation. Une autre alternative est d'utiliser des bibliothèques spécifiques à une plateforme, comme JNA pour Windows, mais vous perdez la portabilité. Le choix dépend de votre besoin : si vous visez plusieurs plateformes avec une API unique, OSHI est pertinent ; si vous ne ciblez qu'un système précis et que vous voulez minimiser les dépendances, une solution maison peut suffire.

Maintenance et licence : un projet actif sous MIT

Le dépôt oshi/oshi est actif, avec une dernière mise à jour le 23 août 2026 et une release 7.6.0 publiée le même jour. Les versions 7.5.0 et 7.4.4 datent respectivement d'août 2026, ce qui montre un rythme de publication régulier. La licence MIT est permissive : vous pouvez utiliser, modifier et redistribuer la bibliothèque, y compris dans des projets propriétaires, à condition de conserver l'avis de copyright. Cependant, la dépendance optionnelle jLibreHardwareMonitor pour les capteurs Windows est sous MPL 2.0, ce qui impose des obligations différentes (notamment la disponibilité du code source des fichiers modifiés). Si vous utilisez cette dépendance, vérifiez vos obligations de conformité. Pour les mises à niveau, le README renvoie à un fichier UPGRADING.md qui détaille les changements de dépendances. Il est donc conseillé de consulter ce fichier avant de passer d'une version majeure à une autre. En résumé, OSHI est maintenu, mais vous devez rester attentif aux changements de configuration et aux éventuelles nouvelles exigences de JDK.

Conclusion éditoriale

OSHI convient aux développeurs Java qui ont besoin d'une API unique pour interroger le système sur plusieurs plateformes sans écrire de code natif. Ceux qui visent Java 25 et veulent éviter la dépendance JNA peuvent choisir oshi-core-ffm. Ceux qui travaillent uniquement sous Linux ou NetBSD et veulent une bibliothèque légère sans accès natif peuvent utiliser oshi-common avec l'implémentation nativefree. À l'inverse, si vous avez besoin de capteurs sur Windows, prévoyez la dépendance optionnelle jLibreHardwareMonitor et vérifiez sa licence MPL 2.0. Avant d'adopter, vérifiez que votre plateforme est dans la liste (Windows, macOS, Linux, UNIX), que votre JDK est compatible avec l'implémentation choisie (8+ pour JNA, 25+ pour FFM), et que la configuration via oshi.properties est faite au démarrage, car elle n'est pas relue pendant l'exécution.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes