- Eine in reinem Java implementierte Wasm-Laufzeit ohne zusätzliche Abhängigkeiten
- Wasm-Module können überall ausgeführt werden, wo die JVM läuft
- Lässt sich einfach in das eigene Projekt integrieren, sodass sich Plugin-Systeme leicht umsetzen lassen
- WebAssembly-Module laufen in einer Sandbox-Umgebung und sind daher konzeptbedingt aus Sicherheitsgründen vorteilhaft. Alle Ressourcen lassen sich kontrollieren
- Ziel ist die vollständige Unterstützung der Wasm-Core-Spezifikation
- Nachteile anderer Wasm-Laufzeiten
- Es gibt verschiedene Wasm-Laufzeiten wie v8, wasmtime, wasmer, wasmedge und wazero, aber die meisten sind in nativen Sprachen geschrieben, sodass bei der Bereitstellung Binärdateien für jedes OS und jede Architektur mitgeliefert werden müssen
- Durch den Einsatz von nativem Code und FFI (Aufruf externer Funktionen) kann man die Tools, das Sicherheitsmodell und die Observability der JVM verlassen
2 Kommentare
Gilt das, was als Nachteil einer Wasm-Laufzeit erwähnt wird, nicht auch für die JVM? Sie haben die Nachteile vermutlich aus der Perspektive eines Java-Entwicklers beschrieben, oder?
Ich bin eher ein Java-Fanboy, und da es nichts gab, was mir bei Wasm mit Java wirklich gut gefiel, lerne ich gerade Rust — daher freut mich das.
Einer der Gründe, warum ich Rust lerne, ist allerdings auch eine gewisse Nostalgie für Low-Level-Themen.