►
From YouTube: Jakarta EE - Present and Future
Description
Java EE has been re-branded to Jakarta EE and moved to truly open source governance under the Eclipse Foundation. This session overviews what this means, offers a brief tour of the first release - Jakarta EE 8, explores current state and looks to what the future might bring including some key challenges. We will also discuss how these challenges can be overcome through active community engagement.
The technical contents of Jakarta EE 8 is mostly the same as Java EE 8 - it solidly enables HTTP/2, Server-Sent Events (SSE), JSON and aligns the platform with Java SE 8. It includes a much awaited security API overhaul as well as a slew of critical updates to APIs like JSF, JPA, JAX-RS and CDI. The true difference is how Jakarta EE is evolved in the open.
You should come to this session with your thinking caps on and your sleeves rolled up. There is much to help move forward together that really matters.
A generic version of the slide deck is available here as a shared Jakarta EE Ambassadors resource: https://drive.google.com/drive/folders/1ohinS4JaDSEjsoFLYeyVOsBii_A-4sRf
A
Hello,
this
talk
is
about
the
current
state
and
future
of
the
jakarta
ee
platform.
My
name
is
razer
raman,
I'm
giving
this
presentation
on
behalf
of
the
jakarta
e
ambassadors,
I'm
also
an
author,
blogger
and
speaker
on
screen.
You
see
my
email
address
and
twitter
handle
feel
free
to
reach
out
to
me
if
you
have
any
questions
on
this
topic.
A
A
So
in
this
particular
presentation
other
than
giving
you
the
information.
I
also
hope
to
give
you
a
rendition
of
how
this
presentation
could
be
delivered,
and
you
can
obviously
take
any
part
of
this
presentation
and
modify
it
in
any
way
that
you
like
the
basic
example.
The
basic
objective
is
to
give
you
an
example.
A
Okay,
so
what
is
jakarta
is
specifically
in
case
you
don't
know.
Is
the
technology
called
that
used
to
be
called
java,
ee
transitioned
from
the
jcp
to
the
eclipse
foundation
and
as
part
of
that
transfer,
there's
some
rebranding
that
needed
to
take
place
and
we'll
talk
a
little
bit
more
about
this
in
a
second.
A
A
A
Similarly
pretty
much,
everything
is
a
lot
more
open
than
it
used
to
be
so
really,
nobody
has
any
special
privileges
under
the
jakarta
e
regime,
so
we
do
have
a
well-defined
specification
process
just
like
we
used
to
be
have
under
the
jcp.
In
fact,
you
could
argue
that
it's
a
bit
more
transparent,
there
is
very
clear
ip
flow.
The
ip
flow
used
to
be
very
centered
on
oracle
and
sun.
Now
that
is
really
not
the
case.
It
is
more
or
less
a
shared
pool
of
ipflow.
A
That
is,
is
far
more
open
again,
it
is
very,
very
vendor
neutral.
So
there
is
a
specific
focus
on
vendor
neutrality
and
jakarta
e
and
having
a
level
playing
field,
not
just
with
all
the
vendors,
but
you
also
included
so
you
as
a
community
member,
actually
now
have
far
more
opportunities
and
ways
of
contributing
to
the
technology
and
having
a
say
in
the
technology.
A
Now,
of
course,
jakarta
is
a
very
large
technology
set
and
a
very
important
technology
set,
and
one
of
the
important
parts
is
strong,
vendor
support
and
strong
corporate
support,
and
that
continues
to
be
the
case,
including
oracle
itself.
In
fact,
oracle
remains
one
of
the
key
contributors
to
even
to
jakarta
ee,
but
there
are
other
players
as
well
many
other
players,
including
ibm,
payara,
pivotal
and,
of
course,
eu
the
community
at
large.
In
fact,
the
community
at
large
has
been
contributing
quite
heavily.
A
The
second
largest
contribution
does
come
from
the
community,
so
folks,
like
yourself,
so
if
you
want
to
find
out
more
about
jakarta,
the
best
place
to
do
so
is
to
log
on
into
the
jakarta
e
website.
I
won't
talk
too
much
about
it.
There's
many
nuances
that
you
could.
You
could
talk
about
and
really
understand
why
this
technology
is
far
more
open
and
why
that
is
so
important.
A
This
is
basically
the
first
time
such
a
large
part
of
the
java,
ee,
or
rather
java
platform,
has
become
open
source
and
has
become
really
so
open
in
terms
of
in
terms
of
its
ability
for
many
people
to
participate,
and
in
fact
it's
very
unique.
You
one
you
might
say
this
is
probably
the
most
significant
and
most
open
part
of
the
java
platform
and
java
ecosystem
overall
today.
So
definitely
an
important
thing
for
you
to
consider.
A
So
I
think
we
all
know
the
evolution
of
java
ee
as
a
technology.
It
used
to
start
with
something
called
jpe
for
those
who
don't
know
what
that
stands
for
is
java
professional
edition,
and
then
the
technology
becomes
j2e
and
really
under
undergone
a
significant
investment
from
sun
at
the
time
and
led
to
the
popularization
of
the
technology
and
in
fact,
the
relevance
of
servers
like
java.
A
In
java,
from
java
e8,
you
had
the
transition
to
jakarta
e,
so
the
first
release
under
jakarta
e
was
jakarta.
E8,
jakarta
e8
is
basically
binary,
compatible
technology
wise
with
java
eight
there's,
no
technological
differences.
The
big
difference
really
is
that
java,
jakarta
e8
is
released
under
completely
open
source
governance
at
the
eclipse
foundation,
including
the
open
source
tck.
A
A
So
that
is
in
fact,
what
jakarta:
a9
is
mostly
about
I'll
talk
a
little
bit
more
about
jakarta
39
in
a
second,
but
basically
it's
about
renaming
the
package
names
from
javax
to
jakarta
and
then,
finally,
in
jakarta,
ee
10,
which
is
not
yet
to
be
determined.
What
what
that
is
and
we'll
talk
about
that
in
a
second
as
well.
A
That
is
really
where
the
innovation
will
begin
to
happen.
So
we'll
begin
to
reap
all
of
the
benefits
of
all
this
openness
and
being
able
to
move
the
technology
into
a
place
where
it
can
be
participated
in
by
many
more
people
in
an
open
fashion,
implemented
in
in
a
more
open
fashion
by
many
more
people
and
hopefully
also
accelerate
faster
than
certainly
what
java
ee
used
to
be
so
that
those
are
the
principal
objectives
of
moving
the
technology
to
the
eclipse
foundation.
To
begin
with.
A
So
let's
take
a
look
at
jakarta
at
a
glance
and,
as
I
mentioned
again,
it's
not
very
very
different
from
what
what
java
e8
is.
But
what
I've
noticed
is
not
a
lot
of
people
know
what
is
in
in
java
8.
So
at
least
a
part
of
this
presentation
will
be
spent,
taking
a
look
at
what
precisely
is
in
jakarta
e8.
A
Now
one
of
the
interesting
things
that
actually
happened
in
the
jakarta
e
transition
is
that
in
the
jcp
world
we
used
to
use
a
lot
of
acronyms
cdi,
jpa
and
so
on
and
so
forth,
jax
rs
and
so
on.
So
in
jakarta,
e
we've,
essentially
gotten
rid
of
all
of
those
acronyms
and
name
naming,
began,
naming
things
in
a
much
more
simpler
way.
So,
instead
of
jsf,
it's
jakarta
faces
in
case
of
in
jpa,
it's
no
longer
jpa.
It's
jakarta
persistence!
A
A
So
in
jakarta
8.
There
are
several
themes
that
I've
outlined
in
this
in
in
this
slide
deck
here.
So
one
is
the
web
standards
alignment.
So,
luckily,
for
us,
the
web
standards
are
suddenly
moving
much
faster
than
they
used
to.
Certainly,
since
the
90s,
so
there's
a
lot
more
innovation
going
on
in
places
like
the
w3c
and
one
of
the
key
objectives
of
jakarta
e8
is
to
stay
relevant
and
to
adopt
all
of
these
changes.
So
some
examples
of
this
is
servlet
4
or
http.
2.
A
Adoption
of
server
sent
events
json
binding
support,
json
pointer
support,
adopting
things
like
jsonpatch
and
we'll
talk
about
a
lot
of
these
things
in
detail.
Of
course,
in
a
moment,
there's
also
some
alignment
with
cdi.
So
as
of
java
e6
really
cdi
is
a
key
central
component
model
in
j2e
it
used
to
be
ejb.
It's
that's
not
the
case
with
java
e6
onward.
So
more
and
more
in
every
single
release.
We
align
more
and
more
of
the
platform
to
our
cdi.
So
in
java
jakarta
eight
a
few
important
things
happen.
A
A
Now
simplicity
has
been
a
theme,
obviously,
as
I
mentioned
since
java
ee5.
So
the
two
things
that
were
simplified
in
jakarta
eight
is
security
which
we'll
talk
about
in
a
at
a
later
stage
and
also
pruning
some
of
the
older
java
or
other
ejb
technologies.
So
this
also,
you
can
consider
it
part
of
the
perhaps
part
of
cdi
alignment
as
well.
A
Lastly,
the
java,
ee
or
jakarta
ee
platform
has
always
taken
advantage
of
fundamental
innovations
in
the
in
the
ecosystem,
certainly
but
more
specifically
in
java
essay.
So
in
java
sc8
in
particular,
as
you
know,
there
was
a
number
of
very
important
changes
that
are
very
useful
for
enterprise
java
developers.
So
these
are
things
like
repeatable
annotations,
the
date
time,
api
streams,
completable
features
and
in
fact
what
has
happened
with
jakarta.
A
A
In
case
you're
not
aware,
http
2
is
a
very,
very
significant
change
to
the
fundamental
protocol,
basically
powering
the
entire
web.
So
in
order
to
understand
this,
you
will
need
to
turn
the
dial
back
and
do
some
time
traveling
back
to
when
http
was
first
conceived.
So
when
http
was
first
conceived,
a
lot
of
the
web
pages
looked
a
lot
like
wikipedia,
so
basically
you
would
load
a
page
and
the
the
page
would
mostly
be
self-contained
with
a
lot
of
text
in
it
and
not
many
other
resources.
A
A
A
Now
time
travel
back
to
the
present
time,
the
web
has
evolved
as
it
should.
It
has
built
upon
its
success
and
it
has
evolved.
Now.
If
you
look
at
the
typical
web
website
or
web
page
today,
it
is
no
longer
very
textual
regardless
there's
definitely
a
lot
of
text,
but
in
addition
to
the
text,
there's
a
lot
of
other
things
to
render
that
page,
like
images,
css,
javascript
videos
and
so
on
right.
A
So
in
on
average,
you
know
if
you
look
around
the
way,
you'll
see
that
it's
about
40
resources
that
a
particular
web
page
needs
in
order
to
in
order
to
render
itself.
So
what
this
means
is
using
the
old
http
protocol,
you
had
to
make
41
different
requests,
distinct
requests
to
get
that
get
get
that
page
rendered
in
a
very
linear
fashion.
A
So
this
obviously
has
performance
implications,
and
this
is
the
problem
that
basically
http
2
solves,
but
it
solves
it
in
a
clever
way
without
changing
actually
the
api
for
http.
So
the
api
still
remains
the
same.
What
changes
is
the
plumbing
of
and
how
things
are
done
so,
instead
of
just
opening
and
closing
so
many
connections,
http
2
treats
treats
these
connections
as
a
scarce
resource.
So
basically
what
happens
is
the
browser
and
the
server
make
a
single
connection?
A
As
you
can
see
in
in
depicted
in
in
the
in
the
image
that
I
have
it's
a
single
connection
under
which
all
of
these
resources
are
being
interchanged
right,
so
the
way
this
is
done
is
to
break
a
single
connection
up
into
streams
and
exchanging
data
back
and
forth
from
the
client
on
the
server
using
these
streams.
Under
the
same
connection,
this
is
really
what's
called
multiplexing
and
it's
a
very
old
technique.
Actually,
so,
in
addition
to
multiple
streams,
each
of
these
streams
have
prioritization.
A
So
this
helps
the
browser
determine
which
of
these
resources
should
be
handled
in
a
more
important
fashion
than
the
rest.
In
addition
to
that,
http
2
comes
with
another
important
technique.
Called
server
push
so
using
this
technique.
Basically,
if
the
server
knows
that
given
a
resource,
you'll
need
many
other
resources
instead
of
the
browser
ad
hoc
requesting
each
of
these
resources,
the
server
simply
gives
those
resources
to
the
client
in
a
proactive
way.
A
Further,
reducing
the
need
for
need
for
making
explicit
requests
for
things
that
you
know
you
would
need
anyway,
as
it
so
happens.
The
http
2
protocol,
instead
of
being
text
based,
is
also
binary
based.
So
this
also,
as
you
can
imagine,
improves
performance
quite
significantly
and
http
2
also
comes
with
one
last
optimization
technique
called
header
compression,
and
what
this
is
all
about
is
basically,
when
you
have
these
closely
interrelated
resources,
the
headers
for
them
tend
to
be
the
same,
so
instead
of
exchanging
headers
for
every
single
resource.
A
A
So,
as
I
said,
and
all
of
these
changes
can
take
place
without
changing
changing
the
http
api
and
what
that
means
for
servlet,
4
and
java
developers
is
a
lot
of
these
changes,
and
a
majority
of
these
changes
can
be
done
without
actually
you
needing
to
change
anything
at
all.
So
all
that
servlet
4
really
does
is
ensure
that
a
server
for
implementation
correctly
implements
http
2
under
the
hood
and
basically,
what
this
enables
you
is
to
upgrade
your
server
engine
and
get
take
advantage
of
all
of
these
nice
performance
improvements.
A
A
You
can
take
advantage
of
server
push
yourself
and
in
fact,
if
you're,
using
something
like
jsf
jsf
is
already
designed
to
take
advantage
under
the
hood
of
of
handling
server
push
without
you
knowing
about
it.
So
if
you're
using
jsf
and
you
upgrade
you'll
automatically
be
taking
full
advantage
of
http
2
without
actually
having
to
make
any
code
changes
whatsoever.
A
A
You
think
about
it
as
intrinsic
parts
of
the
platform
so
but,
as
we
know,
part
of
the
web
standards,
acceleration
has
been
json,
so
json
actually
tends
to
be
used
as
a
defacto
serialization
platform,
far
more
often
than
it
used
to
be
in
the
past,
and
this
is
not
just
about
javascript,
but
really
all
kinds
of
client
and
data.
Interchangeable
are
really
happening
using
json,
so
json,
similar
to
java,
serialization
and
xml
in
the
past,
needs
to
sensibly
also
become
a
default
part
of
the
platform.
A
So
that
is
basically
what
the
jakarta
json
binding
api
or
simply
the
json
binding
api
does.
For
short,
it
allows
you
to
very
simply,
and
almost
by
default,
be
able
to
translate
back
and
forth
a
pojo
between
json
and
back.
So
there
is
a
small
number
of
annotations
that
will
allow
you
to
do
some
customizations
on
top
of
that,
like
json
property
and
json
transient.
A
So
these
two
annotations,
for
example,
will
allow
you
to
rename
a
field
in
a
pojo
and
json
transient,
as
the
name
implies
basically
says:
hey,
don't
part,
don't
use
this
field
for
serialization
destruction
purposes
by
default,
so
the
another
nice
thing
about
all
of
this
is
that
json
binding
is
built
into
and
tightly
integrated
with
the
platform,
including
jakarta
rest.
So
what
this
means
is
now
you
have
a
built-in
way
of
handling
anything
that
is
of
type
application
json
in
a
in
a
rest
endpoint.
A
So
one
thing
to
note
is
that
this
is
this:
did
used
to
exist
pretty
much
as
of
the
java
ee6
timeframe
for
vendors,
but
it
was
provided
in
a
vendor-specific
way.
For
example,
a
vendor
would
provide
built-in
integration
with
jackson.
Obviously,
that's
an
that's
a
non-standard
api,
whereas
json
binding
is
a
standard
api.
So
that's
the
big
difference
between
prior
to
jakarta,
the
e8
and
after
so
here's
a
simple
example
over
here.
I
simply
have
a
rest,
endpoint
simple,
rest
point
in
endpoint
that
implements
get
so
in
here.
A
What
I
can
do
is
I
can
retrieve
or
construct
a
poster
just
like
I'm
doing
here
and
return.
The
exposure
as
part
of
my
rest,
payload
and
all
I
need
to
make
sure
is
that
it
is
producing
the
application
json
type
and,
as
a
result,
what
will
happen
is
I'll
get
a
sensible,
json
representation
without
really
having
to
do
anything
integrating
third
party
libraries,
configuring
them
so
on
and
so
forth.
None
of
that
exists.
A
It
just
works
just
like
it
does,
for
a
vast
majority
of
things
in
the
in
the
jakarta
ie
platform,
so
in
addition
to
json
binding
there's
yet
another
api
that
has
been
available
in
in
the
platform
since
java
ee7
and
that
is
called
json
processing.
So,
unlike
json
binding,
which
is
a
higher
level
api
that
uses
annotations
and
projos.
A
Basically,
what
json
processing
does
is
it's
similar
to
the
older
style,
xml
processing
apis?
It
allows
you
to
programmatically
process
json,
as
opposed
to
doing
it
in
a
declarative
fashion,
and
why
would
you
do
that?
Normally,
you
would
do
that
to
when
you're,
using
ad
hoc
ad
hoc
json
processing.
That
cannot
be
determined
ahead
of
time
and
also,
if
you're
doing
minor
cases
where
binding
is
overkill.
A
There
is
also
some
other
things
done
as
well,
for
example,
this
alignment
with
yet
another
json
web
standard.
That's
called
json
patch,
merge
and
also
java
streams
alignment,
and
what
this
allows
you
to
do
is
that
it
easily
allows
you
to
convert
back
and
forth
between
java
sc
streams
and
arrays
of
of
json
and
using
this
lower
level
api.
A
A
So,
as
you
can
see
here,
this
work,
if
I
was
to
do
it
without
these
facilities,
would
require
a
lot
of
tree
traversal
traversal
of
the
document
to
find
out
where
exactly
this
element
resides,
whereas
in
this
way
it's
much
more
compact
and
it's
much
more
much
more
usable,
so
jsonpatch
is
another
important
change
that
was
brought
into
json
processing.
What
is
this
well?
A
In
the
examples
basically
jsonpatch
uses
jsonpointer
as
an
underlying
underlying
capability,
so
there's
many
different
types
of
basically
modifying
or
testing
operations,
so
things
like
add,
replace,
remove
typical
card
functionality,
moving
copying
testing,
whether
something
exists
and
so
on,
and
so
you
see
two
examples
here,
so
I'm
replacing
a
value
at
in
in
the
mobile
element
that
I
was
navigating
to
before
and
I'm
removing
the
first
element
from
from
root.
So
those
are
the
two
changes
that
I'm
expressing
in
terms
of
json
patch.
A
A
It
allows
you
to
do
a
lot
of
things
very
very
quickly
as
before,
so
you
don't
you're
not
needing
to
do
a
bunch
of
document
reversal
and
also
you
can,
because
it's
using
the
builder
pattern,
you
can
construct
a
set
of
json
patches
and
applied
them
over
and
over
again.
So
this
is
also
a
particularly
strong
capability
that
exists
within
this
api.
A
Server
7
server
center
events,
so
this
is
actually
a
part
of
html5,
so
it's
been
a
little
while
actually
since
service
and
events
were
introduced.
Initially
there
was
a
consideration
whether
to
include
this
capability
in
java,
e7
or
not,
but
ultimately
we,
basically
the
decision
was
made
to
differ
until
jakarta
e8.
A
So
this
is
useful
in
things
like
chat
applications,
for
example,
or
online
massive
on
online
multiplayer
gaming
right
where
you
need
all
these
asynchronous
messages
going
back
and
forth
from
the
client
and
the
server
and
plain
old,
vanilla,
http
right.
We
talked
about
the
http,
so
you
make
one
request
and
you
get
one
response
and
so
on
that
that
world
of
just
making
a
request
from
the
client
and
getting
a
response
from
the
server
so
in
this
world.
A
What
you
have
is
that
you
still
you
still
get
a
connection
between
the
client
and
the
server
initiated
by
the
client,
but
instead
of
getting
just
one
response,
you
get
multiple
responses
over
a
period
of
time
or
multiple
events
over
over
a
period
of
time.
So
good
example
is
something
like
stock,
tickers
or
monitoring
applications.
You
want
to
monitor
something
you
connect
up
to
the
server
and
you
say:
hey
server
I
want
to.
A
A
So
now
I
get
to
have
a
void
return
type,
so
that
means
that
I'm
not
actually
going
to
return
a
single
response.
I'm
going
to
return
a
series
of
responses
over
a
period
of
time
and
two
distinct
apis
will
help
me
with
that.
One
is
ssc
event,
sync
okay,
which
you
can
think
of
as
a
basically
long-lived
connection
between
the
client
and
the
server
under
which
I
sent
multiple
responses
or
events,
and
then
there's
a
utility
object,
called
ssc,
and
that
allows
me
to
do
things
like
very
easily
create
a
new
event
from
my
poster.
A
So
in
this
case
I'm
taking
the
entire
processing
in
a
in,
in
a
background
thread
using
the
manager
executor
facility
available
in
in
jakarta
and
then
over
a
period
of
time.
As
I
receive
stock
updates,
I'm
going
to
send
those
stock
updates
down
down
to
the
client
and
of
course
there
is
a
client
side
rendition
of
this
as
well.
A
I
won't
show
that
show
that
here
jakarta,
jakarta
security,
so
this
is
believed
or
not
a
new
standard
in
in
introduced
in
jakarta
ee-8,
and
then,
when
I
say
this,
a
lot
of
people
are
immediately
surprised.
They
say:
okay,
yeah.
This
is
such
an
old
platform,
and
why
is
this
a
new
new
api
called
jakarta
security?
A
Well
for
those
of
us
who
have
dealt
with
the
platform
for
a
long
time.
What
has
happened
with
regards
to
security
in
the
jakarta
platform.
Is
that
jakarta
ee
platform
takes
a
very
abstracted
way
of
dealing
with
security,
so
security
by
and
large
is
dealt
with
in
vendor-specific
ways
in
prior
to
jakarta
e8,
so
you
typically
secure
an
application
using
some
kind
of
vendor
deployment,
descriptor
or
more
likely
a
vendor
graphical
user
interface,
wizard
to
say,
hey.
A
I
want
to
please
take
this
application
and
secure
it
against
ldap
or
open
directory,
and
do
the
role
mappings
this
way
and
so
on,
and
basically
the
the
application
would
be
content
by
simply
saying
hey,
I
want
to
be
secured.
These
are
the
roles
that
I
recognize.
Please
secure
these
urls
and
so
on.
Right
but
the
rest
of
it
would
be
done
outside
the
application,
so
this
model
has
some
strengths
and
will
continue
to
have
some
strengths,
but
its
big
weaknesses
is
that
it
introduces
a
vendor
neutrality
or
portability
issue.
A
So
now,
if
you
go
from
one
application
to
the
other,
you'll
need
to
redo
that
work.
That
was
that
was
done
in
a
vendor
specific
way,
so
that
does
not
carry
over
from
one
implementation
to
the
other,
and
it
also
is
not
that
developer
friendly.
Let's,
let's
put
it
that
way
right,
so
developers
are
not
able
to
see
hey
what
exact
database
am.
I
am
I
security
against
and
so
on
and
so
forth.
So
the
objective
of
jakarta
is
security.
A
Is
solving
those
problems,
bringing
more
portability
allowing
developers
access
to
those
type
of
security
configurations
and
also
unifying
the
java
ee
security
concept
a
little
bit
as
well
and
we'll
talk
about
how
that's
done
through
an
example,
that's
the
best
way
of
showing
it
so,
first
and
foremost,
thanks
to
these
changes
actually
jakarta,
the
e-security
is
probably
one
of
the
simplest
way
of
securing
securing
java
applications.
Now
so
let's
say
you
want
to
secure
against
your
database.
All
you
really
need
to
do
is
throw
on
this
database.
A
A
So
let's
say
that
you
secure
your
application,
but
it's
not
against
the
database
and
it
is
not
against
your
lap.
So
what
do
you
do
then?
So
jakarta
security
provides
yet
another
capability
called
simple
identity
stores
right,
so
all
you
need
to
do
is
implement
a
cdi
bean
that
and
that
implements
this
interface
identity
store
and
basically
you'll
you'll
be
able
to
do
security,
your
own
way
using
your
own
providers.
A
So
let's
say
I
have
some
legacy
service
called
user
service,
and
then
I
can
inject
that
user
service
within
my
custom
identity
store
and
do
validation,
so
I'll
get
the
credentials
probably
use
in
username
password
form,
do
my
thing
and
then
send
over
my
credential
valuation
result
or
their
success
or
failure.
If
a
success
then
okay,
this
is
the
currently
logged
in
principal
name,
here's
their
roles
and
so
on
right.
So
you
can
completely
customize
your
security
if,
if
you
so
wish.
A
Similarly,
there
is
a
security
context
that
was
introduced
as
a
way
of
unifying
doing
security
context,
handling,
so
security
context.
Handling
in
java
e
was
done
using
different
apis
in
different
places,
so
servlet
had
one
ejb
had
one
and
so
on
so
now,
instead
of
having
all
these
discrete
apis,
you
have
the
security
context
that
you
can
inject
pretty
much
anywhere
where
cdi
is
available
and
it
will
allow
you
to
do
things
like
do
a
lookup
of
hey
who's
currently
logged
in
and
what
is
what
is?
A
What
is
their
current
role
as
opposed
to
using
different
apis
in
different
places
or
perhaps
not
even
being
able
to
use
the
api?
Let's
say
you
are
in
the
in
the
data
access
dao
layer,
whereas
just
a
a
just
cdi
will
now
be
even
there.
You
can
use
a
security
context
in
this
way
and,
of
course,
in
my
example,
I'm
using
it
in
an
interceptor.
So
you
can
apply
this
interceptor.
Basically,
wherever
cdi
is
enabled,
okay
speaking
of
cdi,
the
next
change
that
I
want
to
talk
about
is
about
cdi2.
A
You
can
now
use
cdi
anywhere
where
you
have
a
jvm,
because
you
now
have
a
standard
java,
sc
bootstrap
mechanism,
and
this
used
to
be
a
proprietary
weld
used
to
have
this
api
and
now
all
cti
implementations
will
have
this
api
and
be
able
to
do
bootstrap
in
java,
ac
environments
or
tomcat
environments.
Let's
say
to
go
along
with
that.
The
cdi
specification
was
modularized,
so
now
there's
a
core
version
and
then
a
java
ac
flavor
and
a
java
e
flavor
of
of
cdi,
that's
usable
in
different
environments.
A
You
also
have
asynchronous
events
I'll
show
you
a
concrete
example
of
this.
In
a
moment,
the
other
big
change
that
was
done
is
making
the
portable
extensions
api
a
lot
more
simpler.
So
this
is
to
encourage
even
more
ecosystem
building
around
cdi.
So
if
you
want
to
create
a
cdi,
if
you
have
a
product,
you
want
to
create
a
cdi
plugin
for
it.
A
It
should
be
as
easy
as
possible
to
do
so
using
the
portable
extensions
api
and
similarly
there
were
some
other
java
sc
alignment
that
was
done
in
cdi
as
well,
so
things
like
repeatable,
annotations
and
the
like,
so
here's
an
example
of
asynchronous
events,
so
cdi
includes
a
very
type
safe
and
simple
event:
bus
that
you
can
use.
So
this
event
was
used
to
be
synchronous
prior
to
prior
to
jakarta,
eight
in
jakarta
eight
now
you
have
the
ability
to
have
asynchronous
events,
meaning
if
you
fire
an
event.
A
This
event
will
can
be
observed,
basically
out
of
the
current
thread
right,
giving
you
a
little
bit
more
resiliency
and
a
little
bit
more
reactive
style
style,
programming
api.
So,
instead
of
invoking
fire,
you
now
invoke
fire
async
and
ins.
Instead
of
observing
an
event
using
the
at
observed
sanitation,
you,
you
absorb
the
event
asynchronously
using
the
observes
async
animation.
Okay,
relatively
simple,
simple
changes.
I
think
all
right.
So,
as
we
talked
about,
one
of
the
major
themes
for
jakarta,
e8
is
adopting
java
sc
innovations.
A
A
Okay,
you
know,
let's
make
this
non-non-breaking
and
just
work
with
the
majority
of
the
ecosystem,
and
so,
as
a
result,
a
lot
of
the
java
sc8
innovations
and
even
java,
ac,
9
and
forward
innovations
can
actually
just
be
used
in
java
e
applications,
as
is
especially
if
you're
using
it
where
it
does
not
intersect
with
the
java
e
api,
and
it's
in
your
business
logic,
that's
very
easy
to
do
so.
This
applies
to
things
like
streams,
lambdas
and
so
on,
and
even
the
daytime
api.
A
Now,
in
some
cases
you
have
to
have
built-in
support
for
these
apis
in
jakarta,
apis
themselves
and
I'll
I'll
talk
a
little
bit
about
what
each
of
these
examples
are,
but
basically
each
of
the
java
e
apis,
wherever
possible,
has
adopted
to
things
like
repeatable
annotations,
the
datetime
api
and
computable
features
and
streams.
Okay,
so
taking
a
quick
look
at
this
first
one
is
repeatable
annotations
so,
prior
to
javascript,
you
could
not
repeat
annotations.
So
in
order
to
get
around
that
you'll
have
this
concept
of
wrapper
annotations
like
named
queries.
A
You
know
these
are
all
be
invalidation
these
all
these
and
these
animations
are
all
repeatable
now,
similarly,
the
date
time
api.
So
here's
an
example
of
where
you
have
to
have
some
kind
of
change
in
the
in
the
jakarta
api
to
make
things
work.
So
let's
say
for
a
second
that
you
have
an
entity
and
in
the
entity
you're
choosing
to
model
a
data
bit
of
data.
Let's
say
in
my
case
when
an
accident
occurred
not
using
the
old
java.
Util
time
date
objects,
but
using
the
new
date
time.
A
Api
objects,
so
in
jakarta,
e8
the
jpa
will
actually
recognize
this
natively
and
be
able
to
translate
back
and
forth
between
the
database
and
new
transparently,
without
you
needing
to
do
anything
at
all.
Like
writing.
Custom
converters.
Similarly,
annotations,
like
the
beam
validation
annotations,
will
also
recognize
how
to
handle
the
daytime
apis.
So
similar
changes
have
been
done
in
in
jsf
as
well,
where
you
need
to
potentially
render
and
render
and
convert
these
newer
java
sea
daytime
api
objects.
A
So
completable
features
are
basically
the
promises
of
java.
If
you
haven't
looked
at
it,
I
won't
go
into
it
in
detail
quite
yet,
but
I
I
urge
you
to
take
a
look
at
what
completed
features
are
so
computable
features
are
a
hybrid
between
the
old
style
futures
that
can
be
prone
to
premature
blocking
and
callbacks,
so
it
provides
the
benefits
of
both.
So
it
is
completely
non-blocking.
A
It
is
composable,
just
like
you
have
in
in
in
the
in
the
example
here,
and
it
also
allows
you
a
relatively
fluent
api
to
do
asynchronous
reactive
processing,
especially
in
a
in
a
complex
interaction
like
this
one.
So
one
of
the
areas
that
I'm
showing
an
example
of
here
is
where
this
comes
in
handy
is
the
jax
rs
client
api.
A
So
now
you
can
use
use
the
computable
features
in
order
to
do
this,
because
the
jakarta
rest
api
in
has
introduced
this
rx
method,
okay,
the
so
that
will
allow
you
and
allow
your
return
of
a
complete
and
completion
stage,
as
opposed
to
doing
things
using
callbacks
and
futures,
which
is
also
supported
in
jakarta.
The
rest,
so
streams
are
also
another
thing
that
was,
that
was
adapted.
Two
specific
examples
of
this
one
is,
as
I
mentioned,
the
the
json
processing
api.
A
A
A
Some
other
changes
that
I
won't
have.
I
won't
talk
about
in
detail
and
in
fact
this
is
not
even
a
complete
list.
There's
many
other
minor
changes
that
were
done
in
jakarta,
8,
all
in
all,
it's
a
very,
very
significant
release
and
honestly,
a
very
feature,
complete
release
that
has
kept
the
platform
relevant
for
a
long
time,
especially
thanks
to
something
like
microprofile
which
we'll
talk
about
in
a
second
but
basically
for
monolithic
applications.
A
You
have
a
very
feature
complete
platform,
so
you
have
things
like
websocket
native
integration
with
jsf
or
jakarta
faces
greater
cdi.
Integration
with
jakarta
faces
so
being
able
to
inject
many
more
faces.
Artifacts
like
the
faces
context.
For
example,
more
bean
valuation,
important
bean
value
constraints
were
added.
In
my
example,
I
was
showing
an
example
of
just
one
client
server
based
communication.
A
A
Okay.
So,
let's
move
on
we'll
talk
about
jakarta,
ee-8
implementations,
so
actually
there's
a
number
of
these
already.
The
big
one
that
is
missing
on
this
list
is
probably
weblogic
and
that's
coming
soon
as
well.
So
you
already
have
a
lot
of
places
where
you
can
begin
to
use,
jakarta,
e8
and
begin
to
begin
to
adopt
and
move
to
this
platform,
the
full
list
of
compatibility
you
can
find
on
this
website.
A
A
There
was
some
removal
of
the
older
technologies
that
were
slated
to
be
removed
and
there's
really
no
sense
in
moving
these
moving
these
forwards.
So
example
of
this
is
jack's
rpc,
for
example,
so
we
also,
there
is
also
very
likely
going
to
be
some
editions.
So
this
is
because
java
sc
deprecated
some
of
these
technologies,
so
they
need
to
be
re-added
into
the
platform
and
it's
primarily
adopted
not
to
end
users
necessarily
but
to
the
ecosystem,
the
vendor
ecosystem
and
and
the
implementation
ecosystem,
so
that
they
have
a
chance
to
absorb
this.
A
This
renaming
change.
So
there
are
some
mechanisms
like
eclipse
transformer
that
can
make
this
transition
easier
as
well.
So
this
does
not
necessarily
need
to
be
a
very
difficult
transition,
so
the
milestone
release
for
jakarta
e9
is
out,
which
means
you
can
begin
testing
jakarta,
e9
transition
yourself,
but
your
contribution
is
also
very
welcome.
So
this
is
the
very
first
time
where
end
users
can
and
are
very,
very
heavily
involved
in
the
jakarta
e9
milestone,
and
you
can
still
do
that.
A
So
the
way
you
do
that
is
you
get
involved,
and
we
in
the
jakarta
ambassadors
actually
have
a
guide
to
help
you
with
this.
A
lot
of
people
have
used
this
guide
already.
You
can
also
use
it
by
following
this
url,
so
the
discussion
would
not
be
complete
without
talking
about
micro
profile,
so
micro
profile
happened
at
about
the
same
time
where
jakarta,
eight
was
being
formulated
and
the
technology
was
being
moved
from
the
jcp
to
to
the
eclipse
foundation.
A
Obviously,
this
this
transition
was
going
to
take
some
time,
so
the
platform
needed
to
move
forward
so
a
way
of
keeping
the
platform
and
ecosystem
responsive,
especially
to
changes
like
microservices
is
this
effort
called
microprofile,
and
this
is
basically
a
set
of
open
standard
specifications
also
part
of
the
eclipse
foundation.
So
you
can
take
a
look
at
the
this
technology
yourself
by
logging
on
to
microprofile.io,
but
it
solves
use
cases
very
specific
to
microservices,
often
right.
A
So
these
are
things
like
open,
tracing
or
distributor,
tracing,
open
api
or
swagger
documentation
having
type
safe
rest
clients,
where
you
don't
mind
a
little
bit
more
tight
coupling
between
a
rest
client
and
an
address
server.
Centralized
configuration
outside
of
your
microservices
doing
things
like
fault
tolerance,
to
increase
the
residency
of
your
micro
services,
metrics
to
do
centralized
monitoring
of
your
microservices
jwt
operation.
In
order
to
do
single,
sign-on
across
microservices
health
checks
to
check
for
the
health
and
resiliency
of
each
of
your
micro
services,
and
so
on,
so
micro
profi.
A
So
now
that
there
are,
there
is
jakarta,
and
now
that
java
e
has
moved
to
the
eclipse
foundation,
it's
an
open
question:
what
happens
with
micro
profile
as
a
technology?
Does
it
stay
on
its
own?
Does
it
get
merged
with
java
ee?
Does
it
get
merged
with
jakarta
e?
What
happens
with
it,
because
it's
two
similar
things
that
more
or
less
serve
the
same
audience?
A
A
So
there's
also
not
just
a
a
desire
to
merge
these
technologies
together,
but
also
make
them
look
the
same.
Make
them
look
consistent
under
under
a
single
umbrella.
So
if
you
have
opinions
on
this,
this
is
a
pretty
hot
topic
that
is
not
yet
to
be
completely
determined
and
you
should
provide
your
input
just
like
I
have
just
like
many
other
people
have.
You
should
not
be
shy
in
providing
your
input
of
what
you
would
like
to
see
between
these
two
technologies:
jakarta
e
and
microprofile,
okay.
A
So
now,
let's
talk
a
little
bit
about
jakarta
e
10
possibilities,
so
we
actually
have
a
reasonably
good
view
of
this
in
the
jakarta
ambassadors,
because
we
feel
that
there's
a
lot
of
long-standing
things
that
could
be
addressed
by
the
technology
that
has
sort
of
not
been
addressed
because
of
all
this
transition
work.
So
here's
some
example
of
this
and
we
actually
hope
to
publish
a
a
guide
on
this
as
well
and
part
of
the
guide
is
going
to
be.
A
You
know
your
contribution
into
these
things
and
what
are
these
things
that
that
we
see
at
least
on
our
side?
So
here
are
some
of
the
big
big
ticket
things
so
jakarta.
Nosql
is
a
standard
for
allowing
nosql
access
to
jakarta
ee
applications.
So
this
used
to
be
called
eclipse,
j,
no
sequel.
Now
it's
called
jakarta,
no
sql,
it's
it's
pulled
within
the
jakarta
umbrella.
So
quite
possibly
this
could
be
possibly
an
optional
part
of
jakarta,
e10,
jakarta
mvc!
A
These
very
clearly
are
common
needs,
doing
more
javasc
alignment,
so
there's
a
little
bit
left
to
be
done
specifically
in
jakarta,
concurrency
adopting
things
like
computable
features
and
maybe
introducing
java
records
in
in
alignment
in
in
jakarta
persistence.
So
those
are
some
of
the
areas
where
more
javascri
alignment
could
take
place,
potentially
adopting
the
java
platform
module
system
into
into
jakarta.
That's
yet
another
javascript
alignment
feature
that
you
can
think
of
more
cdi
alignment.
So
there's
some
bits
and
pieces
of
the
platform
that
could
use
more
of
this.
A
So
batch
is
a
good
example
that
could
use
more
usage
of
cdi.
Jakarta
rest
is
another
example,
and
one
of
the
key
things
that's
in
micro
profile
today,
that
is
a
very
common
need,
and
that
is
externalized
configuration
configuration
outside
of
your
application,
simple
things
like
environment
variables
and
so
on
a
lot
of
those
capabilities.
A
You
can
argue
that
actually
belong
and
is
a
common,
very
common
thing
that
can
be
utilized
even
by
jakarta
e
apis
themselves,
like
jakarta,
persistence
and
jakarta
messaging.
So
one
possible
answer
here
is
to
include
that
capability
in
in
in
the
jakarta
e10
umbrella.
Somehow,
okay,
so
I
talked
about
the
jakarta
e
ambassadors.
I'll
talk
about
it
a
little
bit
more
here,
so
we
are
basically
a
grassroots
entity.
We
are
not
completely
vendor
neutral,
not
associated
with
the
with
the
eclipse
foundation.
A
The
eclipse
foundation
is
gracious
enough
to
allow
us
their
branding
and
to
recognize
us
as
a
group,
but
other
than
that
we
are
independent
of
the
of
the
eclipse
foundation.
Also,
our
job
is
basically
to
promote
and
move
forward,
jakarta,
ee
and
the
community
in
whichever
way
that
we
can
by
evangelizing
it
just
like
I'm
doing
at
the
moment
and
hopefully
you'll
consider
doing
keeping
track
of
things,
helping
contribute
and
encouraging
people
to
contribute,
helping
shape
the
direction
to
make
sure
things
are
aligned
with
user
needs.
A
Those
are
all
of
the
things
that
that
we
do
in
the
chakatay
ambassadors.
Anyone
can
be
one,
you
know,
there's
no
special
capability
that
is
necessary
here.
You
can
find
out
more
about
by
logging
on
to
jakarta
ambassadors,
dot,
io
or
following
us
on
twitter,
okay,
so
jakarta,
eight
is
very,
very
significant.
A
All
right.
So
here
are
some
resources
that
I'll
finish
up
with.
Obviously
we
talked
about
the
prior
resources
like
the
getting
started
guide,
the
jakarta
official
website,
the
jakarta
ambassador's
website,
but
other
than
that
there
are
some
other
resources
that
you
can
follow
to
learn
more
about
the
technology,
so
one
very
good
place
is
jakarta
one
especially
jakarta
one.
The
existing.
The
first
edition
will
give
you
a
lot
of
overview
in
all
of
these
technologies
in
much
greater
detail.
A
It's
close
to
24
hour
hours
of
content,
so
feel
free
to
take
a
look
at
there.
The
best
place
to
get
involved
initially,
aside
from
the
jakarta
ambassadors,
is
jakarta
e
community
area.
So
if
there's
one
a
foundation,
alias
that
you
follow
as
somebody
interested
in
the
technology,
this
is
the
one
you
can
also
follow.
The
jakarta
official
twitter
handle
there's
good
information
that
comes
out
there
and
there's
also
a
program
called
jakarta
tech
talks.