Mozilla essaie de faire Java comme il aurait dû être, avec une spécification WASI pour tous les périphériques, ordinateurs et systèmes d’exploitation.
Mozilla a annoncé cette semaine un projet appelé WASI (WebAssembly System Interface) visant à normaliser l’interaction du code WebAssembly avec les systèmes d’exploitation. Si le projet réussit, il fera ce que fait la machine virtuelle Java d’Oracle, mais mieux et plus largement.
WebAssembly, ou WASM, est un format binaire pour une machine virtuelle pouvant s’exécuter sur plusieurs architectures matérielles. Le code WASM peut être produit à partir de divers langages de programmation tels que C/C++, Go et Rust en tant que cible de compilation.
WebAssembly a été adopté par tous les principaux navigateurs Web, mais il ne dispose pas encore d’un moyen standard de fonctionner en dehors du navigateur. C’est là que WASI entre en scène.
« Le code en dehors d’un navigateur nécessite un moyen de communiquer avec le système : une interface système », explique Lin Clark, ingénieur en logiciels chez Mozilla, dans un article de blog. « Et la plate-forme WebAssembly ne l’a pas encore. »
Quoi de neuf avec WASM ?
Avec WASI, le code WASM peut être exécuté dans le navigateur ou dans n’importe quel environnement conforme, ce qui permet un déploiement d’applications multiplateformes et agnostiques en langues. Là où l’interface POSIX (Portable Operating System Interface) permet de rendre le code source portable sur des systèmes d’exploitation de type Unix, WASI vise à rendre les fichiers binaires compilés portables sur tous les périphériques et systèmes d’exploitation. Il promet une exécution universelle à une vitesse presque native.
La machine virtuelle Java (JVM) a le même objectif, mais vous ne pouvez pas exécuter de code Java dans un navigateur sans plug-in. Et bien que la plate-forme WebAssembly puisse offrir une certaine flexibilité linguistique en Java via GraalVM, l’écosystème Java, aussi ouvert qu’il puisse être, reste dans l’ombre d’Oracle et de ses revendications sur les propriétés intellectuelles liées à Java.
WASM, étant sûr pour la mémoire et configuré pour la validation, présente également des avantages en termes de sécurité par rapport aux applets Java, bien qu’il puisse être vulnérable au détournement de flux de contrôle. Il joue également mieux avec des langages comme C/C++ et Rust.
Till Schneidereit, responsable de l’équipe WebAssembly de Mozilla, via Twitter, a expliqué la différence entre WebAssembly et Java: « WebAssembly a été conçu pour passer des appareils minuscules aux grandes batteries de serveurs ou aux CDN; il est beaucoup plus agnostique en langage que Java; empreinte de mise en œuvre beaucoup plus petite ».
Si l’importance potentielle de WASI n’est pas encore évidente, réfléchissez à la manière dont il est caractérisé par Solomon Hykes, cofondateur de Docker. « Si WASM + WASI existait en 2008, nous n’aurions pas besoin de créer Docker », a-t-il déclaré. « C’est son importance. WebAssembly sur le serveur est l’avenir de l’informatique. Une interface système standardisée était le chaînon manquant. Espérons que WASI soit à la hauteur de la tâche! »
Cédant cette vague d’optimisme, CDN biz Fastly a publié jeudi Lucet, son compilateur WebAssembly natif et son environnement d’exécution permettant d’exécuter du code WASM dans un environnement Cloud en périphérie. Il complète le Wasmtime de Mozilla, une exécution permettant d’exécuter du code WASM en dehors du navigateur.
Il reste beaucoup de travail à faire avant que WASI soit complètement cuit. WebAssembly pourrait également être affiné, comme la possibilité d’ accéder au DOM du navigateur (Document Object Model). Mais un binaire en écriture unique, exécuté n’importe où, représente un effort louable. En attendant, profitez de votre Java.