►
From YouTube: Jakarta EE 9 and Beyond
Description
Jakarta EE 9 is out! This is the second release of Jakarta EE since the transition from the Java Community Process (JCP) to Eclipse Foundation. In this session, we will go through every aspect of Jakarta EE 9 and how this release lowers the barriers of entry, eases the migration and lays the foundation for a platform for future innovation.
We will also look ahead towards what future releases may bring.
Speaker(s):
Ivar Grimstad (Eclipse Foundation)
A
Okay,
welcome
to
this
talk
on
jakarta,
e9
and
beyond.
My
name
is
ivar
grimstad
and
I'm
the
jakarta
year
developer
advocate
at
eclipse
foundation.
This
is
my
second
epclipscon
and
the
first
virtual
one,
that's
probably
most
of
the
speakers,
but
some
words
about
me.
I'm
you
can
see
my
twitter,
my
linkedin,
my
my
github
here
just
feel
free
to
contact
me
on
any
questions
regarding
jakarta
e
or
or
java
in
general,
I'm
a
member
of
the
java
community
executive
committee
and
we're
actually
running
for
elections.
A
A
A
So,
to
start
with
I'll
I'll,
give
you
an
introduction
on
jakarta,
ee
and,
as
you
probably
remember,
it
used
to
be
java.
Ee
and
java
eve
was
governed
by
the
java
community
process
run
by
oracle
for
many
years.
It's
been
a
tremendous
success
story
and
a
couple
of
years
ago,
oracle
decided
that
it
was
time
to
open
source
java
e
and
move
it
over
to
eclipse
foundation.
A
A
And
you
also
may
wonder:
where
are
the
jakarta
name
coming
from
and
those
who
are
been
in
the
game
for
a
while,
probably
remember,
jakarta,
apache
project,
and
that
was
the
an
umbrella
project
for
all
the
java
projects
at
apache
foundation
and
apache
foundation
was
so
gentle
with
us
that
they
let
us
have
the
name
and
from
that
we
got
jakarta
ee
and
the
the
source
of
information
for
jakarta
and
all
related
stuff
is
jakarta.edu.
It's
a
super,
simple
url
to
remember.
A
A
So
what
we
do
at
jakarta
dde,
then
we
produce
specifications
and
what
are
specifications
first
of
all,
it's
a
lot
of
them
and
in
jakarta
e
we
have
34
different
specifications,
a
little
more
than
34
are
listed
here,
and
that
is
the
the
grayed
out.
One
at
the
bottom
are
specifications
that
we
have
decided
not
to
develop
any
further,
so
so
they
are
still
there
and
you
can
still
use
them
and
they're
being
used.
But
we
look
at
them
as
as
legacy
technology
that
won't
need
to
be
developed
any
further.
A
They
are
stable
as
they
are,
then
we
have
divided
the
specifications
into
into
a
chicari
web
profile
and
a
jakarta
platform,
and
the
web
profile
is
a
subset
of
the
platform.
So
so
this
is
how
we've
kind
of
organized
these
you
can
either
get
certified
by
implementing
all
the
java
web
profile
specifications
or
a
full
profile
certification.
A
The
specifications
at
jakarta
e
are
open
and
by
open
specifications
we
mean
that
the
specifications
are
developed
using
the
jakarta
e
specification
process
and
this
process
mandates
a
code
first
approach.
That
is,
we
want
to
have
some
technologies
that
are
proven
to
work
that
you
have
some
some
some
use
case
that
you're
solving
something
with
a
technology
that
has
been
around
for
a
while.
Then
you
can
specify
it
it's
collaborative,
so
everybody
is
welcome
to
join
and
collaborate
on
creating
these
specifications.
A
A
We
also
have
the
concept
of
compatible
implementations.
In
the
jcp
days.
We
used
to
have
a
reference
implementation
that
was
kind
of
a
one
implementation
that
was
used
to
prove
that
the
specification
was
implementable
in
jakarta.
We
have
the
notion
of
compatible
implementation,
so
there
is
no
implementation.
That
is
any
more
special
than
others.
So
so
we
we
have
the
the
concept
of
compatible
implementations
and
there
may
be
many
of
them,
but
at
least
one
we
also
practice
self-certification.
A
The
jaccardi
specification
process
has
a
a
a
couple
of
reviews
here
that
are
import,
important
milestones
where
that
the
specification
goes
through
so
at
first
it
it's
created
and
in
order
to
to
become
a
specification,
the
specification
committee
has
to
approve
that.
Yes,
it's
a
valid
thing
to
specify.
So
that's
why
we
have
the
creation
review
and
then
we
require
a
plan
review.
A
So
what
is
the
specification?
Then?
A
specification
in
our
terminology
is
a
specification
document.
It's
an
api
artifact
and
it's
a
test
suite
or
a
tck,
a
test
compatibility
quiz,
okay
and
all
this
together,
backed
by
a
compatible
implementation.
That
shows
that
the
specification
specified
in
the
document
is
implementable
that
passes
the
tck.
A
So
compatible
implementations,
then
there
are
a
lot,
a
lot
of
compatible
implementations
and
we
have
adequate
foundation.
We
have
an
eclipse,
glassfish
and
also
in
addition
to
this,
we
have
all
these
different
vendors
that
have
their
implementations
of
jakarta
ee,
and
these
are
the
ones
that
are
listed
on
our
compatibility
page,
which
is
jakarta.e,
slash,
compatibility
right
now
and
there
are
more
to
come.
A
A
and
and
to
show
that
it
actually
goes.
I'm
using
the
the
text
block
features
that
that
was.
That
is
newer
in
the
native,
at
least
so
so
this
is,
you
can
see
it
implements
the
jakarta
servlet
and
it's
a
super
simple
server.
This
just
says
hello,
and
it
says
hello
from
jakarta:
nine
greetings
from
solo
temple,
let's,
let's
call
it
servlet
5.,
and
so
let's
go
and
run
this
one.
A
There
we
go
and
while
it
runs
here,
I'm
going
to
switch
to
my
command
line
here
and
you
can
see.
I
have
tonkat
running
and
let's
drop
this
artifact
I
just
compiled
into
the
webers
folder.
You
can
see
I'm
copying
the
servlet
dude
war
application
in
here
and
let's
do
the
same
thing
with
jetty.
So
here
I
have
jetty
running
it's
it's
an
alpha
of
jetty.
A
So
let's
copy
this
one
in
there
the
same
file
so
copy
both
of
them
in
here
and
and
as
you
can
see
it,
it
deploys
so
then
I'll
open
the
browser
and
look
at
the
tomcat
installation
here
and
the
application
was
servlet.
Duke
hello-
and
you
say
it
says,
greetings
from
solidify,
which
I
just
didn't
know
and
the
same
thing
will
will
apply
if
you,
if
I
refresh
this,
you
see
that
the
server
duke
application
has
been
deployed
here.
I
can
go
in
and
say
hello
phone
check
out
e9,
so
you
see
it.
A
And
there
are
more
like
I
said:
there
are
lots
of
them
out
there
and
you
can
see
a
list
of
them
here
and
these
versions
are
newer
now.
But
you
can
probably
find
your
favorite
product
here
and
get
a
newer
version
that
supports
more
of
the
api.
So
you
can
download
the
release,
canvas,
milestones
and
etc
there,
and
if
you
want
to
get
listed
on
this
page,
use
the
hashtag
embrace
chikara
and
show
that
your
product
supports
jakarta,
89.
A
A
A
A
So
let's
go
and
change
that
first
I'll
go
into
the
pom
and
I'll
update
the
version
from
and
I'm
actually
using
the
reset
calendar
candidate.
Three
and
I
update
the
pom
file
I'll
just
have
to
to
update
my
project
as
well
and
when
that
is
done,
you'll
see
that
my
code
doesn't
compile
anymore,
because
there
is
no
java
x
name
space.
So
I
have
to
switch
this
and
most
most
of
it
is
done
by
the
ide.
A
A
So
there
it
compiles-
and
in
this
case
I'll
just
run
it
directly
from
my
ide
here.
So
I'll
just
show
the
the
first
one.
I
think
I
still
have
it
running
here.
It
says:
oh
sorry,
rustic
hello,
so
this
one
was
the
previous
one.
He
said
hello
to
jakarta,
e8
and
the
the
new
one
I'll
change
from
eight
to
nine.
A
A
So
we
want
to
pretty
soon
after
e9
release
a
901
release
with
java
se11
support,
and
this
java
se11
this
dot
release
of
jakarta
is
is
something
new
we
haven't
done
that
before,
but
in
this
case
it
it
makes
sense
rather
than
waiting
for
a
jakari,
10
or
or
even
releasing
a
jakarta
e-10,
which
is
jacardi
9
with
11
support.
It
makes
sense
to
do
the
the
11
support
there
online
that
one.
A
Some
stable
release,
cadence
and
and
as
the
community
community
usually
responds
to
questions
around
this
is
that
it
seems,
like
the
community,
wants
one
release
years
kenyans
and
we
are
exploring
how
to
set
this
and
define
when
and
how
this
is
going
to
be
done,
but
most
likely
we'll
end
on
some
sort
of
time-based
release,
cadence,
which
we
are
now
familiar
with.
With
from
the
javascript.
A
We
want
to
decouple
the
specifications
a
little
bit,
so
we
don't
have
to
to
have
so
much
coordination
when
we
are
releasing
the
specifications
for
jakarta
eight
and
the
current
e9.
It's
a
massive
effort
to
do
this
and
we
want
to
kind
of
decouple
the
especially
the
test
suites
that
are
testing
the
applications,
so
we
can
release
them
more
independently.
A
We
will
explore
a
cdi
and
see
if
that
can
be
used,
maybe
to
replace
some
other
technologies,
maybe
replace
ejb,
who
knows
and
and
or
move
things
from
egb
over
to
a
cdi,
maybe
even
make
a
lighter
profile
of
cdi.
That
is
more
suitable
for
ahead
of
time.
Compilation
we'll
see
if
the
work
has
already
started
there.
A
We
want
to
add
some
new
apis
if,
if
the
community
wants
it
and
up
for
grabs
or
jacob
and
nosql
are
working
on
there,
it's
probably
something
that
could
be
explored,
even
in
combination
with
the
jba,
maybe
or
or
as
a
standalone
specification
as
it
is
now
jakarta.
Mvc
is,
has
recently
released
version
101
and
is
planning
a
version
2.0
on
the
jakarta
namespace.
So
that
is
a
possible
addition
to
the
web
profile.
A
A
A
A
A
A
At
jakartablogs.eee
do
read
my
hashtag
chikari,
which
comes
out
weekly
on
my
blog,
and
that
is
what
I
have
for
today
is
so
or
I'll
just
do
a
a
reminder
that
the
jicara1
live
stream
is
coming
in
december
8th
this
year,
so
do
go
into
gcard1
at
oregon
and
register
there.
The
the
paper
is
closed
and
the
program
is
being
being
set
together.
A
B
A
So
the
question
is,
I'm
totally
new
and
reactive
programming
world,
and
I
even
don't
know
if
my
question
makes
any
sense,
but
I'd
like
to
know
if
jacari
offers
any
support
or
help
for
reactive
programming
and
the
answer
to
that
is
not
currently.
No,
there
are
some
initiatives
in
microprofile
on
reactive
support
and
the
now
that
the
establishment
of
market
profile
is
coming
up.
It
doesn't
make
sense
to
duplicate
that
efforts
in
in
jakarta,
so
so
take
a
look
at
the
reactive
work
that
that
is
being
done
in
microprofile.