►
Description
This presentation will provide an update of the upcoming Jakarta REST releases. Jakarta REST 3.1 will be part of EE 10 and will include numerous improvements and clarifications as well as a new bootstrap API for Java SE development. Jakarta REST 4.0 in EE 11 proposes a backward incompatible change that eliminates its @Context-based injection mechanism in favor of full CDI support. With the advent of CDI Lite, this will also enable support for built-time dependency injection which is becoming more popular with microservices and native compilation.
A
Hello,
everyone
and
welcome
to
another
jakarta
tech
talk
joining
us
today.
We
have
santiago
parikhas
gerstin
to
discuss
the
jakarta
rest
update.
Santiago
is
a
principal
member
of
the
technical
staff
staff
in
the
sun
glass
fish
organization
at
oracle,
as
well
as
an
architect
and
technical
lead
in
the
avatar
project
at
oracle.
If
you
have
any
questions
for
san
diego
as
we
move
through,
today's
presentation
feel
free
to
ask
it
in
the
chat
or
using
the
ask
a
questions
tab
at
the
bottom,
so
without
any
further
delay
santiago
over
to
you.
B
Okay,
so
good
afternoon
and
good
morning,
wherever
you
are
so
today,
I'm
going
to
give
you
an
update
on
jakarta.
Rest
jakarta
rest
is
what
we
used
to
call
jax
harass
so
in
I'm
sure
in
the
presentation,
I'll
be
using
the
two
terms,
interchangeably,
and
I
have
to
say
that
originally
we
had
an
abstract
for
this
presentation
was
were,
which
was
more
focused
on
the
4.0
version.
B
B
I'll
talk
a
little
bit
about.
What's
coming
in
the
future,
which
is
what
we
call
jakarta
rest
four,
and
this
is
going
to
be
a
backward
incompatible
release
and
that's
the
reason
why
it's
been
delayed
a
little
bit
as
well
and
we'll
talk
a
little
bit
about
why
the
incompatibility
and
what
we're
trying
to
accomplish
in
4.0.
B
B
B
So
talking
about
the
the
smaller
clarifications.
First,
if
you're
interested
you
can
use
those
numbers
and
go
check
out.
The
pr's
I'll
include
a
link
to
the
github
location
at
the
end
of
the
presentation,
but
just
briefly
going
over
them.
We've
added
auto
closable
in
in
a
few
more
places
where
it
made
sense.
The
client
is
an
important
one
where,
especially
if
you're
using
clients
on
a
server-side
environment,
you
want
to
make
sure
that
you
close
those
and
you
free
all
the
resources
that
they
take,
which
can
be
significant.
B
B
B
You
always
had
to
specify
them
programmatically
or
via
some
meta
provider
like
a
feature
or
things
like
that.
It
has
been
requested
for
a
while
the
ability
to
use
the
service
loading
mechanism
in
java
to
load
these
providers
and-
and
now
this
is
going
to
be
available.
Finally,
we
have
deprecated
some
things
as
well.
In
preparation
for
release
4.0,
one
of
them
is
get
singletons
one
of
the
things
that
you
need
to
do.
B
When
you
write
your
jakarta
rest
application,
you
typically
have
to
create
what
we
call
the
application
subclass
and
within
it
you
can
override
a
method
called
get
singletons.
This
is
something
that
made
sense
way
back
when,
when
jakarta
rest
was
designed.
It's
not
something
that
is
very
useful
these
days,
especially
when
you
see
their
integration
with
cdi
and
other
things.
So
we're
going
to
be
deprecating
this
now
and
eliminating
it
later
on.
B
We
juxta
has
had
a
static
dependency
on
jax
b
for
a
long
time,
and
this
was
a
bit
unfortunate,
but
it
was
introduced
as
part
of
two
small
classes
that
we
have
and
we
want
to
eliminate
that
compilation
dependency,
so
we're
deprecating
a
couple
of
those.
As
you
know,
most
of
you
use
json
these
days
and
not
so
much
xml,
so
you're
still
going
to
be
able
to
use
jax
v,
but
there
won't
be
any
more
dependency
or
static
dependency.
B
I
should
say
web
application
exception
is
now
serializable,
something
that
probably
should
have
been
for
a
long
time.
Some
improvements
to
the
cookie
class,
as
well
as
a
default
exception
mapper.
So,
if
you're
interested
in
any
of
these
improvements,
please
go
to
github
and
take
a
look
today.
What
I'll
talk
more
about
is
the
new
features
that
we
have
primarily
the
bootstrap
api
and
the
support
for
multi-part.
B
B
We
have,
I
believe,
around
2700
tck
tests.
Not
all
of
them
can
be
migrated,
but
most
of
them
will
be
migrated
over
time.
Release
3.1
will
have
a
subset,
a
pretty
small
subset
of
those,
but
we'll
continue
working
that
on
that
for
the
next
release
all
right.
So
let's
talk
a
little
bit
about
the
new
features
in
3.1,
so
the
first
one
is
the
bootstrap
api.
B
B
Some
implementations
provided
this
support,
but
it
was
not
portable.
So
the
idea
here
is
to
have
something
that
is
portable
across
implementations
and,
of
course,
this
is
going
to
require
the
implementation
to
embed
an
http
server.
In
order
to
provide
this
feature,
and
the
basic
idea
of
the
feature
is
that
you
have
an
application,
you
have
some
configuration,
which
is
all
api
based
as
we're
going
to
see
in
a
moment,
and
you
just
want
to
start
an
http
server
using
your
application
and
don't
have
to
use
any
external
library
for
that
purpose.
B
Let's
have
a
look
at
an
example,
so
the
application
is
what
you
defined
before.
Usually
you
would
override
the
some
methods
in
that
application
and
return
the
classes
and
the
providers
that
you
want
to
use
and
all
you
would
really
want
to
do
once
you
have
a
jakarta
rest
application.
Is
you
want
to
start
an
instance,
an
http
server
and
let
those
resources
become
available
for
clients
to
to
access
so
with
the
bootstrap
api?
It's
it's
a
very
simple
api.
I
should
say
that
it's
still
undergoing
some
changes.
B
There
are
some
there's
a
couple
of
pr's
that
are
in
the
works
to
make
it
a
little
bit
easier
to
use,
but
in
essence
it's
a
reactive
api.
So
you
start
and
you
get
an
event
or
or
information
about
the
instance
once
the
instance
is
up
and
running
and
the
the
idea
there
is
that
you
could
start
up
other
things
in
concurrently
without
having
to
wait
and
and
sort
of
hog
the
the
main
thread
here
once
it
starts.
B
B
B
So
essentially,
what
we're
talking
about
here
is
support
for
the
multi-part
form,
data
type
or
media
type,
and
the
difference
here
is
that
you
can
have
multiple
entities
or
what
we
call
parts
and
each
one
has
its
own
set
of
headers
and
potentially
a
different
media
type,
different
content
and
some
additional
metadata
for
that
part,
and
so
the
way
you
would
produce
multi-part.
Of
course,
we
we
support,
producing
and
consuming
these.
The
way
you
would
produce
a
multi-part
is
simply
using
a
list
of
entity
parts.
B
B
B
B
So
very
simple:
you
can
produce
a
multi-part
multi-part
form
data
entities
now
now
for
the
consumption
part.
As
I
said,
you
have
an
option
to
either
using
a
list
which
would
be
useful
if,
especially
if
you
want
to
process
all
of
them,
but
maybe
you're
interested
in
only
some
of
them,
and
you
can
also
bind
them
to
specific
java
types.
B
So
you
can
use
the
add
form
param
annotation
to
do
that
and
there's
only
a
few
types
that
are
supported,
but
you
can
extend
the
set
of
types.
So
you
can
support
that
using
message
body
readers
as
you
normally
do,
and
but
in
this
example,
we
have
string
input
stream
and
entity
part
you
would
bind
into
an
entity
party
if
you're
interested
in
getting
the
headers.
If
you
do
not
bind
it
to
an
entity
part
then
the
headers
are
not
going
to
be
accessible
to
you.
B
If
that's
important,
that's
what
you
need
to
do.
This
is
similar
to
when
we
use
response
in
a
normal
request
in
a
normal
resource
and
but
other
than
that,
it's
all
very
jakarta
rest
and
fits
in
the
rest
of
the
api
very
nicely.
The
way
you
can
process
these
okay.
So
these
are
the
two
new
features,
more
important
features,
and-
and
again
this
should
have
been
there
for
a
long
time
ago,
but
they
finally
made
it
in.
B
Those
that
have
used
jakarta
rest
for
a
while
have
probably
are
probably
familiar
with
the
add
context,
annotation,
and
this
is
the
way
you
inject
things
that
are
specific
to
jakarta.
Rest
that
are
provided
by
jakarta
rest,
interestingly
cdi
and
jakarta
rest
or
jax
rs,
as
it
was
called
back,
then
sort
of
started
around
the
same
time.
B
B
B
We,
we
define
the
so-called
per
request,
scope
or
per
application
scope,
and
of
course,
these
map
really
nicely
to
scopes
that
exist
in
cdi
and
are
well
known
to
all
the
programmers
which
are
request,
scope
and
application
scope.
So
we'll
definitely
take
advantage
of
those
one
of
the
things
we
never
quite
had
in
jakarta.
Rest
that
it's
another
motivation
to
rely
more
on
cdi
is
the
discovery
part,
so
you
could
do
some
discovery
in
a
servlet
environment
using
the
servlet
extension
mechanism.
B
Some
of
you
may
have
used
that
before,
but,
of
course,
that
doesn't
necessarily
apply
to
microservices,
which
may
or
may
not
be
using
servlets
anymore.
So
the
idea
of
discovery
is
very
useful,
because
sometimes
you
don't
want
to
specify
an
applications
of
class.
You
just
want
your
resources
and
providers
to
be
automatically
discovered,
and-
and
this
is
something
we
can
do
with
cdi
cdi-
supports
portable
extensions
and
with
portable
extensions.
You
can
do
all
sorts
of
things
dynamically
and
we'll
talk
a
little
bit
more
about
that
as
well.
B
So,
as
I
said,
we
want
to
drop
all
the
compile-time
dependency
with
jax
v,
we're
deprecating
it
in
three
one
and
essentially
dropping
it
in
four,
and
I
don't
think
a
lot
of
people
are
actually
using
those
classes.
There's
always
people
that
use
classes,
of
course,
but
I
don't
think
they're
terribly
popular.
B
The
other
thing
we
want
to
do
going
forward
is
review
integration
with
other
specs.
One
of
the
ones
that
comes
to
mind
is
the
concurrency.
Some
of
you
may
have
heard
about
this.
One
jakarta
rest
supports
asynchronous
processing
or
asynchronous
resources.
I
should
say-
and
the
integration
with
concurrency
of
course
would
make
a
lot
of
sense,
and
we
want
to
propose
all
this
for
11,
which
hopefully
will
be
available
sometime
next
year.
B
All
right,
so
let
me
just
make
sure
I
didn't
skip
anything
yep,
so
removal
of
that
context.
What
does
that
mean?
And
what
is
the
implication
of
that
for
developers?
Well,
it's
it's
not
huge,
but
there
are
some
differences
ad
inject
can
be
used
in
for
as
at
context
in
many
places.
But
there's
a
few
places
where
we
need
to
be
careful
ad
inject
cannot
be
used,
at
least
not
as
of
today
in
a
parameter
position,
which
is
something
that
we
use
add
context
for
all
the
time.
B
B
So
this
is
something
that
it
doesn't
make
sense
to
keep
around.
There's
some
exceptions
to
that.
We
can
use
ad
producers
with
context
resolvers
to
filter
on
media
types,
so
we'll
have
to
we'll
have
to
find
an
alternative,
they're,
probably
using
qualifiers
or
something
like
that
in
general
constructor
field
property
injection.
We
can
all
do
it
in
the
same
way
we
do
cdi.
B
B
So
typically
you
don't
have
injection
in
parameters
in
cdi
for
the
most
part,
because
cdi
doesn't
call
your
business
methods
at
least
not
normally,
and
but
in
the
case
of
jakarta
rest.
This
is
something
we
need
to
do
and
we'll
have
full
control
over
that
and
I'll
show
you
some
examples
of
how
that
would
work.
B
The
default
scope
in
3.1
is
per
request,
so
that
maps
rather
nicely
to
request
scope
for
the
most
part,
and
so
in
this
example,
we're
being
explicit.
Maybe
we'll
decide
that
ad
request
scope
should
be
automatically
added
by
the
implementation.
So
you
don't
have
to
worry
about
the
default
scope,
but
just
to
be
explicit.
We're
gonna
put
it
in
here
for
this
example,
things
like
uri
info
and
things
that
you
would
normally
inject.
B
Using
that
context,
you
would
just
inject
using
add
inject
things
that
require
qualifiers,
such
as
a
header
parameter
that
takes
a
specific
name,
would
probably
require
two
annotations.
Unless
we
do
something
about
it
and
you
can
see
the
injection
on
the
right
hand,
side
has
an
add.
Injector,
then
add
header
parameter.
B
B
If
you
had
an
enviro,
if
you
were
working
in
an
environment
where
both
were
available,
there
were
some
problems
with
constructors,
because
essentially
when
the
bean
is
constructed,
it
has
to
be
in
charge
of
one
the
eye
and
not
the
other,
and
when,
when
you
try
to
mix
and
match,
then
you
run
into
problems.
So,
by
moving
to
cdi
we're
going
to
have
more
options
and
we're
going
to
be
able
to
inject
different
types
of
beans
in
the
constructor,
which
were
which
was
difficult
to
do
before
so
the
right
hand.
B
Side
has
an
example
where
we're
injecting
a
regular
bean,
which
is
a
green
bean
cdi
bean,
as
well
as
a
query,
parameter
or
all
in
the
same
constructor,
all
right.
So
to
recap,
field
injection
doesn't
really
change
much.
We
may
have
to
add
inject
in
some
places
where
we
didn't
use
it
before,
and
it's
going
to
give
us
a
few
more
options
when
it
comes
to
constructors
and
and
remove
some
of
the
confusion
about
constructing
means
when
multiple
dependency
injection
mechanisms
are
in
place.
B
What
about
okay?
So,
let's
just
to
recap
the
the
example
at
inject
on
the
constructor,
the
the
ability
to
do
prime
injection
as
well.
One
of
the
little
problems
is
that
cdi
supports
essentially
a
single
constructor.
At
least
up
to
this
point,
jax
rs
decided
to
support
multiple
constructors
and
way
back
when
and
and
it
would
pick
the
one
with
the
largest
number
of
parameters
that
it
can
supply.
B
B
B
B
It's
probably
better
if
we
switch
to
a
again
an
incompatible
change
where
the
entity
is
explicitly
marked
as
so,
so
it
would
be
a
new
annotation
called
identity,
but
the
advantage
of
that
is
that
we
can
then
eliminate
the
need
for
any
annotations
and
pretty
much
anything
else
that
you
we
want
to
inject,
because
we
no
longer
have
this
restriction
that
we
had
before
so
things
like
async
response.
So
this
will
be
an
example
of
an
async
resource.
B
We
use
the
suspended
annotation,
it's
not
really
required
anymore.
If
we
go
in
this
direction,
we
can
just
detect
that
we're
injecting
a
beam
that
is
controlled
by
jakarta
rest
rather
than
the
application,
and,
of
course
it
has
a
special
meaning
for
the
specification
and
can
be
injected
as
such,
the
other
okay.
So,
let's
recap
resource
method
injection.
B
So
one
of
the
things
that
we
don't
need
to
do
is
annotate
the
method
with
at
inject,
and
the
reason
for
that,
at
least
not
up
to
this
point
is
because
the
call
will
be
all
controlled
by
the
jakarta
rest
implementation.
So
we
we
know
what
we're
doing
and
we
know
we
need
to
do
injection
and
it
so
it
only
adds
verbosity.
B
Then
again,
this
just
becomes
beans
that
are
provided
by
the
jakarta
rest
implementation.
So
we
don't
have
to
do
that
anymore,
so
in
some
sense,
in
a
few
cases,
you're
going
to
have
to
write
a
little
bit
more
in
other
cases,
this
is
going
to
probably
simplify
the
implementation
and
eliminate
some
some
annotations.
B
B
These
are
going
to
be
part
of
my
application,
and
this
connects
to
another
slide
about
what
we're
going
to
do
with
the
applications
class
or
what
we
could
do
with
the
applications
of
class
resources
in
request
scope.
We
already
talked
about
that
providers
in
application
scope
and,
of
course,
these
are
the
defaults
just
like
if
you
use
a
jakarta
rest
application
today
in
a
cdi
environment,
you
can
change
the
scope
of
the
beans
as
you
like,
but
by
default.
This
is
what
we're
going
to
do
and
then
for
the
application.
B
Subclasses
there's
a
bit
of
an
exception
here,
because
one
of
the
things
that
we
could
potentially
do
is
support
the
ability
to
have
more
than
one
application,
subclass
and
I'll
wait
on
that
discussion
for
a
bit
and
then
default
scopes
can
be
overreading
as
overwritten
as
I've
already
said,
all
right.
Let's
talk
about
the
applications
of
classes,
so
one
of
the
things
that
we
can
do
with
discovery
is
not
force
the
developers
to
provide
any
application
whatsoever,
and
this
is
something
that
is
already
done
in
some
newer
frameworks
these
days.
B
Essentially,
what
you
do
is
you
just
look
around
and
see
what
are
the
resources
and
what
are
the
providers
that
are
available
and
assuming
that
you
have
discovery,
enabled
you
can
collect
all
these
together
and
sort
of
create
a
synthetic
subclass
without
the
developer,
having
to
specify
that,
of
course,
that's
not
going
to
apply
to
all
the
services,
but
it's
going
to
apply
to
a
lot
of
them.
So
the
cdi
beam
discovery
mechanism
is
is
useful.
B
Now
there
are
some
security
libraries
built
on
top
of
jakarta
rest
and
many
of
those
use
annotations,
and
so
the
natural
place
for
those
annotations
to
live
is
associated
with
applications
of
classes.
Well,
you
could
put
them
in
other
places,
but
this
would
be
one
place
where
you
could
put
them,
and
so
you
could
define
a
different
security
mechanism
for
one
application
supplies
for
those
resources
that
are
public
versus
those
that
are
private
and
so
the
easy,
an
easy
way
to
do.
B
That
is
to
have
multiple
applications
of
classes
that
can
basically
split
the
resources
and
maybe
even
the
providers
that
your
service
has
available
and
now
the
the
problem
with
this
is
that
it
introduces
some
issues
with
scopes,
because
today
you
can
actually
in
fact
inject
the
obligation,
slip,
class
and
the
applications
of
class.
If
that
you
have
it's
going
to
be
obviously
an
application
scope,
but
if
you
have
more
than
one
then
this
becomes
a
bit
of
a
problem.
B
You
would
probably
want
to
inject
the
one
that
is
specific
to
the
request
that
is
being
processed,
which
would
make
that
application
supply
applications
of
class
and
request
go
rather
than
application
scope.
So
the
ability
to
have
more
than
one
application
surplus
opens
the
the
door
for
some
new
use
cases
to
be
easily
supported,
but
at
the
same
time
it
brings
some
problems
that
we
would
need
to
to
solve.
So
so
this
is
still
another
discussion
that
we
we
need
to
have
all
right.
B
B
B
This
makes
a
lot
of
sense
for
certain
cloud.
Applications.
Cloud
functions
is
an
example
of
that,
where
you
want
the
startup
to
be
as
quick
as
possible,
and
you
don't
want
to
be
discovering
the
world
at
that
time
so
cdi
light
is,
is
something
very
interesting.
I
think
that
it's
going
to
be
very
useful
for
jakarta.
B
B
Essentially,
what
you're
doing
on
the
server
side
is
you're,
providing
a
publisher,
that's
gonna,
publish
events
for
the
for
the
client
to
consume,
so
the
equivalent
would
be
the
subscriber
on
the
client
side.
That
would
look
at
those
events
and
process
them,
and
the
the
advantage
of
this
is
that
there
are
a
lot
of
libraries
out
there.
B
So
if
you're
using
a
dependent
scope,
then
this
is
not
a
problem,
but
anytime
you
have
to
do
proxy,
which
of
course,
we
would
need
to
do
or
cdi
we
need
to
do
for
us
in
jakarta
rest.
There
is
this
mandate
of
a
noaa
constructor.
Now
implementations
have
worked
around.
This
weld
has
a
a
way
to
get
around
this.