►
From YouTube: The JVM Meets WASI: Writing Cloud-Friendly Wasm Apps Using Java and Friends - Joel Dice
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
The JVM Meets WASI: Writing Cloud-Friendly Wasm Apps Using Java and Friends - Joel Dice
Java has been one of the most popular programming languages for decades and remains the go-to language for many enterprises. Other JVM-based languages such as Kotlin, Scala, and Clojure have gained large and loyal followings, boosted by easy interoperability with the vast body of Java libraries and frameworks. There are already a number of options for translating Java bytecode into WebAssembly for use in browsers, including Bytecoder, TeaVM, JWebAssembly, and CheerpJ. However, none of these were suitable for cloud-based workloads until recently. This presentation will describe how to use TeaVM to build WASI-compatible WebAssembly modules from Java, Kotlin, and any other language that compiles to Java bytecode. It will also discuss some of the advantages of doing so versus using a traditional JVM, including faster startup time, broader language interoperability, and improved isolation of untrusted code.
A
A
I
started
to
piece
things
together
and
added
some
new
tools
to
the
mix
to
actually
make
it
work
and
now
I've
become
somewhat
addicted,
and
now
you
have
to
listen
to
me
rave
about
it
today,
so
to
set
a
little
context
here.
This
is
the
vision,
probably
very
fresh
in
your
mind
after
Luke's
talk
here
that
we
have,
which
is,
you
should
be
able
to
take
any
language.
A
You
want
in
fact
a
bundle
of
languages
if
you're
a
polyglot
development
shop
and
Target
webassembly
build
a
webassembly
component
and
then
run
it
in
whatever,
whatever
Target
environment
you
you
want
it
to
run
in
and
that
could
include
application.
Plugins
include
serverless
functions,
it
could
include
stored
procedures
and
databases
and,
of
course,
the
web
browser
and
a
couple
things
to
notice
about
all
these
places
I've
listed
here
is
that
we
want
to
be
able
to
provide
isolation
in
pretty
much
all
these
cases.
A
We
have
sort
of
a
mixed
trust
model
where
you've
got
code,
possibly
from
multiple
Origins.
Certainly
that's
going
to
happen
in
a
web
browser,
but
potentially
in
any
of
these
cases,
and
you
want
to
separate
them
from
a
security
system
point
and
a
privacy
standpoint-
there
could
be
sensitive
data
you're
handling.
There
could
be
a
multi-tenant
situation
that
you
need
to
support,
so
that's
really
important
and
the
other
thing
is
in
many
of
these
cases.
We
want
fast
startup
time.
A
You
know
in
the
browser
you
want
a
page
to
load
very
quickly
and
start
being
interactive
very
quickly.
You
want
fast
startup
time
in
terms
of
HTTP
request
handlers
in
a
serverless
scenario
in
a
database,
you
want
to
be
able
to
run
a
function
on
a
piece
of
data,
hundreds
and
thousands
of
times,
and
you
want
the
latency
to
be
minimized
for
each
of
those
runs.
A
So
that's
going
to
be
a
big
theme.
Here
is
isolation
sandboxing,
whatever
you
want
to
call
it
to
ensure.
You
know
that
separation
of
concern
separation
of
data
separation
of
resources,
but
today
we're
going
to
focus
in
particular
on
jvm
languages,
Java
itself,
Scala
closure,
kotlin,
whatever
your
favorite
jvm
language
is,
we
want
to
see
that
work
in
all
those
environments.
A
So
we'll
start
out
by
looking
at
some
of
the
traditional
tools
you
would
use
in
Java
development
and
then
compare
those
with
what
you'd
use
today
to
develop
webassembly
components
and
then
see
how
we
can
combine
those
and
then
we'll
look
at
why
you
would
want
to
do
that
and
also
why
you
might
not
want
to
do
it.
We'll
look
at
you
know
performance.
You
know
what
what
sacrifices?
If
any,
do
we
have
to
make
to
achieve
that
level
of
isolation?
A
A
All
of
these
are
going
to
compile
to
Java
byte
code
and
that
Java
byte
code
can
then
be
run
on
what's
called
a
JRE
or
a
Java
runtime
environment,
and
that
environment
has
two
pieces.
It's
got
a
virtual
machine
that
interprets
the
byte
code
executes
it,
and
then
it's
got
a
class
Library
standard
class
Library,
which
provides
the
apis
and
and
and
basic
tools
that
you
would
use
to
build
an
application
and
that
the
main
function
of
that
those
apis
is
to
provide
access
to
the
outside
world
operating
system
functionality.
A
Networking
that
sort
of
thing.
So
how
does
that
compare
with
the
web
assembly
component
model
development
experience?
Well,
it
turns
out.
It
looks
very
similar.
It
shouldn't
probably
surprise
you
if
you've
been
around,
you
know
Computing,
for
a
few
decades
now,
you'll
recognize
that
Java
has
already
sort
of
covered
a
lot
of
this
ground
with
mixed
success.
Certainly
there
were
Java
applets
back
in
the
day
running
in
the
browser.
You
could
run
it.
You
know.
The
whole
idea
was
right
once
run
everywhere.
A
That's
what
we're
trying
to
do
with
webassembly
we're
trying
to
do
it
better,
but
it's
not
surprising
that
we're
following
a
similar
pattern,
and
so
here
you
take
your
favorite
programming
language.
Again,
you
compile
to
a
webassembly
module
or
component,
and
then
you
run
that
this
time
in
an
environment
that
very
much
resembles
the
jvm.
But
this
is
a
web
assembly.
Runtime
interprets
just
in
time
compiles
what
have
you
the
byte
code
in
the
webassembly
file,
and
then
we
have
various
apis
to
interface
with
outside
world.
A
That's
what
Luke's
talk
was
about
is
modularizing
the
those
apis,
but
right
now
we
have
Wazi
for
interacting
with
posix
style
systems
or
something
that
can
be
made
to
look
like
a
posix
style
system.
We
have
web
apis.
If
you're
running
this
in
the
browser
that
you
can
create,
Java
JavaScript
shims
for
and
then
you
can,
you
know
run
that
anywhere.
A
A
The
and
I
mentioned
worlds
to
mention
the
other
tool
which
I
think
Luke
also
mentioned,
which
is
with
binding,
and
this
takes
a
set
of
webassembly
interfaces
and
generates
bindings,
and
that's
the
second
big
contribution
we've
made
here,
which
is
Java
bindings.
They
landed
probably
about
a
week
or
two
ago
in
The
Binding
repository.
So
now
you
can
generate
Java
bindings
and
if
you
know
anything
about
the
Java
ecosystem,
it's
very
easy
to
reuse,
those
bindings
in
closure
or
and
from
Scala
and
so
on.
A
So
you
know
next
question
might
be.
Why
would
you
want
to
do
this?
You
know
this
looks
a
little
more
complicated
right.
Well,
good
news
is
these
tools
are
actually
sort
of
hidden
behind
the
scenes
you
don't
really
have
to
work
with
them
directly
as
we'll
see
later,
all
you
have
to
do
is
a
maven
build
and
you're
Off
to
the
Races.
You've
got
a
web
assembly,
but
there
is
extra
complication,
extra
things
that
could
go
wrong
potentially,
so
why
would
you
want
to
do
it?
Well?
A
First,
let's
look
at
why
you
might
not
want
to
you
know,
first
of
all,
if,
if
you
are
well
served
already
with
the
Java
ecosystem
and
your
your
team
knows
Java
or
scholar,
what
have
you
and
you're
used
to
the
tools
that
are
available
in
that
ecosystem,
you
probably
do
want
to
stick
with
that.
If
it's,
if
you're
well
served
if
you're
writing
long-lived
stateful
applications
and
services,
the
that's
what
Java
was
made
for,
it's
got
Decades
of
optimizations
and
fine-tuning
for
those
sorts
of
things.
A
If
all
your
code
is
trusted,
you're
writing
a
monolith
or
a
micro
service
that
you
know
all
your
dependencies
are
vetted.
You
know
Java's
does
really
well
there
and
then,
as
we'll
see
in
a
moment,
the
jvm
has
maximum
throughput.
It's
the
hotspot
jvm
from
Sun
and
now
Oracle
has
been
optimized
for
decades.
It's
an
amazing
piece
of
technology,
and
so
I
would
sum
this
up
as
by
default.
A
These
days
want
to
be
able
to
use
possibly
a
mix
of
languages
that
are
jvm
friendly
and
not
so
jvm
friendly
and
the
you
know
the
hot
thing
these
days
is
Building
Services
out
of
stateless
functions,
the
whole
serverless
Paradigm
and,
as
we
saw
earlier
short-lived
functions,
you
know,
have
applications
and
databases,
you
know
smart
contracts,
etc.
Those
cases
are
not
necessarily
what
the
jvm
was
designed
to
handle,
whereas
webassembly
that's
kind
of
its
bread
and
butter,
untrusted
and
or
multi-tenant
code.
A
This
is
definitely
something
you've
seen
the
browser
serverless
if
you're
hosting
a
platform
as
a
service
or
you're
choosing
a
platform
as
a
service.
You
want
to
know
that
there's
strong
security
and
isolation
guarantees
that
there's
your
data
is
not
going
to
be
leaked,
you
know
through
side,
Channel
attacks
or
or
otherwise.
A
So
you
know
strong
sandboxing
model
is
super
important
and
then,
even
if
you're,
not
in
a
multi-tenant
context
these
days,
any
modern
app
is
going
to
have
a
long
list
of
dependencies
and
transitive
dependencies,
and
you
know
for
Java
developers
in
particular.
The
whole
log
for
Jay
Fiasco
is
fresh
in
mind
and
people
have
been
talking
seriously
about.
You
know
how
do
we?
How
do
we
deal
with
this?
A
How
do
we
address
supply
chain
issues
and
that's
a
multi-faceted
problem,
but
one
of
those
facets
is
sandboxing
and
limiting
the
scope,
the
capabilities
to
use
Luke's
term
that
are
available
to
a
dependency,
and
you
know
so,
if
you're,
if
you
were
a
Java,
you
know
systems
administrator
a
few
months
ago,
you
were
probably
asking
yourself:
why
did
my
login
framework
make
Network
calls
a
and
why
did
it
load
classes
off
the
internet
to
to
execute
locally?
You
know
with
webassembly,
that's
you
know,
that's
a
non-starter!
A
First
of
all,
you
wouldn't
give
your
logging
framework
Network
capability
unless
it
specifically
needed
it,
and
even
then
you
would
restrict
the
set
of
hosts
that
could
access
and
class
loading
just
isn't
really
a
thing
in
webassembly.
So
all
your
code's
going
to
be
there
up
front
so,
but
one
question
often
comes
up.
It
certainly
came
up
in
my
mind
when
I
was
working
on.
This
is
what
about
performance
is
sandboxing
expensive.
A
You
know
what
cost
am
I
paying
to
achieve
that
sandboxing
and
so
here's
a
chart
I
just
you
know
performance
is
a
complicated
subject.
It's
hard
to
sum
up
in
a
single
chart
or
a
set
of
numbers,
but
what
I've
done
here
is
I
took
just
a
handful
of
little
example:
CPU
heavy
types
of
problems
and
Benchmark
them
in
various
execution
models.
So
just
the
the
main
takeaway
here
is
what
I
said
before
maximum
throughput
is
what
you
would
get
from
openjdk
or
any
other
modern
jvm.
A
And
that's
what
we
see
here
in
the
blue.
That's
open,
jdk,
with
no
attempt
at
sandboxing
we're
just
trying
to
get
the
best
possible
performance
and
then
over
in
red.
We
have
TVM
plus
wasm
time
a
popular
web
assembly
run
time
and
we
can
see
how
performance
Stacks
up
there
and
then
in
the
yellow.
We
have
open
jdk
again,
but
this
time
we're
actually
trying
to
sandbox
it
we're
actually
forking
a
process
for
each
invocation
of
our
function.
Here
and-
and
so
we
see
that
has
a
performance
impact
and
just
for
fun.
A
I
threw
in
grovel
VMS,
ahead
of
time
native,
compile
option
which
you
know
and
with
also
with
sandboxing,
just
to
kind
of
see
how
web
assembly,
with
TVM
Stacks
up
against
the
other
options.
You
have
for
sandboxing
Java
if
you've
been
around
the
Java
ecosystem
for
a
while.
You
know
that
there
are,
there
were
originally
I
should
say
past
tense
ways
to
sandbox
code
within
the
jvm.
That's
been
deprecated
the
security
manager
if
you're
familiar
with
that,
that's
been
deprecated,
there's
no
planned
replacement.
A
So
quickly
that
you
can
shut
it
down
before
you
even
need
to
garbage
collect
and
that's
pretty
much
instantaneous.
Plus
these
things
are
embarrassingly
absurdly
parallelizable.
You
know
when
each
invocation
has
its
own
memory
is
not
sharing
state
with
others.
You
can
horizontally
scale
these
things
to
the
nth
degree
and
win
back
some
of
that
performance
that
you
lost
in
terms
of
you
know
pure
CPU,
single
core,
all
right.
So
all
this
hopefully
sounds
pretty
good.
You
know:
we've
got
strict
isolation.
A
We've
got
competitive
performance
for
compared
to
what
else
is
out
there,
we're
buzzword,
friendly
we're,
modern,
we're,
hip
or
cool.
So
what's
not
to
like
about
this.
Well,
there
are
some
limitations.
You
know
they're
all
addressable,
but
they're
worth
mentioning
right
now.
The
webassembly
support
in
TVM
itself
is
experimental.
It
was
actually
intended
originally
as
a
tool
to
transpile
Java
byte
code
to
JavaScript,
and
that's
still,
it's
bread
and
butter
to
be
run
in
the
browser.
A
So
there
are
some
bugs
hidden
there.
It
works
really
well
for
the
most
part,
but
there's
you
know,
there's
bugs
and
we're
going
to
need
to
address
those.
The
standard
library
is
incomplete.
It's
you
know,
there
was
a
deliberate
decision
and
I
think
it
was
the
right
one
not
to
reuse
the
Open
jdk
Class
Library
due
to
licensing
concerns
the
GPL
and
it's
maybe
not
so,
business
friendly
nature
reflection
if
you're
a
long
time,
Java
developer.
A
You
know
that
reflection
can
be
like
this
drug
that
you
know
you
tend
to
use
to
solve.
It's
the
hammer
you
use
to
solve
all
the
problems
and
many
Upstream
dependencies
might
might
need
it
one
way
or
the
other,
and
that
takes
a
little
bit
of
extra
upfront
development
effort
and
then
the
wazzy
component
model
that
Luke
talked
about
earlier.
It
is
under
rapid
development.
That's
a
good
thing.
You
know
we're
making
rapid
progress.
A
It
also
means
the
tools
are
churning
the
interfaces
with
binding
every
day,
the
interfaces
change
and
whatnot.
So
it
takes
some
work
to
keep
up
with
and
then
finally
debugging
and
profiling.
If
you're
used
to
visual
VM-
or
you
know,
debugging
in
Eclipse,
the
experience
for
webassembly
is
not
nearly
as
slick
it
is
doable.
It
could
be
made
better.
A
And
let's
see
so
in
terms
of
next
steps
and
ways
we
could
improve,
you
know
it's
basically
a
reflection
of
the
last
slide.
We
want
to
get
more
TVM
Test
passing.
We
want
to
add
more
features
to
the
standard
Library
as
popular
third-party
dependencies
need
those
extra
features.
We
need
to
stay
current
with
the
component
model
as
it
evolves.
We
need
to
ideally
generate
some
debug
info.
A
B
A
Requests
and
translate
English
words
to
Spanish
words:
it
uses
wazzy
to
access
the
file
system
and
load
the
dictionary
of
words
also
just
to
show
off
outbound
HTTP
capabilities.
It
can
optionally
proxy
a
response
from
another
host
I'm
not
going
to
spend
too
much
time.
Looking
at
this
code
right
now,
but
you're
welcome
to
check
out
the
link
at
the
end
of
the
presentation.
A
Thank
you
all
right,
so
that's
about
it.
That
was
the
demo
there's
going
to
be
a
link
here.
There's
all
the
links,
so
the
benchmarks
I
showed
you.
The
results.
I
showed
you.
Those
are
available
in
a
repository
here,
there's
a
link
to
that
and
as
well
as
the
demo
I
just
did
the
application
and
a
few
other
resources,
the
link
to
the
Java
binding
generator
in
whitbine
gen
and
then
TVM
wazzy,
I
I
should
just
note.
I
didn't
make
this
clear
earlier.
A
Tpm
wazzy
is
a
friendly
Fork
of
Upstream
TVM.
We
do
have
a
PR
open
for
Upstream
TVM
we'd
like
to
get
it
Upstream.
It's
not
clear
whether
that
really
fits
the
mission
of
TVM
as
the
lead
maintainers
see
it.
So
it
may
not
end
up
Upstream,
in
which
case
we'll
just
maintain
a
parallel
friendly
Fork
going
forward.
C
A
For
sure
yeah,
so
the
question
was,
you
know:
I
wanted
to
hear
more
about
the
transpilation
that
TVM
does
from
java
byte
code
to
webassembly.
The
first
thing
you
need
to
know
is
because
webassembly
currently
doesn't
have
garbage
collector
support
doesn't
have
exception.
Support
doesn't
have
any
notion
of
reflection
and
whatnot
that
all
gets
bundled
into
the
web
assembly
that
you
create
the
component
and
the
cool
thing
is
that
amounts
to
about
180.
A
Kilobytes
of
you
know
in
the
hello
world
case,
that's
kind
of
where
you're,
starting
from
so
very
minimal,
otherwise
Java
byte
code.
If
you,
if
you
squint
it's
not
that
different
from
webassembly,
and
so
things
like
working
with,
you
know,
floats
and
integers,
and
so
on.
That
translates
almost
one
to
one.
You
know
the
the
stack
model
and
the
register
model
is
a
little
bit
different,
but
you
know
there's
a
straightforward
transformation,
higher
level
instructions
and
Java
byte
code
such
as
you
know,
invoke
virtual
invoke
interface
and
whatnot.
A
Those
all
have
to
be
kind
of
built
out
of
the
web
assembly
Primitives
to
do
look
up.
So
you
know
they're
static,
there's
a
whole
static
memory
segment
that
is
instantiated
in
the
web
assembly
for
virtual
function
tables
and
that
sort
of
thing
so,
but
it
you
know
it
compiles
down
to
a
pretty
efficient
code
and
I'm
sure
you
know
if
the
proposals
to
add
garbage
collection
and
exceptions
to
core
webassembly
gain
traction
then
we'll
see
that
you
know
become
an
even
smoother
and
you
know
more
straightforward
transition.
D
So,
in
the
course
of
your
experiments,
I'm
curious
to
see
one
of
the
things
we
tend
to
see
is
this:
the
idea
is
really
easy
to
see.
Webassembly
and
fast
firing
functions,
model
kind
of
thing,
a
lot
of
the
things
like
java.net,
you
know
like
I'm
from
Microsoft,
so
it's
a
similar
model
on
approach
or
based
on
sort
of
the
idea
of
a
kind
of
a
heavy
scalable
middle
tier
sort
of
concept.
D
It's
long
running,
you
can
do
all
kinds
of
cool
things
right
in
the
course
of
this
experiment
that
you're
you're
working
on
this
project,
like
how
did
your
thoughts
evolve
with
respect
to
sort
of
where
the
strengths
and
weaknesses
were
a
little
bit
more
than
what
you
just
said
here
like
did
you
have
things
where
like
oh?
Actually,
we
could
do
that
or
oh
no,
that's
not
really
the
thing
we
should
do,
and
so
on.
A
Yeah
well
so
you
know,
I
was
coming
at
it
from
the
point
of
view
of
spin.
You
know,
Matt
talked
Matt
and
Radu
talked
a
bit
about.
You
know
the
whole
idea
behind
Spin
and
it
was
very
much
this
mindset
of
serverless
functions
and
whatnot.
So
you
know
I
I
actually
have
about
two
decades
of
development
experience
in
Java
and
have
worked
on
those
big
monolithic,
long-lived
servers
and
whatnot
and
I
think
there's
still
a
place
for
that.
They're
always
is
going
to
be
a
place
for
those,
but
I'm
really
excited
about.
A
You
know
the
component
model
and
in
in
the
serverless
context.
For
basically,
you
know,
starting
with
stateless
functions,
using
that
as
your
super
horizontally,
scalable
building
block
and
then
using
you
know
a
distributed
data
store
or
whatnot
to
kind
of
store.
Your
state.
You
know
between
requests
and
so
on,
to
build
those
those
distributed
systems,
and
so
you
know
it's.
It's
really
I
think
it's
a
matter
of
opinion
and
also
a
matter
of
use
case.
Whether
microservices
and
Nano
services
and
serverless
are
appropriate
versus
a
monolithic.
A
You
know,
beefy
Big,
Iron,
server
and
I.
Think
you
just
need
to
know
your
problem
domain
well
enough
to
kind
of
make
that
decision.
I,
don't
think,
there's
ever
going
to
be
the
right,
a
single
right
answer.
So
that's
why
I
was
trying
to
be
very
balanced
here.
I
think
a
lot
of
people
just
should
stick
with
that
that
Java
model,
that
kind
of
just
you
know,
long-lived
stateful
service
model
and
but
I
do
think.
A
There's
room
for
you
know
a
different
model
depending
on
your
use
case
and
and
again
you
know
being
able
to
reuse
this
in
the
context
of
databases
in
the
context
of
blockchain.
In
the
context
of
the
browser,
you
know,
I
think
we're
just
seeing
a
lot
of
different
places.
People
want
to
use
Java
or
any
other
language
and
and
that's
what
this
is
all
about.