- Un runtime Wasm implémenté en Java pur, sans dépendance externe
- Permet d’exécuter des modules Wasm partout où la JVM fonctionne
- S’intègre facilement dans un projet, ce qui permet de mettre en place simplement un système de plugins
- Les modules WebAssembly s’exécutent dans un environnement sandbox, ce qui est avantageux du point de vue de la sécurité dès la conception. Il est possible de contrôler toutes les ressources
- Vise une prise en charge complète de la spécification cœur de Wasm
- Inconvénients des autres runtimes Wasm
- Il existe divers runtimes Wasm comme v8, wasmtime, wasmer, wasmedge et wazero, mais la plupart sont écrits dans des langages natifs et doivent donc inclure des binaires propres à chaque OS/architecture lors du déploiement
- L’utilisation de code natif et de la FFI (appel de fonctions externes) peut faire sortir de l’outillage de la JVM, de son modèle de sécurité et de son observability
2 commentaires
Les inconvénients d’un runtime wasm ne s’appliquent-ils pas aussi à la JVM ?.. J’imagine que vous avez listé les inconvénients du point de vue d’un développeur Java, n’est-ce pas ?
Je suis plutôt un pur Java, et comme je n’ai rien trouvé de vraiment satisfaisant pour faire du wasm en Java, j’étais justement en train d’étudier Rust, donc ça fait plaisir à voir.
Parmi les raisons pour lesquelles j’étudie Rust, il y a aussi une certaine nostalgie du low-level.