►
Description
Presentation from the Eclipse Foundation Virtual Booth @ J4K Virtual Conference - October 13-14, 2020.
Check out the Jakarta EE Website for all things Cloud Native Java related: https://jakarta.ee/
Get Social!
Subscribe: https://www.youtube.com/user/EclipseFdn
Follow us on Twitter: https://twitter.com/JakartaEE
Like us on Facebook: https://www.facebook.com/JakartaEE/
Join us on LinkedIn: https://www.linkedin.com/groups/13597
Tag us: #JakartaEE
Want more great Eclipse Community webinars? Become a member of our Jakarta Tech Talks Meetup: https://www.meetup.com/jakartatechtalks
A
I'm
going
to
go
ahead
and
start
by
just
presenting
to
you.
You
know
this
deck
that
I
have
and
this
deck
basically
talks
about
the
current
and
future
of
java,
jakarta
e
as
a
technology.
So
a
bit
a
little
bit
of
both.
My
name
is
raz
rahman.
If
you're
not
familiar
with
me
in
my
day
job
I'm,
I
work
for
microsoft
as
principal
program
manager
for
java
on
azure.
A
So
basically
I
try
to
make
sure
that
you
know
everything
that
microsoft
is
doing
is
in
the
benefit
of
java
developers
and
java
developers
can
be,
can
have
a
good
experience
on
azure,
but
actually
today,
I'm
I'm
representing
more.
The
jakarta
ambassadors
and
I'll
talk
a
little
bit
about
what
the
jakarta
ambassadors
are.
You
know
outside
of
my
day,
job,
I'm
an
author.
I
do
blog
and
I
do
speak
in
places
like
this
so
feel
free
to
get
in
touch
with
me
at
any
point
in
time.
A
Okay,
so
hopefully
you've
heard
by
now
you've
heard
of
jakarta,
and
if
you
haven't
heard
of
jakarta
basically
java
jakarta
is
the
technology
formerly
known
as
java
ee.
So
java
e
was
transitioned
from
the
jcp
to
the
eclipse
foundation,
there's
nothing
per
se
wrong
with
the
jcp.
I've
worked
with
jcp
for
a
number
of
years,
but
the
jcp
at
the
end
of
the
day
is
not
a
separate
organization.
It's
owned
by
oracle.
It's
just
a
division
of
oracle.
A
If
you
will
and
ultimately
everything
that
goes
on
in
the
jcpe,
a
majority
of
it
is
actually
owned.
The
ip
is
owned
by
oracle
and
some
prior
to
that
when,
when
the
gcp
bar
spot
a
sun
as
opposed
to
that
model
in
the
with
the
jakarta
e
and
moving
things
moving
to
the
eclipse
foundation,
really
it
is
a
separate
entity.
You
know
it's
a
it's,
not
a
for-profit
organization.
It's
a
non-profit
organization
whose
core
mission
is
to
foster
open
standards
and
open
source
and
and
no
one
really
owns
the
ip
right.
A
A
So
what
that
means
is
completely
open
governance,
open
source,
even
all
the
way
down
to
the
compatibility
testing
for
years,
the
tck
or
the
compatibility
test
kit
for
for
java
e
was
close
source,
not
open
source
that
is
open
source
now
right.
So
it's
a
it's
a
completely
open
regime.
If
you
want
to
be
jakarta
compatible,
all
you
need
to
do
is:
go
and
download
the
tck
and
run
the
tck
and
say
hey.
A
There's
still
some
process,
though
this
is
not
like
just
an
open
source
project,
if
you
will
so,
there
is
still
a
well-defined
specification
process.
So
all
of
the
things
that
were
there
before
the
good
parts,
like
you
know,
having
the
specification
process
having
clear
ip
flow
being
vendor
neutral
and
being
able
implementation
neutral.
A
Anyone
can
contribute
and
have
a
significant
impact
on
jakarta,
and
this
is
an
opportunity.
It's
a
historic
opportunity
of
having
such
a
large
impact
on
such
an
important
part
of
the
java
ecosystem.
So
it's
very
very
important
that
we
all
understand
it
and
hopefully
contribute
towards
the
future
of
this
technology.
A
So
if
you
want
to
find
out
more
about
jakarta,
the
best
place
to
do
that
is
the
website
that
I
listed
here,
it's
jakartha.e
and
you
can.
You
can
feel
free
to
log
on
there
and
find
out
whatever
information
that
you
would
like
now.
One
thing
that
I
I
forgot
to
mention-
and
I
should
say,
is
this
particular
slide
deck
is-
is
actually
intended
to
be
a
shared
right.
So
in
other
words,
if
you
want
to
present
this
talk,
you
can
feel
free
to
take.
A
Take
the
slide
deck
and
present
this
talk.
So
the
source
is
available
on
the
jakarta
ambassador's
website.
You
can
download
it.
You
know
you
can
certainly
attend
the
talk
today.
You
can
get
help
from
people
like
me
and
other
ambassadors,
and
maybe
you
can
present
this
talk
at
a
conference
or
a
java
user
group,
or
even
internally
at
your
own
company.
A
So
in
this
slide
we
want
to
talk
a
little
bit
about
the
evolution
of
jakarta
as
a
technology.
It's
a
certainly
not
a
young
technology
has
been
around
for
quite
a
while.
Basically,
since
the
since
the
mid
90s,
it
started
his
life
as
jpe.
I
don't
know
how
many
people
still
remember
what
jpe
is,
but
it
stands
for
java
professional
edition
right
so
in
in
the
very
beginning
that
was,
that
was
the
acronym
that
was
used
for
java
e.
A
Then
it
become
j
to
e
and
it
remained
j
to
e
for
some
years,
and
this
is
where
a
lot
of
people
still
have
an
an
idea
of
of
j2e
or
java
e
they're
kind
of
still
thinking
about
j2e
as
a
technology,
but
the
reality
is
the
technology
set
has
moved
on
from
that
for
for
a
very
long
time
right.
So
now
it's
this
has
been
java.
E5
java,
e6
java,
7
java
e8,
and
these
are
all
technology
sets
that
that
have
evolved
and
evolving
right.
A
A
Jakarta
e8
is
the
first
release
under
the
eclipse
foundations
on
the
under
under
open
source
governance
model
so
other
than
the
governance
model.
It's
actually
basically
the
same
technology
as
java
e8,
so
java,
e8
and
jakarta
e8
are
binary,
compatible
they're
the
same
technology
set.
The
only
difference
is
that
jakarta
38
has
a
completely
open
tck,
whereas
not
the
case
with
java
e8.
A
So
that's
been
actually
out
for
about
a
year
now,
so
you
can
actually
begin
to
add
up
jakarta
eight
and
I
hope
some
of
you
already
have,
which
brings
us
to
jakarta
a9
and
we're
really
at
the
cusp
of
jakarta.
Almost
all
of
the
work
has
been
done.
It's
any
day
now
it
will
be
released.
In
fact,
the
first
candidate
release
is
already
out
there.
It
has
been
out
there
for
a
few
months
now,
so
you
could
begin
to
evaluate
you
know
adopting
jakarta
eight
as
well.
A
A
So
this
is
truly
owned
by
the
community
community
by
in
all
senses,
including
all
of
the
code
base,
including
the
naming,
including
branding
including
namespace
and
everything,
and
that
really
primes
things
to
move
it
forward
and
move
it
forward
onto
jakarta
ee
10
going
forward
and
we'll
talk
a
little
bit
about
what
exactly
is
in
jakarta
e10,
maybe
towards
the
end
of
this
presentation
or
slightly
thereafter.
So
we
have
a
couple
of
hours
and
I
do
plan
to
keep
it
a
little
bit
interactive.
A
You
know
at
least
I
hope
you'll
be
encouraged
to
you
know,
interact
with
me
and
answer
any
questions
that
you
might
have.
So
I
think
I
would
like
to
stop
here
and
and
basically
take
any
questions.
You
know
engage
how
you
all
are
doing
before
we
jump
into
this
slide,
which
is
about
jakarta
e8.
So
what
I
found
is
because
of
all
of
the
things
that
have
happened
between
the
transition
with
the
transition
from
java,
8
and
jakarta.
38
java,
jakarta,
38
actually
hasn't
been
evangelized
very
much.
A
So
not
a
lot
of
people
actually
know
what
is
possible
today,
and
that's
really
a
shame,
because
jakarta
aid
at
heart
is
a
very,
very
capable
platform,
especially
if
you're
writing,
mostly
just
a
monolithic
application.
It's
a
really
good
platform
platform
to
go
with
so
we'll
we'll
see
why
that
is
in
a
second
and
we'll
also
see
what
the
changes
are
in
the
platform.
But
before
we
do
that,
let
me
just
gauge
what
is
going
on
and
also
maybe
give
you
an
opportunity
to
do
a
little
bit
of.
A
A
Okay,
so
I
don't
see
any
questions
posted
as
of
yet
so
we're
just
going
to
continue
moving
forward.
I
hope
I
hope
that
you
will
have
some
questions
and
then
you
will
post
your
questions.
Please
do
post
your
questions
on
the
chat
and
then
you
know,
maybe
you
can
have
a
dialogue
again.
I
can
bring
you
on
screen
and
you
know
we
can
have
a
real-time
chat.
You
know
just
like
we
would
at
a
booth.
A
So
these
are
the
things
that
are
there
in
jakarta,
eight,
first
and
foremost,
a
lot
of
web
standards
alignment.
So
a
lot
of
things
are
actually
happening
these
days
outside
of
the
java
ecosystem,
in
particular
the
the
javascript
ecosystem
and
believe
me,
this
javascript
ecosystem
is
also
is
also
a
very,
very
vibrant
and
then
there's
a
lot
of
things
going
on
just
in
in
the
in
the
in
that
ecosystem
as
well.
So
these
are
things
like
http
2
server,
send
events
json.
A
I
don't
know
how
many
people
have
know
this,
but
json
is
actually
a
w3c
standard
as
well.
So
all
of
these
things
are
evolving
and
we
need
java
developers
to
be
to
be
enabled
so
that
they
can
actually
take
advantage
of
all
of
these
innovations.
So
these
sorts
of
changes
in
jakarta.
The
aim
is
exactly
that.
A
A
But,
aside
from
cdi
too
the
standard
itself,
other
parts
of
jakarta
actually
has
has
absorbed,
absorbed,
bits
and
pieces
of
this
technology
as
well
right,
so
other
other
technologies,
like
jsf
management
faces
all
of
the
all
of
these
have
made
their
own
alignment.
So
some
examples
of
this
is
that
the
jsf
management
model
was
entirely
pruned
right
in
favor
of
cdi.
Now
you
can
inject
more
cdi,
artifacts
in
as
as
jsf
injectables
right.
So
all
of
these
things
like
faces
context,
you
no
longer
need
to
look
those
up.
A
A
I
know
one
thing
that
I'll
notice
and
I'll
note
here
is
those
acronyms
that
we
used
to
use
they're
actually
no
longer
in
use
anymore,
so
we
used
to
say
things
like
jpa
and
jax,
rs
and
and
and
jsf
and
the
like.
So
in
in
jakarta.
What
has
happened
is
we've
also
dropped
all
these
acronyms
right
and
also
this
is
part
of
that
same
concept
of
decoupling,
the
branding.
So
now
you
have
full
names
right.
So,
instead
of
saying
jpa,
you
can
simply
say
persistence
or
jakarta
resistance.
A
You
can
simply
say
jakarta
faces.
You
can
simply
say
jakartha
rest
right,
so
that's
that's
the
model
that
you'll
see
actually
see
me
following
in
this
slide
deck
as
well.
Now,
simplicity
is
another
theme,
and
simplicity
has
been
a
theme
even
prior
to
java
e6.
It's
been
a
theme
since
java
e5,
so
you
know
the
biggest
example
of
this
in
this
case
is
security,
so
we
always
want
to
take
a
look
at
every
part
of
the
platform
and
make
sure
that
it
is
as
simple
as
possible.
A
So
we'll
talk
about
what
the
security
simplifications
are
a
little
bit
later
in
the
presentation
and
the
other
bit
of
simplicity
is
pruning
the
ejb
model,
so
we
basically
got
rid
of
some
of
the
really
old
stuff
in
ejb,
for
example
the
jax
rpc
bindings
and
the
nttp
in
bindings,
so
those
have
officially
been
pruned
as
a
jakarta,
e8
and
finally,
jakarta.
Yi
has
always
made
a
point
of
adopting
innovations,
not
only
from
java,
I
see
actually
from
the
larger
ecosystem,
but
but
most
certainly
from
javascript
right.
A
So
some
key
examples
of
this
is
things
like
annotations.
I
don't
know
how
many
of
you
know
this,
but
java
e5
was
actually
the
main
technology
to
bring
annotations
into
the
mainstream.
All
of
the
other
frameworks
and
all
the
other
technologies
were,
after
that,
after
java
e5
adopted
java,
adopted
the
concept
of
annotations
and
depend
and
pose
your
modeling
essentially
so.
Similarly,
java
sc8
also
has
some
very
good
innovations.
A
So
these
are
things
like
repeatable
annotations,
daytime
api
streams,
completable
features,
in
fact,
things
like
repeatable
annotations
were
specifically
designed
for
adoption
into
interjacy,
but
all
of
these
other
good,
solid
innovations
jakarta.
You
also
needed
to
take
advantage
of
right
so
that
again,
those
those
technology
use
cases
become
mainstream
and
become
fully
available
to
enterprise
java
developers.
A
So
some
of
the
technologies
that
have
adopted
in
this
way,
the
java
sc8
features
are
jakarta,
faces
check
out
the
persistence
rest
and
be
invalidation
and
we'll
see
that
in
a
moment
how
that
is
as
well,
okay.
So
now,
let's
begin
a
general
tour
of
jakarta
e8,
so
the
best
place
to
start
this
tour
is
actually
the
the
servlet
specification
or
jakarta
servlet
4..
A
This
is
one
of
the
fundamental
foundationally
important,
probably
the
one
of
the
most
important
things
that
are
in
jakarta,
eight
and
as
to
why
you
should
really
consider
adopting
it
and
the
key
objective
in
servlet
4
is
really
adopting
http
2
support
right
that
that's
the
that's
the
primary
thing.
That's
the
that's
the
reason
for
for
having
the
standard,
and
if
you,
if
you
haven't
seen
http
2,
you
really
should
right.
So
this
has
been
a
long
time
in
the
making.
A
It's
almost
the
first
revision
of
the
http
specification
in
almost
15
years,
and
its
basic
objective
is
to
align
the
protocol
with
the
way
the
web
is
today
right.
So
in
order
to
understand
what
these
changes
are,
you'll
have
to
take
a
time
machine
back
trip
back
to
me
if
you're
about
15
years
ago
in
the
very
beginning
of
the
web,
when
you
had
things
like
nsca
mosaic
or
perhaps
netscape
right.
So
how
did
the
world
look
like
back
then?
How
did
the
web
look
like
back
then?
A
So
the
web
of
that
age
looked
a
lot
like
a
set
of
wikipedia
pages.
So
if
you
look
at
wikipedia
today,
that's
that's
the
web
of
you
know
basically
the
early
early
90s
or
even
before
that
right.
So
it's
a
basically
a
set
of
pages
right.
So
you
you
yeah,
you
pull
up
a
page
and
it's
mostly
self-contained.
A
It's
just
a
bunch
of
text,
there's
a
little
bit
of
text
formatting
and
that's
really
about
it.
There's
not
a
lot
of
images,
maybe
one
or
two
images
here
and
there
and
principally
text
and
hypertext
right.
So
you
click
on
one
thing
and
then
you
go
to
another
page.
That
looks
exactly
the
same
way
like
it's
a
bunch
of
text,
a
little
bit
of
images
and
hyperlinks,
and
that's
funny
so
in
that
world.
The
model
that
http
1.1
followed
really
made
a
lot
of
sense
right.
A
So
in
http
1.1,
it's
really
based
on
single
request
and
single
response
right,
so
you
make
a
request
to
a
page.
The
the
server
gives
you
that
page
and
if
you
happen
to
need
an
image,
you
make
another
request
and
you
get
the
image
back,
and
that
works
perfectly
fine
right
in
that
word
now.
If
you
look
fast
forward
back
to
where
we
are
today,
the
web
of
today
looks
very,
very
different
than
the
web.
The
way
the
web
used
to
look
like.
A
So,
if
you
so
google
did
a
little
bit
of
a
study
on
this,
and
basically
they
found
out
that,
on
an
average
page
there's
about
40
different
resources
that
that
page
depends
on
to
render
itself
right.
So
these
are
things
like
css,
javascript
images,
video
embedded
content
and
the
like
right.
So
what's
happening
is
using
http
1.1,
it's
a
fundamental
bottleneck
right,
there's
a
paradigm
mismatch
and
that
paradigm
mismatch
causes
a
lot
of
performance
issues
or
at
least
perceived
performances.
A
So
basically,
what
http
do
does
is
that
it
breaks
down
that
fundamental
paradigm
and
says:
okay,
let's
reimagine
the
protocol,
in
the
way
that
it
would
make
sense
in
today's
world.
So,
first
and
foremost,
the
main
thing
main
changes
are
that
it
no
longer
opens
up
a
connection
again
and
again,
there's
no
longer
a
a
set
of
requests
and
responses
that
happen.
It's
really
just
one
connection
right
that
open
or
that
is
open
once
between
the
client
and
the
server.
A
As
you
can
see
in
my
in
my
little
diagram
here
and
basically,
you
reuse
the
same
connection
to
exchange
a
bunch
of
information,
namely
a
bunch
of
logical
resources
broken
down
by
stream
right
and
for
those
of
you
who
are
familiar
with
tcpip.
This
is
a
very
normal
model
right.
This
is
the
canonical
model
of
how
tcp
actually
works
right
as
you
break.
You
have
one
connection
and
you
break
things
down
into
various
streams,
each
stream
representing
your
resource.
A
So
this
is
really
how
http
2
works,
and
not
only
does
it
work
this
way.
Another
parallel
with
tcp
is
that
it
is
no
longer
a
text-based
protocol.
It's
actually
binary
based
protocol
right,
which
again
improve
it,
goes
towards
improving
performance
by
essentially
eliminating
serialization
and
destabilization
overhead
on
both
the
client
and
the
server
brand.
A
In
addition
to
that,
there's
other
optimizations.
So
there's
things
like
when
you
have
these
multiple
screens.
Each
of
these
streams
is
actually
given
a
priority
right.
So
maybe
the
text
and
the
body
of
the
of
of
the
request
is
given
more
priority,
as
opposed
to
images
that
are
maybe
getting
given
slightly
less
priority
right.
So
the
the
server
and
client
don't
need
to
open
up
sequential
connections.
They
can
open
up
as
sort
of
parallel
streams
and
then
prioritize
those
streams
accordingly,
there's
also
something
called
header
compression.
A
So
this
is
based
on
the
observation
that
when
you
have
a
set
of
related
resources,
the
http
headers
are
exchanged
between
the
client
and
the
server
actually
mostly
the
same.
They
don't
differ
very
much
right.
So
taking
advantage
of
that
fact,
you
can
eliminate
some
of
the
redundant
headers
and
only
exchange
things
that
actually
make
sense.
So
maybe
things
like
the
name
of
the
resource
or
the
size
of
a
particular
particular
resource,
and
that's
really
about
it
right.
A
So
that's
what
about
header
compression
and
the
final
notable
optimization,
that's
in
http
2
is
something
called
server
push,
and
what
this
is
is
that
taking
advantage
of
the
knowledge
that
the
server
has
that?
Okay,
if
you
want
to
load
this
page
you're,
going
to
need
all
of
these
other
dependent
resources,
so
instead
of
the
browser
parsing
through
that
page
and
making
those
requests
one
by
one,
the
server
just
says:
hey
you
requested
this
page.
I
know
you're
going
to
need
all
these
resources
here.
A
They
are,
I'm
going
to
push
it
to
you
into
the
cache
right
away
so
that
you
don't
have
to
explicitly
request
it
and
the
moment
you
need
it.
It
will
just
be
there
for
you.
So
these
are
all
that's
what
what
server
push
is
about
now,
you'll
notice,
another
important
thing
about
http
2
is
that
it
actually
does
not
change
the
api.
The
http
2
api
looks
exactly
the
same.
A
All
of
the
changes
are
mostly
in
the
implementation
layer
right
so
in
in
how
the
api
is
implemented.
So
what
that
means
for
servlet
is
that
servlet
4
does
not
actually
need
to
change
its
api
very
much
right.
So
all
it
really
needs
to
do
is
guarantee
that
a
servlet
4
implementation
is
going
to
correctly
implement
http
2
and
that's
actually
very
important
right.
So
when
somebody
is
getting
certified
with
servlet
you're
guaranteed
that
you
have
a
good
implementation
of
http
2.,
the
one
api
change
is
that
server
push
right.
A
So
in
the
server
push
you
can't
do
that
automatically.
You
do
need
to
take
a
proactive
step
to
flush
down
those
resources
right
those
dependent
resources,
but
that
is
also
opt-in
right.
So
you,
you
need
to
explicitly
make
a
change
to
your
code
to
take
advantage
of
that
feature.
If
you
don't
add
that
code,
you
know
it
you
just
nothing
happens
right.
It's
a
non-breaking
chain,
non-breaking,
update
survey,
4.
A
and
actually,
if
you're,
using
something
like
jsf
or
a
higher
level
web
framework.
Jsf
actually
takes
care
of
server
push
under
the
hood,
because
jsf
knows
what
the
dependence
resources
are.
So
it
will
do
the
server
push
on
your
behalf
again
without
you
needing
to
make
any
changes.
So
if
you
have
a
jsf
implementation
and
you're
upgrading
to
jakarta,
38
you're
immediately
getting
the
benefit
of
server
push
without
making
any
code
changes.
A
So
google
did
again
a
little
bit
of
a
research
on
the
performance
impact
of
some
of
this
and
it
actually
improves
perceived
performance
by
the
end
user
by
about
five-fold
right.
So
that's
a
that's.
A
pretty
significant
performance
improvement,
largely
without
making
needing
to
make
any
core
changes.
A
So
json
binding
is
another
very
important
change
that
was
introduced
in
jakarta
eight,
so
this
is
basically
a
brand
new
api
that
that
was
introduced
and
it's
important
to
understand
and
understand
the
context
of
why
this
api
was
introduced
right.
So,
if
you
look
at
jakarta,
ee
or
even
java
ac
today,
it
actually
comes
with
a
set
of
protocols
that
allows
you
to
serialize
and
deserialize
data,
in
other
words,
take
data
from
a
file
system
or
take
take
data
from
an
external
system
and
consume
it
within
java
and
vice
versa.
A
So
some
of
these
civilization
mechanisms
are
java.
Serialization
is
one
of
them,
of
course,
but
also
xml
right,
xml
is
baked
into
the
into
the
platform,
so
you
don't
have
to
do
anything
else.
It's
just
sort
of
there
with
the
recognition
that
okay,
this
is
a
first
class
data
format
that
you
need
to
support
for
server-side
java
developers.
A
Now
in
today's
world,
json
has
largely
displaced
everything
else
as
the
data
serialization
format,
and
it's
not
just
about
javascript
right
pretty
much.
Everybody
has
agreed
that
this
is
a
a
data
format
that
they
want
to
use
in
order
to
do
do
detain
data
interchange
on
the
web.
Okay.
So
when
that
happens,
you
need
to
do
something
in
in
the
server
in
the
server
side
technology
platform.
A
A
The
idea
is
that
you
should
be
able
to
very
easily
transform
between
back
and
forth
between
json,
without
needing
to
do
anything
at
all
and
you'll
see
that
in
the
example,
there
are
a
small
set
of
annotations
that
allow
you
to
basically
overwrite
default
behavior
right,
so
maybe
rename
a
property
or
mark
something
as
transient
so
that
it's
it's
not
actually
sent
out
in
the
wire
right.
Those
are
the
kind
of
changes
that
kind
of
annotations
that
are
there,
but
by
and
large
the
idea
is
it
just
works
with
approaching
right.
A
In
fact,
this
kind
of
thing
was
available
as
of
java
e7
in
most
most
run
times
the
json
binding,
but
what
it
was
is
that
they
did
this
with
proprietary
apis
non-standard
apis
like
jackson.
So
in
this
case
you
don't
you
don't
have
any
dependencies
on
jackson.
The
dependency
is
essentially
on
a
standard
based
api.
Instead
that
allows
you
to
do
port
from
one
runtime
to
the
other
very
easily,
okay.
So
here's
an
example.
The
the
simple
example
is
that
I
have
a
restful
endpoint.
A
It
has
a
it,
consumes
a
get
request
and
produces
an
application
json.
As
you
can
see,
it's
producing
the
person
pojo.
I
don't
need
to
do
anything
at
all.
I
just
have
a
pojo.
I
do
whatever
I
need
to
do
for
the
pojo
and
I
return
it
and
it
automatically
translates
into
a
sensible
default
json
output
because
of
the
of
the
jakarta
json
binding
api.
A
Okay.
So,
prior
to
jakarta,
json
binding
there
was
another
api
called
jakarta,
json
processing
that
was
introduced
in
java
ee7.
So
this
api
is
more
helpful
in
cases
where
you
want
to
do
lower
level
processing.
So
this
is
a
same
difference
between
let's
say
a
jax
b,
which
is
a
annotation
binding
api
and
jax
p,
which
is
a
processing
api.
So
similar
type
of
idea
is
here.
A
If
you
want
to
do
lower
level
json
processing-
let's
say
you
have
a
very
complex
document
and
you
won't
be
part
one
part
of
the
document
to
be
processed
or
a
very
complex
pojo,
and
you
only
want
to
maybe
hydrate
part
of
that
or
if
you
have
highly
customized
bindings,
that
change
at
run
time
right.
Those
are
all
cases
where
having
a
lower
level.
Api
makes
a
lot
more
sense,
as
opposed
to
a
a
binding
based
api.
A
Now
this
api,
in
as
of
java
e7,
was
largely
feature
complete.
There
was
a.
There
was
a
few
things
that
were
added,
though
in
jakarta,
e8,
and
that
is
along
again
to
adapt
to
changes
that
are
happening
in
the
json
standard
itself
right.
So
two
particular
changes
name
changes,
namely
jsonpointer
and
jsonpatch.
A
Okay.
So
let's
talk
about
jsonpointer,
so
jsonpointer
is
basically
xbox
if
you're
familiar
with
xbot
and
even
if
you're
not
familiar
with
xbox,
it's
just
like
a
url
right,
so
it's
a
url
like
syntax
that
describes
a
location
in
a
json
document
right.
So,
as
you
can
see,
this
is
a.
I
have
an
example
of
navigating
to
a
mobile
phone
number
right,
just
using
using
a
url
like
syntax.
A
So
what
this
allows
you
to
do
is
that
it
allows
you
to
navigate
json
content
much
more
easily
right
without
this
api
you'd
have
to
write,
complicated,
looping
logic,
conjugated
complicated
tree
traversal
logic
to
get
to
the
same
bit
of
data.
So
it
cleans
up
your
application
code
quite
a
bit
and
makes
it
a
lot
more
functional
if
you
will
and
basically
the
the
example
that
you
see
in
the
in
that
the
example
change
that
you
see
is
the
one
on
screen
right.
A
The
other
change
that's
interesting
is
json
batch
and
jsonpatch
in
in
in
some
ways
it
has
parallels
to
http
patch
right.
So
basically
it
is
describing
a
change
to
a
json
document
inside
of
another
json
document
right,
so
the
format
is,
is
the
like
the
one
you
see
on
screen.
So
there
is
a
an
operation
and
there's
various
types
of
these
operations,
there's
a
add
or
replace
or
remove
move
copy
test.
A
These
are
these
are
the
different
operations
that
are
there
and
then
you
basically
are
using
those
operations
to
operate
on
mostly
json,
actually
json
path
operations
right.
So,
as
you
can
see,
I
have
a
couple
of
examples:
one
replacing
example
and
one
remove
example
crystallize
this.
This
is
how
it
looks
like-
and
this
is
how
the
corresponding
api
looks
like
right.
A
So
the
api
uses
the
builder
pattern
right
and
again
notice
how
compact
this
api
is
and
imagine
how
this
code
would
look
like
if
you
were
to
do
this
just
by
navigating
the
json
document,
as
opposed
to
just
applying
a
simple
patch.
Another
really
nice
use
case
for
for
this
patch
functionality
is,
if
you
have
the
same
set
of
changes
that
you're
applying
to
different
kinds
of
json
documents,
or
at
least
maybe
different,
different
instances
of
the
same
json
document
right.
A
So
this
is
also
very
helpful
functionality
in
that
right,
okay,
so
service
and
defense
is
the
last
api
that
I'll
talk
about
that
is
along
the
lines
of
along
the
lines
of
http
and
web
standards,
support
right,
so
service
center
events
is
a
lesser
known
part
of
html5
right
this.
This
is
so.
This
came
out
when,
when
things
like,
websocket
came
up
right.
A
A
So,
in
this
paradigm
of
server
sent
events,
what
you
get
is
you
still
get
one
initial
request
from
the
client
to
the
server,
but
the
server
doesn't
respond
in
a
once
and
done
fashion
right.
What
the
server
does
is
that
it
responds
with
multiple
responses
or
multiple
events
over
a
period
of
time
right
so
multiple.
So
an
example
of
this
is
a
is
stock
tickers
on
monitoring
applications.
Let's
say
you
want
to
monitor
the
status
of
a
control
system
or
you
want
to
want
to
monitor
a
particular
stock.
A
A
A
A
This
is
stickers,
so
you're
making
a
get
request
to
register
with
this
endpoint,
and
once
you
do
that
this
endpoint
is
not
going
to
give
you
just
one
response,
so
hence
you
see
that
it
is,
it
is
of
type
get,
but
the
response
type
is
actually
void
right,
so
you're
not
just
getting
one
response,
you're
going
to
get
instead
a
response
set
of
responses
over
time.
So
the
way
this
happens
is
that
you
get
a
handle
to
a
couple
of
important
apis.
A
One
is
ssc
event
sync,
and
this
represents
the
live
connection
between
the
client
and
the
server
and
soc
is
just
a
utility
object
that
will
allows
you
to
create
new
events,
just
like
you
see
in
in
the
example.
So
in
my
example,
once
I
get
the
get
request,
I'm
putting
it
in
a
background
manage
thread
using
the
manage
execute
service
and
in
java
ee,
as
you
can
see,
I'm
using
lambda
here
it
works
quite
well.
A
A
A
Maybe
we
can
talk
a
little
bit
about
what
is
next
in
terms
of
jakarta
e10,
so
jakarta
security
is
a
pretty
important
api
and
it's
a
version
1.0
api
right
and
when
I
say
that
some
people
are
surprised,
you
know
it's
a
technology,
that's
almost
15,
20
years
old.
How
come
you
have
a
version
1.2
of
the
security
api
and
how
a
security
api
done
was
done
in
the
platform
before
well.
For
those
of
you
who
are
familiar
with
java
e,
you
know
the
answer
to
that
so
java.
A
A
You
know
I
want
to
be
it
to
be
secured
through,
let's
say,
basic
authentication.
These
are
the
rules
that
you
can
access
this
url
or
access
this
particular
method,
but
things
like
okay,
so
I
want
to
configure
against
a
database
or
ldap
or
how
how's
my
role.
Mapping
is
going
to
look
like
all
that
usually
happened
at
the
application.
A
But
the
model
creates
two
different
problems:
number
one.
The
security
configuration
is
outside
the
application.
So
again
the
application
developer
doesn't
have
control
over
it
and,
although
the
server
specific
configuration
is
done
in
a
vendor-specific
way
right,
so
if
you
configure
security
once
through
some
vendor
specific
mechanism,
let's
say
ui
and
you
move
your
application
server.
Well,
you
have
to
redo
that
in
the
other
application
server
using
the
other
application
service
mechanism,
rather
than
simply
be
able
to
port
the
application
as
us.
A
Okay,
so
jakarta
security
addresses
these
weaknesses
and
it
does
that
in
a
couple
of
different
ways
that
we'll
talk
about
in
a
second,
but
one
of
the
key
things
is
providing
simple,
simple
security
providers
for
common
use.
Cases
like
like
database
and
ldap
providing
a
simple
plugability
mechanism
where
you
know
these
common
use
cases
are
not
sufficient
and
also
providing
a
universal
security
context
that
takes
all
those
little
bits
and
pieces
that
were
there
and
unifies
it
in
in
a
single
place.
A
Okay,
namely
in
the
jakarta,
jakarta,
security,
api,
okay,
so
here's
the
simple
security
providers.
This
is
a
very
good
example
of
simplicity,
right
now
of
introducing
simplicity
into
the
platform.
So
all
those
complex
configurations
that
you
used
to
do
before
you
don't
need
to
do
any
of
that
right.
All
you
need
to
do
in
order
to
secure
an
application
against
data
against
the
database
or
secure
against
ldap
is
just
put
in
this
one.
Little
annotation
and
you're
done
right
here.
A
Now,
let's
say
for
a
second
that
you're
you're
not
securing
against
the
ldap
and
you're
not
securing
against
a
database.
Let's
say
you
have
maybe
text
files
where
your
security
is
is
configured
or
some
other
legacy
based
system.
This
is
neither
a
relational
database
or
an
or
a
a
ldap
server.
Maybe
it's
in
a
nosql
database
right.
So
what
do
you
do
in
that
case?
So
the
way
you
do
that
you
used
to
do
that
in
the
past.
Is
you
have
to
write
a
complicated
jazz
module?
A
Jspec
module,
configure
your
app
server
again,
a
lot
of
vendor
specific
configuration
using
the
jakarta
security
api?
It's
super
simple
right,
so
all
you
need
to
do
is
you
need
to
implement
the
identity
story?
Interface?
You
need
to
make
it
a
cdi
bean
and
that's
it
right.
It
becomes
a
first
class
security
provider
right
out
of
the
gate.
A
As
a
result,
you
and
there's
just
one
method
to
implement
in
the
end,
it's
just
validate
it'll
take
some
kind
of
credential
as
an
argument,
usually
a
username
and
password
of
some
kind,
and
then
you
basically
will
take
those
credentials
validate
them
against
your
your
identity,
store,
okay
and
send
along
the
results.
So
the
result
will
be
either
success
or
failure.
If
it's
failure,
then
maybe
a
failure.
A
Reason
if
it's
success,
then
then
probably
the
name
of
the
logged
in
user
and
maybe
some
of
the
permissions
that
they're
granted
or
some
of
the
roles
that
they
are
okay,
so
security
context
is
an
important
one
too.
As
you
know,
again,
you
used
to
be
able
to
get
information
like
okay
who's
logged
in
and
what
is
their
role
in
a
very
service
in
a
very
api
specific
way,
and
only
in
certain
points,
so
maybe
only
in
hiv
right
and
only
in
servlet
and
that's
about
it.
A
Let's
say
you
have
a
security
need
to
do
security
at
the
dio
layer,
where
you
can't
really
do
that
very
easily.
So,
in
order
to
solve
all
those
problems,
now
you
have
a
universal
security
context
that
you
can
inject
anywhere.
There
can
be
a
servlet,
it
can
be
a
cdi,
it
can
be
an
ejv
wherever
cdi
is
enabled
you
can
inject
it
once
you
inject
it,
you
get
the
information
about
okay,
who's
currently
locked
in
and
what
is
their
their
current
roles
right.
A
So
you
see
that
in
the
example,
in
fact,
in
my
example,
I
have
it
implemented
in
a
cdi
interceptor
so
that
you
can
apply
this
interceptor
anywhere.
You
would
like
on
your
code
and
maybe
globally,
enable
it
right
for
every
single
method,
indication
cdi
method,
indication.
This
could
be
great
for
you,
okay,
so
moving
on,
I
want
to
talk
about
another
sort
of
sim
change
along
the
lines
of
simplification
and
that's
a
jakarta
cdi2
right.
So,
as
you
can
see,
this
is
a
major
release.
So
the
major
changes
here
are
actually
java.
A
Sc
support,
so
cdi
used
to
be
a
a
jakarta
ee
only
technology,
so
there
was
no
standard
way
of
bootstrapping
it.
Let's
say
in
a
unit
test
or
in
a
servlet
environment,
or
some
some
other
place
right.
So
now
you
can
do
that,
there's
actually
a
bootstrap
api
to
use
cdi
wherever
you
want
whatever
it
is
that
you
need
again,
primarily
maybe
in
unit
tests
and
the
way
you
do.
That
is,
there's
also
the
notion
of
modularity.
A
So
there's
a
certain
set
of
features
that
will
only
work
in
a
java
e
container,
there's
a
certain
set
of
features
that
are
core
that
work
anyway
and
then
anywhere
and
then
a
certain
set
of
features
that
will
only
work
in
java,
ac
environments.
Asynchronous
events
is
another.
One
I'll
show
you
that
in
a
second
the
other
big
change
was.
There
was
a
lot
of
improvements
made
to
the
extensions
api.
A
So
a
lot
of
that
has
been
changed
so
that,
ideally
anyone
can
write
a
cdi
portable
extension.
In
fact,
you
should
give
it
a
try.
It's
actually
quite
nice
to
write
the
other
change
was
java,
sc8
alignment,
so
these
are
things
like
observing
repeatable
annotations
and
the
daytime
api
and
completely
open
features.
A
A
So
you
know
it's
just
a
one
method
that
says
fire
and
you
give
it
an
object
to
that
is
representing
your
event,
and
then
you
observe
that
event
using
the
at
observes
annotation,
and
that's
it
right.
That's
that's
as
simple
as
the
cda
bus
gets,
the
cdi
bus
used
to
be
synchronous
right
so
event,
firing
and
even
reception
used
to
happen
in
the
same
thread,
so
it
now.
You
can
do
that
in
different
threats
and
that
will
help
help
scalability.
A
A
Okay,
so
I
have
a
question
from
sajeed:
ssc
is
similar
to
event
driven
sort
of
right.
So
event,
driven
is,
is
a
you
can
say.
Yes,
ssc
enables
event
driven
programming
on
the
client
side
right,
but
it
it.
You
know
you
know
itself
is
not
defining
the
entirety
of
event
driven
architectures
right.
So
it's
a
small
part
of
event
of
an
arc
architecture,
certain
okay,
any
other.
A
Well,
if
not,
I'm
gonna
continue
moving
on
and
let's
talk
about
some
of
the
innovations
in
java
sc
that
were
absorbed
by
jakarta,
and
why
that
that's
important
to
you
so
in
reality,
a
lot
of
the
changes
that
were
made
in
java
sc8
were
made
in
a
in
a
forward
comparable
fashion.
So
what
that
means
is,
if
you
upgrade
it
to
java
sc8
and
you
began
to
use
javascript
features.
Most
of
those
features
actually
will
work
with
older
apis.
A
As
is
you
so
you
saw
an
example
of
that
right,
so
I
use
the
executor
api
with
lambdas
right
and,
and
it
didn't
require
any
changes
to
the
executor
api.
For
that
to
happen,
because
executor
api
already
is
callback
based
right,
so
anything
that
is
callback
based
is
probably
going
to
naturally
work
with
landless.
A
Similarly,
if
you
want
to
adopt
things
like
the
daytime
api,
you
can
very
easily
do
that
in
your
business
logic.
There's
not
a
lot!
You
need.
You
need
from
the
runtime
in
order
for
that
to
happen
same
thing
with
computable
features,
but
there's
some
cases
where
you
actually
do
need
the
jakarta
api
to
adapt
right.
A
So
one
key
example
of
that
we'll
see
a
few
examples
of
this
right,
and
these
are
the
list
changes
that
are
listed
so
repeatable
annotations
actually
change
a
lot
of
apis
things
like
persistence,
messaging,
mail,
the
bean
validation
they
all
adopted.
Repeat
our
cdi
as
well
daytime
api.
Again
this
the
changes,
the
apis
that
changed
as
a
result
were
faces,
persistence,
being
ventilation.
A
Computable
features
were
adapted
by
jakarta.
Rest
and
streams
were
adopted
by
jakarta,
persistence
and
jakarta
json
processing.
So
let's
take
a
look
at
what
these
changes
actually
mean.
So
we'll
first
talk
about
repeatable,
annotations
right,
so
repeatable
annotations
is
solves
the
problem
of
being
able
to
have
the
same
annotation
at
the
same
place
right.
So
this
didn't
need
to
be
possible.
So
in
order
to
solve
this
problem,
jakarta
typically
use
this
technique
of
using
wrapper
annotations,
which
is
kind
of
a
hack
right.
A
So
any-
and
you
see-
hopefully,
you
have
seen
this
already
use.
Things
like
named
queries
is
a
pretty
good
example.
So,
as
of
jakarta
ee,
eight
that
is
no
longer
necessary
right,
because
all
of
these
annotations
have
been
retrofitted
to
make
use
of
repeatable
mutations
right.
So
you
can
just
as
an
end
user.
Just
repeat
these
annotations,
where,
where
you
would
you
would
need
them,
so
it
cleans
up
the
api
cleans
up
the
code
quite
a
bit
so
similar
again,
all
of
the
apis
like
jms
java
mail,
anything
that
were
multiple
annotations.
A
A
It
will
come
in
if
you're,
using
something
prior
to,
let's
say
java,
e7
and
you're,
trying
to
use
datetime
apis.
Let's
say
in
an
entity
like
like
in
my
example:
you
wanted
to
use
in
the
instance
class
right
to
represent
a
particular
event
in
time.
Well,
you
won't
be
able
to
use
instance
because
jpa
will
not
know
how
to
translate
instances
back
and
forth
between
the
database
right
so
but
in
jakarta,
eight.
This
is
no
longer
the
case
right.
A
So
jakarta,
38,
now
jpa
understands
all
these
daytime
apis
and
can
translate
them
without
your
needing
to
do
anything.
So
you
can
just
use
it
the
same
way.
You
are
using
going
to
use
java,
util
date
or
java
sequel
date
and
similarly,
the
bean
validation
annotation,
which
I
have
an
example
of
here
that
also
it
recognizes
these.
These
daytime
api
classes
automatically.
So
you
don't
have
to
do
anything
with
that
same
thing
for
jsf.
A
Okay,
so
if
you
don't
have
to
you,
don't
have
to
write
a
converter
or
anything
to
convert
back
and
forth
between
these
date
date
classes
and,
let's
say
faces
backing
beats
okay,
so
completable
futures.
I
hope
you
guys
know
what
this
is,
but
this
is
basically
the
promises
for
java
all
right.
So
if
your
firmware
javascript
promises,
basically
it's
it
takes
the
best
parts
of
future
and
merges
it
with
callbacks
right.
So
you
have
the
capability
of
making
asynchronous
invocations
without
prematurely
blocking
or
writing
very
complicated
code
right.
A
Like
then
combined,
as
you
can
see
in
my
example
that
allows
you
to
do
this
kind
of
kind
of
complex,
asynchronous
implications
in
a
very
fluent
functional
way
right
so
now
the
jakarta
rest,
this
particular
exam
usage
of
this
in
jakarta
both
on
the
server
side,
as
well
as
on
the
client
side
api.
So
in
the
client-side
api,
all
you
need
to
do
is
invoke
dot
rx
and
instead
of
returning
a
future
or
doing
callbacks
you'll
get
a
handle
to
a
completable
computer
future.
A
Instead,
okay,
so
streams
again,
hopefully
you're
familiar
with
this
already
right.
It
allows
you
to
do
all
kinds
of
aggregate
operations
in
java
that
you
didn't
used
to
do
before
you
either
had
to
have
to
get
a
third
party
library
or
be
able
to
handwrite
a
lot
of
this
code
right.
So
you
don't
need
to
do
that
anymore
and
also
the
streams
api
makes
heavy
use
of
functional
paradigms.
A
It's
actually
one
of
the
better
examples
of
of
an
api
adapting
functional
paradigms.
So
the
jakarta
persistence
api,
as
well
as
the
collection
api,
rather
the
the
json
processing
api,
allows
you
to
translate
two
streams
very
easily
right.
So
now,
for
example,
you
can
do
things
like
what
you
see
on
screen
that
you
can
get
a
stream
directly
from
a
query
and
manipulate
those
results
right
so
same
thing
with
arrays
of
of
json
that
you
can
very
easily
translate
them
into
streams
and
perform
operations
on
those
right.
A
Do
use
this
with
care
right.
So
I've
seen
cases
where
people
suddenly
think
they
can
use
streams
as
a
replacement
to
the
where
clause
or
the
order
by
clause
right.
That's
usually
not
a
good
idea
as
good
as
streams
are,
you
know.
Even
you
know,
with
some
of
the
multi-threading
capabilities,
the
database
optimizations
often
will
outperform
right
the
thing
anything
that
you
can
do
in
java,
so
do
use
it
with
caution.
A
Okay,
these
are
not
all
of
the
changes.
These
are
just
the
high
level
changes
in
in
in
chakras
there's
many
others
of
changes
as
well.
So
here
are
some
examples
of
those
that
I
won't
talk
about
in
great
detail
and
won't
show
you
example
code
too
much
so
now
you
can
do
very
easy,
websocket
integration
with
jsf.
A
You
can
do
jsf
and
cdi
integration.
So,
as
I
said,
injecting
things
like
faces
context,
you
can
do
that
very
easily.
There
are
more
invalidation
constraints
that
are
added
so
things
like
email,
validation,
not
empty
past
feature
and
and
there's
a
few
others
like
that.
In
my
example,
I
showed
you
one
point
to
point
communication
between
sse.
It
can
be
one
too
many
communication,
so
you
can
broadcast
ssc
events,
so
you
can
have
basically
multiple
clients
connecting
to
the
same
endpoint
and
getting
the
same
result
right.
A
That
is
also
possible
in
using
the
ssc
sse
api.
You
can
do
things
like
cdi
event
ordering,
in
addition
to
being
able
to
do
just
asynchronous
events.
Similarly,
you
can
prioritize
injection
points
as
well.
So
this
is
the
ad
priority
annotation
and,
as
I
said,
the
the
jakarta
stream
support
is
all
is
also
there
in
the
I
didn't
mean
to
say.
A
Yeah
I
heard
the
json
processing.
I
didn't
show
you
an
example
of
that,
but
you
can
do
that
as
all
right.
So
state
of
jakarta,
8
implementations,
pretty
much
all
of
the
runtimes
are
today
jakarta,
8
compatible
the
only
one
that
is
that
remains
is
weblogic
and
the
next
revision
of
weblogic
is
also
going
to
be
jakarta.
Eight
compatible
so
pretty
much
all
of
the.
A
A
Okay,
so
what
is
this
about?
As
I
mentioned,
the
primary
objective
here
is
to
move
away
from
the
jawbox
namespace
that
is
still
under
oracle's
branding
regime.
Two,
a
truly
open
name
space
via
jakarta,
there's
also
some
other
changes,
so
removing
all
of
those
things
that
I
I
said
was
pruned
well
they're
now
actually
gone.
A
You
know
it's
primarily
intended
for
tools,
ecosystems
and
early
adopters
that
want
to
move
to
the
new
space
name
space
in
preparation
for
jakarta
e10.
That
gives
you
a
little
bit
of
space
to
do
that,
it's
all,
but
done
right.
So
you
know
there
is
a
milestone.
Release
out.
You
can
begin
testing
it
glass
fish
five
is
already
out.
You
can
begin
testing
with
plus
fish
five
and
see
how
the
name
space
changes.
Look
like
you
know.
A
A
It's
all
the
work
is
almost
done
now,
but
you
can
still
check
to
see
if
there's
some
work
that
you
can
contribute
you.
Certainly
your
contribution
is
welcome
here,
so
jakarta,
e9
is
going
to
remain
targeted
to
java
sc8
right
just
to
not
create
too
many
changes
all
at
once,
but
early
next
year
there
should
be
a
jakarta
9
1
and
the
primary
objective
of
9
1
is
going
to
be
to
support
java
sc
11.,
okay,
in
fact,
most
of
the
jakarta
run
times
today
like
open
liberty
and
payara.
A
A
Okay,
so
hopefully,
in
this
in
this
conference,
you've
also
heard
of
microprofile.
I
won't
talk
too
much
about
it,
but
basically
you
know
it's
taking
a
little
bit
of
time
to
do
all
of
the
transition
and
do
the
transition
cleanly
from
java
e
to
jakarta
e.
So
there's
not
a
lot
of
time
for
a
lot
of
innovation,
so
the
innovation
space
is
micro
profile,
at
least
for
now.
Right.
A
So
as,
as
I
said,
jakarta
in
general
is
a
pretty
good,
solid
platform,
if
you're
all
you're,
really,
writing
is
a
monolithic
application
and
that's
all
you
plan
to
write
and
that's
that
is
good
enough
for
you.
But
if
you
want
to
go
beyond
that
and
if
you
want
to
adopt
microservices
in
a
wholesale
fashion,
right
now
be
in
the
bleeding
edge
of
microservices
development,
then
you
need
to
look
into
augment
augmenting,
jakarta,
yeah,
jakarta
apis
with
microprofile
apis.
In
fact,
most
of
the
jakartan
times
will
allow
you
to
use
microfiber.
A
They
also
bundle
micro
profile,
just
like
they
do
just
like.
They
have
built-in
support
for
for
jakarta
e
and
there's
a
number
of
features
that
are
available
that
are
micro
services
oriented,
and
you
should
definitely
take
a
look
at
that.
You
know,
even
if
you
don't
wind
up
using
my
microservices
right
away,
it's
useful
to
be
aware
of
what
these
innovations
are.
A
Okay
and
the
way
you
find
out
more
about
that
is
log
on
to
microprofile.io
all
right.
So
now
that
you
have
the
jakarta
transition
almost
done
and
the
name
space
almost
done,
and
you
have
this
micro
profile.
A
natural
question
to
ask
is
like
how
do
you
align
both
of
these
technologies,
and
this
has
been
something
that
I've
been
thinking
about
for
a
while.
A
So
the
way
I've
I've
thought
about.
This
is
basically
talking
to
people
that
that
I
know
and
trust
their
java
users
and
listen
to
what
they
would
like
to
see
and
also
to
take
advantage
of
my
twitter
following
right
to
see
hey
what
do
the
people
that
follow
me
on
twitter?
What
are
their
opinions
on
this
and
the
opinion
is
actually
very
at
least
somewhat
surprising
to
me
right.
So
they
really
don't
want
two
different
things.
A
Everybody
just
wants
one
platform,
not
microprofile
and
jakarta,
but
just
one
platform,
and
they
do
believe
that
that
one
merged
platform
should
remain
shakartai
even
down
to
the
names.
But
even
if
you
ask
people
hey
what
type
of
name
space,
what
does
the
brain,
branding
and
name
space
need
to
be
to
there?
Can
they
be
two
different
things
or
the
same
thing?
The
answer
is
overwhelmingly
again
same.
A
So,
if
you
have
an
opinion
on
someone
else,
you
should
be,
you
should
engage,
you
should
engage
them
under
profile
community
and
make
sure
your
opinion
is
heard
right.
So
if
your
opinion
is
not
heard,
it's
not
going
to
be
listened
to
either
right.
So
that's
the
first
step
is
saying:
what
is
it
that
you
want
and
why
I'm
going
to
stop
a
little
bit
now
and
see
where
folks
are
then
we'll
move
on
on
to
another?
Pretty
big
topic
I
have
another
hour
or
so
to
in
in
this
slot?
A
A
A
But
I
don't
see
any
questions,
so
I'm
just
going
to
keep
moving
and
keep
moving
forward.
Okay,
so
these
are
the
possible
so
after
jakarta,
e9
is
done
hopefully
by
this
year.
This
opens
up
the
possibility
of
innovation
right,
and
this
was
the
whole
point
of
why
we
did
these
things
right
to
speed
up
the
innovation
in
jakarta.
A
A
What
this
does
is
that
it
bridges
it
gives
you
a
jpa
and
jdbc-like
api
to
access,
nosql
data
stores
like
mongodb,
cassandra
and
so
on.
So
this
is
a
possibility
or
where
this
could
be
in
brand
new
api
added
in
jakarta,
e10,
similar
thing
for
jakarta,
mvc
right.
So
this
is
an
alternative
to
jsf.
That
is
looks
more
along
the
lines
of
struts.
Let's
say
it's
an
action-oriented
framework.
People
have
been
asking
for
such
an
alternative
in
java
e.
A
For
a
little
while
right,
so
they
don't
want
to
just
get
after
java
e
just
to
be
able
to
use
action,
oriented
frameworks,
they
wanted
a
frame
framework
choice.
Just
like
this
again,
it
was
started
as
java.
Eemvc
didn't
make
it
in
the
java
e8
time
frame,
but
it's
finalized.
Now,
right
and
again,
another
possibility
is
to
add
jakarta
mvc
as
part
of
jakarta
e10
as
a
brand
new
api,
some
of
the
old
things
in
particular
deprecating
ejv,
it's
a
it's
an
outdated
programming
model
and
it's
basically
redundant
with
cdi.
A
So
what
you
can
do
here
is
you
can
move
a
lot
of
the
functional
manually
that
is
an
ejb
in
and
then
make
it
cdi
based
and
move
it
into
other
specifications
like
messaging
and
concurrency
and
security
where
they
actually
make
more
sense
right.
So
we
saw
that
the
jakarta
security
api
supports
things
like
ldap
and
database
in
reality,
especially
with
microservices.
There
are
other
authentication
mechanisms
that
are
also
very
common
right,
so
these
are
things
like
oauth,
2
and
openid
connect
and
jwt
or
json
web
token.
A
A
A
I'll
I'll
walk
you
through
that
document
in
the
latter
part
of
the
of
the
presentation
once
we're
once
we're
done
here,
so
that
you
one
you
have
an
idea.
What
are
the
possibilities
in
jakarta,
e10
and
two?
You
can
provide
your
own
opinion
and
also
maybe
help
implement
some
of
those
changes
yourself,
like
I
said,
if
there's
one
thing
that
you
should
take
away
is
that
you
need
to
get
involved
right.
A
A
So
there's
a
website
if
you
want
to
learn
more
jakarta
ambassadors,
dot,
io
and
also
actually
one
of
the
best
ways
of
keeping
track
of
what's
going
on
with
jakarta
is
just
to
follow.
The
jakarta
embassador's
twitter
handle
that's
outlined
there
as
well,
and
and
if
the
you
do
nothing
else,
hopefully
you
can
just
follow
the
twitter
handle,
and
that
is
already
an
improvement.
Something
that's
something
that
you
can
do
better
as
a
as
a
somebody
that
sees
the
value
in
jakarta
as
a
technology.
A
A
Jakarta,
nine
and
nine
one
are
coming
soon
right,
so
they're
right
around
the
corner
and
they're
another
step
in
the
transition
towards
openness
and
followed
by
jakarta
e10.
But
ultimately
I
I
really
hope
that
the
main
thing
you
take
away
from
from
the
talk
today
is
that
you
need
to
get
involved
right
and,
and
you
you
need
to,
you-
need
to
contribute,
and
you
need
to
see
what's
going
on.
A
Okay,
so
I'll
leave
you
with
a
few
resources
and
I'll
end,
this
particular
segment
of
our
session
and
then
we'll
move
on
to
the
next
one.
So
the
next
one
is
going
to
be
walking
through
the
changes,
the
doc,
the
document
draft
that
we
have
for
jakarta,
e10
and
showing
you
what
the
potential
changes
might
be
and
maybe
hopefully
get
some
of
your
input.
A
So
if
you
want
to
learn
more
about
jakarta
one
one
of
the
really
nice
places
is
the
jakarta
e
live
stream
recordings
right.
So
a
lot
of
what
we're
talking
about
actually
has
been
talked
about
in
greater
detail
in
those
recordings,
so
log
on
to
jakarta1.org
find
the
recordings
they're
actually
on
youtube
as
well
and
you'll
get
a
lot
of
information
just
by
taking
a
look
at
those
videos.
A
It's
called
jakarta
tech
talks,
there's
usually
monthly
talks
in
the
jakarta
tech
talks
and
again
the
jakarta
tech
talks
have
a
have
a
bunch
of
recordings
as
well,
and
you
can
join
there
and-
and
you
know
basically
subscribe
and
see.
What
are
the
topics
and
sessions
that
interest
you
and
you
can?
You
can
stay
up
to
date
that
way
as
well
all
right,
so
that
is
it
in
terms
of
this.
A
So
this
is
the
jakarta
ambassador's
website.
If
you
go
to
the
resources
section
and
if
you
go
to
the
google
drive,
this
is
a
shared
drive
for
everyone.
That
is
a
jakarta
ambassador
over
here.
You
will
see
the
there's,
a
presentation
template
and
the
this
particular
deck
that
I
just
presented
is
jakarta,
ee8,
dot,
powerpoint
right,
you
can
open
up
this
powerpoint
and
actually
and
actually
download
it
and
make
make
your
own
alterations
and
adopt
this
deck
yourself.
Okay,
so
hopefully
that
is
helpful
and
something
you
will
consider
doing.
So.
A
A
A
A
So
the
way
you
get
there
is
you
hit
the
getting
involved
button,
okay
and
you'll,
see
in
the
getting
involved
section
they'll
be
with
outlined
all
other
different
things
that
you
can
do
as
an
individual
to
help
move
forward.
The
the
jakarta
e
as
a
technology
and
under
here
you'll,
see
that
we
have
linked
an
early
draft
contributor
guide
for
jakarta
e10.
So
you
can
click
on
on
here
and
this
it'll
bring
you
to
a
google
doc
right
and
the
google
doc
is
open
to
anyone,
especially
open
for
comment.
A
Okay,
so
you
can
take
a
look.
You
can
read
this
document
and
it
will
tell
you
you
know
how
you
can
become
a
contributor
to
jakarta
e10
and,
more
importantly,
what
are
the
changes?
What
are
the
types
of
changes
that
you
can
get
involved
in?
So
I'm
going
to
begin
to
walk
through
this
document.
For
you,
you
know,
unless
you
have
other
questions
right
or
something
else
that
you
would
like
to
cover,
I'm
going
to
take
a
little
bit
of
time
to
basically
discuss
this
document
and
go
over
it
with
you.
A
A
Okay,
maybe
that's
too
much:
let's
do
one
more
150.
Does
that
work?
No!
That's
too
much,
okay,
all
right,
125
years.
So
this
is
the
guide
to
contributing
to
jakarta
e10.
So
there's
many
many
different
ways
of
contributing
contributing
to
jakarta.
The
simplest
thing
you
can
do
is
you
can
subscribe
to
our
mailing
list.
A
A
It
has
a
list
of
all
of
the
jakarta
emailing
list
that
that
you
can
join
right,
beginning
from
cdi
to
el
to
jsf
and
a
whole
bun
whole
bunch
of
this,
like
that,
and
one
of
the
ones
is
the
chakarte
community
test
that
we
already
talked
about.
So
the
first
thing
you
can
do
is
you
can
join
on
on
to
these
mailing
lists
and
essentially
you
keep
track
of
what's
going
on
and
contribute
to
the
conversations
there
right.
A
So
next,
if
you
want,
if
there's
a
specific
set
of
changes
that
you
would
like
to
see,
one
very
easy
way
of
doing,
that
is
first
see
if
that
issue
is
already
documented
right,
then
the
way
you
do
that
is
you
go
to
each
of
these
jakarta
e
projects.
So
let's
say
we
go
to
jakarta
bean
validation
or
jakarta
concurrency,
and
each
of
these
will
have
some
kind
of
link
right.
That
will
take
you
to
take
you
to
the
github
or
where
this
project
resides
perhaps
in
github.
A
Okay
and
here's,
where
you
have
your
the
github
account
and
you'll,
see
those
github
issues
right.
So
each
of
these
projects
will
have
some
issues
that
talk
about
future.
Looking
changes,
changes
and
the
kind
of
things
that
could
be
done
so,
for
example,
add
the
asynchronous
annotation
to
replace
cjb
right.
So
these
are.
These
are
the
kind
of
things
that
that
you
can
do
and
see.
If
your
your
particular
your
favorite
technology
is
listed
right,
your
favorite
change
is
listed.
If
not
you
can
what
you
can
do.
A
Is
you
can
log
on
to
the
mailing
list
and
begin
discussing
this
change
and
maybe
down
the
line,
enter
an
issue
and
begin
working
on
that
issue
right,
there's
a
also
the
different
sets
of
changes
right.
So
there's
the
ap
sensor
changes
in
the
api,
so
this
is
the
api
project,
for
example,
concurrency
api.
A
If
you
look
in
the
project,
there
will
be
an
implementation
project
as
well,
and
there
will
be
a
tck
project
right.
So
there's
a
number
of
projects
that
you
can
get
involved
in.
If
you
want
to
begin
making
a
change
right
so
begin,
making
a
change
looks
like
propose
an
api
change.
Do
a
tck
change
change
the
actual
implementation,
typically
something
like
lost
fish
or
jersey
or
mahara
or
openmq
or
eclipse
link,
maybe
even
provide
a
proof
of
concept.
These
are
the
kind
of
things
you
can.
A
You
can
do
if
you're
unsure
about
all
of
that
right
and
you
don't
really
don't
know
where
to
start.
One
easy
way
to
start
is
to
just
reach
out
to
the
jakarta
ambassadors.
Google
group-
that's
here,
okay,
you
can
just
introduce
myself
like
there
is
somebody
that
introduced
themselves
and
say
hey.
I
want
to
help.
You
know
this
is
my
background
in
jakarta.
A
A
So,
for
the
most
part,
actually
a
lot
of
the
stuff
you
will
you'll
be
able
to
do
without
any
kind
of
paperwork
as
well,
just
as
a
normal
end
user
right.
So,
there's
no
reason
to
assign
paperwork
to
just
to
follow
a
project
just
to
file
an
issue
just
to
participate
in
a
discussion
right.
But
if
you
do
anything
beyond
that,
and
you
begin
to
want
to
contribute
some
code
or
contribute
a
change,
you
will
need
some
paperwork
and
even
in
that
paperwork
is
not
really
that
heavy
right
right.
A
So
if
you
don't
want
to
become
a
committer
and
you
just
want
to
contribute
some
code,
all
you
really
need
is
something
called
the
eca
or
or
eclipse
contributor
agreement.
So
I'll
show
you
how
that
looks
like
this.
Is
it
right?
It's
a
simple
document:
you,
you
just
click
on
some
links
here
and
and
you
it
takes
you
to
the
eca
form
right.
So
I'm
logging
in
as
myself
here
and
you
just
sign
the
agreement
right.
Just
I've
already
signed
the
agreement.
A
So
all
you
need
to
do
is
sign
the
agreement
and
you're
good
to
go.
That's
all
you
need
in
order
in
order
to
contribute
code.
Now,
if
you
want
to
do
something
beyond
that-
and
let's
say,
you've
contributed
quite
a
bit
and
now
you
want
to
become
a
committer
on
a
project
that
will
require
some
more
additional
paperwork
right
and
that
paperwork
will
often
require
some
permissions
from
your
employer
right
so
sign
the
eca.
You
don't
need
it.
A
A
So
let's
talk
about
what
the
jakarta
contents
are.
We
talked
about
that
as
well.
There's
no
official
roadmap
for
jakarta
a10,
just
yet
there's
some
high
level
directions
that
was
that
were
put
together,
but
that's
really
about
it.
So,
ultimately
it
is
really
up
to
you
it's
up
to
each
individual
technology
project.
What
type
of
changes
they
would
actually
like
to
see
right.
So
the
best
way
of
determining
this
is
to
is
to
get
involved
and
get
your
voice
heard
and
hopefully
begin
to
contribute
some
of
these
changes.
A
So
there
are
some
key
themes
that
you
can
take
a
look
at
at
a
high
level,
so
aligning
cdi
is
one
of
them
right,
so
getting
rid
of
ejb,
perhaps-
and
you
know
more
flexible
modernized
cdi,
centric
functional
equivalent
functionality,
introducing
that
aligning
more
more
and
more
specifications
with
cdr,
where
it
makes
sense.
I
talked
about
jakarta
rest,
for
example,
aligning
to
java
sc
right.
A
Those
are
those
few
bits
and
pieces
that
we
talked
about
where
java
ac
innovations
can
can
be
better
adopted
by
java
java
e
technologies
and
also
breaking
up
and
making
all
of
every
single
technology
that
is
fundamentally
available
could
be
available
to
in
java
sc,
making
that
available
in
javascript
right.
There's,
no
reason
not
to
do
that.
The
more
you
do
that
the
greater
usage
these
these
technologies
are
likely
to
have
right.
If
you
can
use
it
more
in
more
places.
It's
a
good
thing.
A
There
are
some
other
vendor
neutral
things
that
would
be
better
standardized
to
achieve
better
portability.
So
this
is
another
key
thing.
So,
at
the
platform
level,
these
are
some
of
the
changes
that
you
can
think
about.
The
tcks
today
are
very,
very
old
right.
They're
used
in
pardon
me,
the
tck
is,
is
about
15
years
old
right,
so
it's
it's
written
in
a
very
with
very,
very
old
technology,
although
the
tcks
can
be
modernized
using
junit,
5
and
arcelia,
and
actually
my
friend
andrew,
did
a
very
good
write-up
on
this.
A
A
A
We
could
introduce
and
add
service
annotation
as
a
replacement
to
ejb.
Stateless
hiv
status
is
by
far
the
most
commonly
used,
ejb
ejb
annotation.
We
can
replace
that
using
at
service
that
provides
equivalent
functionality,
we
could
have
more
customized
websites.
So
good
examples
are
things
like
the
invalidation.
So
let's
take
a
look
at
the
beam
validation.
A
You
see.
This
is
a
jakarta
technology
that
has
its
own
website.
Cdi
is
another
example,
so
each
java
e
technology
can
have
its
own
website
just
like
this
right,
so
that
would
that
would
help
these
technologies
as
well
to
to
succeed
on
their
own
right,
as
opposed
to
just
being
part
of
a
broader
platform.
A
When
you
look
begin
to
look
at
the
issues
of
each
of
the
each
of
the
projects,
you'll
see
a
number
of
issues
that
are
old
and
out
of
date.
Okay,
so
you
can
help
clean
up
and
prioritize
those
issues
as
well.
Right,
that's
an
easy,
a
very
easy
thing
to
do,
and
it's
a
good
way
of
learning
and
beginning
to
engage
in
beginning
to
contribute
to
these
projects
as
well.
A
So
all
of
these
technologies
could
be
made
to
better
support
that
standard
or
and
there's
modularity
itself
could
be
standardized
in
jakarta
much
better
right.
So
the
first
model
steps
to
doing
this
is
doing
things
like
automatic
module
names
in
the
manifest
at
mf
and
providing
a
correct
module,
info.java
again,
very,
very
simple,
work
right:
you
can,
you
can
log
on
to
most
of
these
projects
and
and
make
a
pr
and
provide
these
fixes
yourself,
introducing
a
micro
services
profile
right.
A
The
security
api
already
is
pretty
important
right.
We
talked
about
some
of
the
potential
other
changes
there
so
again,
adding
support
for
oauth
2
jwt,
open
id
connect,
in
addition
to
the
database
on
ldap,
providing
cd
ejb
based
alternatives
in
cdi
centric
ways
so
replacement
to
things
like
roles
allowed
and
run,
as
that
could
be
done.
A
One
other
idea
that
that
has
been
floating
on
for
a
little
while
is
allowing
a
role-based
el
powered
annotation
to
do
authorization
right.
So
you
can
see
an
an
example
of
that
so
at
authorized,
if
a
principal's
name
is
arjun
right,
so
you
know,
in
addition
to
writing
code,
for
that,
you
could
just
do
that
in
a
more
declarative
fashion.
A
A
Jakarta
concurrency
is
another
important
one.
There's
a
lot
of
pending
changes.
Here
again
this
could
be
another
destination
where
egb
annotations,
like
at
asynchronous
at
scheduler
net
lock,
could
wind
up
in
right
outside
of
ejb
and
a
cdi
centric
model.
You
could
add
other
things
that
are
today
proprietary.
So,
for
example,
a
specifying
maximum
concurrency
for
a
bean
doing
manage
executor
service
definition
right
today,
you
can
only
do
that
in
vendor-specific
ways:
adapting
support
for
javascript
completable
features.
So
a
lot
of
these
apis
today
are
still
based
on
java
util
future.
A
They
could
be
retrofitted
to
use
computable
features.
Instead,
you
properly
propagating
cdi
context.
So
today,
when
you
create
a
managed
executive
service-
and
you
spawn
a
thread,
the
cdi
context
is
not
propagated
right,
so
that
that
could
be
a
a
an
important
change
as
well
standardizing
things
like
object,
pooling
through
the
pooled
or
pool
scoped
animation.
That's
another
possible
change!
A
A
So
just
like
cdi,
you
could
provide
a
java
sc
bootstrap
module
in
a
standardized
way
of
creating
resources
like
cues
and
topics
you
could
think
about
doing
interoper,
interoperability
between
jms
and
m
amqp
or
jms
and
kafka
or
jms
and
mqtt,
so
that
these
protocols
are
also
have
baked
in
support
a
defined
way
of
support
in
jakarta
messaging,
or
you
could
also
think
about
potentially
kafka
implementing
jms
implementing
a
version
of
janus
right.
So
these
are
all,
I
think,
very
important
things
to
think
about.
A
Jakarta.
Persistence
is
largely
pretty
mature.
Okay,
but
there
are
some
things
you
can
consider
doing
here
as
well.
So
persistence,
dot
xml
is
is,
can
be
made
optional
right,
you
don't
actually
in
many
cases
you
actually
don't
need
the
processor
on
start
xml,
so
that
it's
potentially
could
be
something
that
can
be
pulled
out
and
made
optional.
A
You
could
add
more
sql-like
features
right,
so
things
like
sub
selects
right
these
are.
These
can
can
be
helpful
in,
for
example,
things
like
pagination,
adding
jcache
as
a
second
level
cache
provider
right.
So
today,
gpa
has
a
caching
mechanism,
but
it's
proprietary.
It's
jpa
specific!
You!
You
can't
use
a
jpa.
You
can
use
a
jcatch
provider
very
directly
with
jpa
gps
secondary
level
cache.
Maybe
that
could
be
standardized
multi-tenancy,
so
things
like
eclipse,
link
and
hibernate.
A
Jakarta
rest
similarly
has
a
set
of
changes,
so
using
at
inject
instead
of
context,
add
context
for
injection.
This
is
this
would
be
an
alignment
story
between
jakarta
the
rest
and
cdi
again
providing
a
bootstrap
api
for
jax
rs,
potentially
for
doing
again
doing
unit
testing
right.
You
ought
to
be
able
to
bootstrap
jersey
in
a
in
a
in
a
unit
test
or
in
a
java,
ic
application.
A
Adding
native
support
for
multiplied
form
data
right.
This
is
today
not
really
possible
in
jax
rs,
but
there
are
some
legitimate
cases
where
you
would
want
to
do
things
like
this
in
batch
again,
you
can
today
batches
basically
uses
its
own
api.
It
doesn't
use
cdi
very
much
right.
It
could
be
enhanced
to
align
with
cdi
a
bit
better.
A
Today,
you
can
only
define
jobs
in
xml,
so
the
job
definition
language
can
be
moved
from
xml
to
java,
so
that
you
don't
you
can
avoid
using
xml
in
one
more
case
and
there's,
you
could
also
do
more
flexible
definitions.
So
today
the
definition
for
readers
process
and
writers
are
a
little
bit
rigid
right.
So
there's
a
specific
way
of
doing
things,
and
instead
of
doing
that,
you
could
make
it
a
little
bit
more
generic
jakarta
mail
if
you've
used
it
before
it's
a
very
low
level
api.
It
feels
a
lot
like
jdbc.
A
There
could
be
a
space
for
creating
a
higher
level
cdi
based
api
for
jakarta
mail.
Okay,
so
one
very
easy
place
that
you
could
do.
This
kind
of
work
is
something
like
apache
delta,
spike
right,
material
delta,
spec
project.
You
could
create
a
model
there
that
supports
jakarta
meal.
Specifically
transactions
is
another
interesting
place
where
there
are
certain
things:
certain
optimizations,
for
example,
using
one
phase
commit
or
loss
resource
utilization.
These
are
common
optimization
techniques
in
run
times
like
web
logic
that
improve
the
performance
of
jta.
A
Resales
has
a
set
of
set
of
changes
as
well
right,
so
you
can
make
more
rest
friendly
urls
for
for
faces.
You
can
certainly
deprecate
some
of
the
older
apis.
You
know
there
are
interfaces
things
like
support
for
jsp
right,
so
jsp
can
remain
a
part
of
jakarta,
but
the
support
for
it
in
in
phases
could
be
dropped.
Largely
this
is
replaced
by
faceless
new
apis.
A
We
already
talked
about
jakarta,
no
sequel,
jakarta,
mvc
and
potentially
configuration
these
could
be
new
apis
that
are
introduced
in
in
java
e
I've
added
links
to
the
mailing
list
and
the
project
for
all
of
these
specifically
nosql
and
mbc.
They
could
use
some
engagement
and
evaluation
right.
You
could
you
could
get
engaged
in
these
in
this
project
and
see
how
they're
doing
you
know
how?
How
does
it
look
like?
A
You
can
also
get
involved
in
non-specification
projects
right.
So
aside
from
the
specification
project
itself,
there's
a
tutorial,
there's
the
examples
and
there's
also
cargo
tracker
right.
So
these
are
not
as
technologically
advanced
as
as
trying
to
contribute
to
a
jakarta
standard
right.
Most
of
us.
You
know,
I
think,
can
write
tutorials
right
or
write
some
examples
or
write
an
app
a
an
example
application
using
into
an
example
application
using
jakarta.
So
these
are
good
candidates
for
those
type
of
contribution,
if
you're
interested
in
that.
A
So
we
should
also
talk
about
what
is
beyond
jakarta,
etan
right.
So
there
are
also
a
certain
set
of
changes
that
you
could
think
about
after
jakarta,
in
10
is
done
by
the
way,
there's
a
possibility
that
jakarta
18
may
be
done
by
next
year.
Okay,
so
these
are
so
some
of
the
things
that
are
beyond
that,
let's
say
aligning
jpa
with
java
sc
records,
adding
schema,
so
json
schema
support
in
json
processing
and
json
binding
today.
A
A
A
A
Okay,
so
that
is
all
the
questions
that
I
have
I'm
going
to
stick
around
a
little
bit,
but
I'm
going
to
turn
off
my
my
video
or
I'll
or
I'll,
keep
my
video
on
and
see.
If
there's
any
other
questions,
you
know
anyone
that
will
potentially
want
to
come
and
come
online,
come
on
the
screen
and
have
a
chat
with
me
yeah.
It's
really
up
to
you.