►
Description
Speaker: Reza Rahman
///GET SOCIAL!
Subscribe: https://www.youtube.com/user/EclipseFdn
Follow us on Twitter: https://twitter.com/JakartaEE
Follow the conference: https://twitter.com/JakartaOneConf
Like us on Facebook: https://www.facebook.com/JakartaEE/
Become a member of our Jakarta Tech Talks Meetup: https://www.meetup.com/jakartatechtal...
Join us on LinkedIn: https://www.linkedin.com/groups/13597...
Tag us: #JakartaEE #JakartaOneLivestream
A
And
live
so
hi
everyone.
A
We
are
improvising
your
great
deal
just
because,
as
always
when
we're
online,
we
do
hit
some
technical
difficulties.
But
nevertheless,
here
we
are
with
our
program,
chair,
Reza
rock
man,
and
we
are
going
to
take
advantage
for
the
next
20
years
to
ask
questions
and
do
clarifications
for
people
out
there.
So
please
take
advantage
of
this
opportunity
and
ask
any
questions
you
may
have
and
Reza.
If
you
want
to
raise
something
with
us
and
and
give
us
heads
up
to
any
of
your
thoughts,
that
would
be
greatly
appreciated.
B
Yeah
I
think,
let's
do
that.
I
I
don't
have
I'm
trying
this
on
my
phone
I'm
having
some
kind
of
issue
that
I'm
I'm
gonna
sort
out
before
my
next
session,
but
I
think
I'm
gonna
give
people
a
little
bit
of
time
to
think
about
their
questions.
Servlet
4
is
enormously
important.
If
there
is
one
API
that
is
important
for
Jakarta
e8,
this
one
is
it
so,
please
and
I
know
you
know
we
had
some
technical
difficulties
with
Eid
session
and
I
very
much
apologize
for
that
you'll.
B
Definitely
get
this
sorted
out
and
you'll
be
able
to
see
the
right
video
on
on
YouTube
on
the
recording.
So
please
do
gather
your
thoughts
on
what
kind
of
questions
you
would
like
to
ask
me
and
Tanya.
If
you
can
do
me
a
favor
and
just
relay
those
questions
to
me
and
I
will
answer
them,
but
before
I
do
that
I
would
like
to
share
some
thoughts
with
the
audience,
and
maybe
this
will
help
us
jog
all
of
our
thoughts
as
well.
B
So
one
of
the
issues
with
any
vendor
specification
or
Bay
or
body
of
work,
even
if
its
proprietary
work
or
open
source
work,
is
that
vendors
need
feedback
right.
So
they
are
people
as
well.
Just
like
just
like
you
and
me,
you
and
I
maybe
work
on
enterprise
projects,
and
you
know
how
thankless
that
is.
It's
the
same
for
vendors.
These
are,
at
the
end
of
the
day,
just
normal
human
beings,
with
their
emotions
and
motivations
and
so
on.
B
So
the
way
to
get
things
done
and
the
way
to
motivate
a
lot
of
these
vendors
is
speaking
to
them
as
your
valued
vendor
right
the
person
that
provides
you
these
useful
services
that
you
build
all
these
useful
applications
on
top
of
and
talk
to
them
about.
What
is
it
that
your
needs
are
so
believe
me
servlet
is
anything
but
done.
So
let
me
spend
a
little
bit
of
time.
You
know
sharing
my
ideas
on
what
I
see
servlet
going
and
in
general,
the
service
layer.
B
So,
let's
start
with
just
a
service
layer
itself
as
a
bit
of
functionality
and
let's
forget
what
the
API
for
a
second,
so
the
servlet
model
is
built
on
a
synchronous
request
response.
This
is
a
very
old
model.
It's
a
proven
model
that
we've
had
since,
in
fact,
the
early
80s,
but
the
one
model
that
is
sort
of
challenging
that
in
turn,
notion
is
non-blocking
I/o.
So
these
sorts
of
changes
need
to
happen
bottom-up,
starting
from
the
surface
in.
A
B
There's
a
couple
of
different
ways
of
addressing
it:
you
can
either
address
it
by
you're,
creating
a
new
specification
or
you
can
Rea
engineer
the
servlet
specification
to
become
reactive
and
to
become
non-blocking.
So
that's
a
very
broad
swath
of
a
very
large
body
of
work
that
needs
to
be
done
in
the
servlet
space.
But
beyond
that,
let's,
let's
assume
for
a
second,
that
we
don't
go
the
reactive
way
and
we
just
stick
with
sort
of
it.
B
So
we
need
to
keep
an
eye
on
that
as
an
industry
and
sooner
or
later,
essentially
re-engineer
the
server
spec
and
do
a
rev
of
the
existing
API
to
absorb
these
changes
in
a
HTTP
3
right.
So
these
are
all
four
important
protocol
layer
changes
that
we
need
to
enable
server-side
developers
to
take
advantage
of
these
features.
So
these
are
just
some
of
the
things
and
and
Ede
already
talked
about
alt
and
support
done
properly.
B
In
the
servlet
API,
independent
of
whatever,
is
and
is
in
the
JDK,
so
these
sorts
of
things
don't
have,
as
you
said,
mentioned
right
now.
These
are
not
necessarily
things
that
the
servlet
vendors
are
motivated
to
do,
and
the
motivation
needs
to
come
from
you
it's
an
it.
Can't
always
be
people
like
me
that
go
and
talk
to
these
vendors
and
say
hey
well,
why?
What
about
this?
You
know
why?
Don't
you
do
this?
B
Ultimately,
they
don't
want
to
hear
from
people
like
because
I'm
they
see
me
as
pretty
much
one
of
one
of
them,
rather
than
the
way
they
look
at
you,
which
is
their
customers,
so
they
need
to
hear
from
you
on
these
things.
You
know
you
need
to
ask
these
questions
and
you
need
to
engage
them
in
dialogue
and
assure
them
that
these
are
things
that
matter
to
you
and
things
that
you
would
like
to
get
done
and
Java
EE
in
this
entire
specification.
B
Moving
from
the
J
CP
into
the
eclipse
foundation,
that's
fundamentally
what
this
objective
is
all
about.
This
is
your
opportunity
to
engage
these
vendors
in
a
way
that
maybe
you
weren't
able
to
do
in
the
past,
so
I've
been
talking
for
a
little
while
I,
don't
know
how
much
time
I
have
left
I
hope
my
ramblings
are
somewhat
useful.
I'm
gonna
stop
now
and
hope
that
there
were
some
questions
which
I
cannot
see
I'll,
let
you
read
those
and
I'll,
try
and
answer
them.
Yes,.
B
B
That's
never
been
the
WebLogic
team's
preferred
way
of
doing
things,
so
I
believe
some
of
the
investment
into
Eclipse
loss,
which
will
continue
to
come
from
Oracle
by
virtue
of
the
fact
that
they
will
treat
lost
fish
as
sort
of
a
laboratory
innovation
laboratory
for
the
work
that
they'll
be
continuing
to
be
doing
moving
forward
in
Jakarta
ii,
and
of
course,
this
was
provided.
That
oracle
continues
to
be
a
significant
player,
which
you
know
on
the
surface
that
they
said
they.
They
will
do
that,
and
I
have
no
reason
to
not
believe
that.
B
In
addition
to
that,
I
believe
in
order
to
keep
GlassFish
alive,
there
will
have
to
be
some
investment
from
the
payara
folks,
so
they
will
need
to
invest
a
bit
more
than
what
they
have
traditionally
so
they've
been
I.
Think
some,
the
investment
that
comes
from
Oracle
so
I
believe
they
will
need
to
step
up
their
game
and
maybe
the
Delta
between
payara
and
GlassFish
becomes
smaller,
then
and
then
it
has
been
today
and
finally,
it's
you,
the
community
right.
B
So,
if
you're
going
to
contribute
to
something,
please
consider
contributing
to
Gloucester,
nobody
really
owns
it,
it's
an
orphan
right.
So
why
not
help
the
orphan
instead
of
helping
the
the
implementations
that
have
multi-billion
dollar
revenue
streams
behind
it,
though
those
implementations,
don't
really
need
your
help
right.
The
implementation
that
knee
your
help
is
the
small
guys
like
Tommy
and
and
payara
in
Gaza.
B
B
Basically,
the
approach
is
in
the
first
as
a
first
step
taking
out
those
services
that
are
currently
defined
in
EJB
and
creating,
hopefully
better
api's
that
are
CDI
replacements,
CDI
services.
Replacements
of
of
each
of
those
api
is
in
a
piecemeal
fashion.
A
majority
of
that
is
going
to
go
into
AE
concurrency.
B
According
to
our
our
ideas
that
we've
had
for
a
number
of
years
now,
and
once
we've
done
that,
then
we
can
talk
about
the
ideas
that
Adam
has,
which
is
to
create
stereotypes
that
would
be
roughly
the
equivalent
of
what
EJB
is
today
and
then
the
final
step
would
be
to
prune
declare
EJB
to
be
pruned
and
then
finally
deprecated
it
should
be
optical,
so
I
imagine
this
is
going
to
take
if
I
were
to
estimate.
You
know
this
we're
talking
about
a
two
year
time
horizon.
B
So,
if
you're
using
EJB
today,
I,
don't
think
there's
a
reason
to
panic,
I
think
you
need
to
embrace
the
future
and
look
at
the
ideas
that
were
proposed
and
bring
your
own
ideas
and
give
us
feedback
on.
You
know
what
we've
gotten
wrong,
what
we've
gotten
right
and
in
these
draft
ideas
that
we've
talked
about
for
some
period
of
time,
and
then
you
have
time
to
adapt
right.
So
it's
not
like
anyone
is
pulling
the
EJB
rug
from
under
your
feet.
It's
it's
more
about
evolving.
The
platform
going.
B
Non-Working
thread,
api's
I,
believe
these
are
much
more
important
than
necessarily
what
ultimately
will
wind
up
boil
down
to
CDI
alignment.
I,
don't
know
how
many
people
are
using
the
CDI
programming
model
at
the
servlet
error.
In
fact,
I
don't
even
know
how
many
people
are
using
the
servlet
API
plane
these
days.
You
know
I.
Think
James
Gosling
is
a
is
an
exception.
Most
of
us
don't
do
not
program
its
orbit.
So
me
personally,
I
mean
opinionated
guy,
maybe
maybe
some
time
not
for
the
best.
But
in
my
opinion,
I
didn't
mind.
A
B
So
again,
I'll
give
you
my
opinion
a
to
take
on
this
right,
so
we've
had
a
platform
that
has
basically
stagnated
for
two
years
right
so
cleanup.
You
know:
we've
had
the
cleaner
problem
for
10
years
now,
10
for
those
of
us
who
aren't
watching
it.
You
know
all
the
people
that
will
tell
you.
You
know
this
needs
to
be
cleaned
up.
That
needs
to
be
cleaned
up
well.
B
That
stuff
has
been
around
for
almost
10
years
now
right,
so
you
have
to
evaluate
what's
important
right,
III
believe
the
clean
up
stuff
can
wait
until
we
prove
from
a
business
standpoint.
What
is
the
value
proposition
of
Jakarta
II,
and
in
order
to
do
that,
you
need
new
features
first
right,
so
you
need
to
show
people
useful
things
that
they
can
do
with
this
platform
already
right
and
not
focus
so
much
on
cleaning
up
house
so
on.
There
will
be
time
for
cleaning
up
the
house
early
right
now.
B
B
Deserts
and
I
I
can
talk
the
talk
in
terms
of
servlet
I,
it's
difficult
for
me
to
walk
the
walk
at
the
end
of
the
day.
My
layman's
view
is
that
the
servlet
API
can
be
refactored
to
make
it
in
I/o,
because
a
lot
of
these
API
is
fundamentally
things
like
request
response,
you
know
the
fundamental
servlet,
API
I
think
these
are
the
right
paradigms
to
begin
I,
don't
think
the
paradigm
change
very
much
I
think
you
can
refactor.
B
These
API
is
to
to
absorb
non-blocking
a
non-blocking
thread
model,
but
to
get
honest
when
I,
they
tell
me
I'm
any
I'd
yet
right
so
they're
telling
me
this
is
not
the
right
way
of
thinking
right
and
they
may
be
right
that
they
may
be
correct
in
thinking.
You
know
you
need
a
full
rewrite
that
has
nothing
to
do
with
servlet
at
all,
and
it's
a
brand
new
brand
new
technology.
I
do
not
know
enough
to
give
you
an
intelligent
answer.
B
I
think
it's
best
to
trust
the
experts
and
work
with
the
experts
when
they
have
the
appetite
to
do
this
work
and
evaluate
at
that
point
in
time
whether
what
these
folks
are
proposing
makes
sense
or
they're
simply
reinventing
the
wheel
for
the
sake
of
reinventing
the
wheel
and
if
they
are
doing
that,
then
as
an
end
user,
you
can
give
them
that
feedback
down
to
say
hey.
Why
are
you
reinventing
the
wheel
right?
These
are
paradigms
we've
seen
already.
Why
can't
we
just
use
this
formula?
Tapi
is
instead
of
inventing
a
new
thing.
B
Yes
unknown,
so
you
can
I'll,
give
you
my
honest
answer.
The
problem
is
where
services
service
is
really
relevant
is
with
cloud
vendors,
myself
included
as
rent
with
it,
AWS
included,
Google
included.
They
have
reasons
not
to
write
api's
that
are
very,
very
bound
to
jakarta
ii
right.
So,
at
the
end
of
the
day
there
they
need
to
serve
a
broader
market.
Then
simply
Java
developers
right
so
serve
those
platforms
need
to
be
language
agnostic.
B
There
is
a
de
facto
reason
why
these
API
is:
it's
very
tough,
sell
for
a
cloud
provider
to
standardize
the
server
unless
API
is
on
something
like
Jakarta.
He
because
effectively
you're,
creating
a
variant
that
has
nothing
to
do
with.
You
know
the
rest
of
the
API.
Is
it
you'll
be
supplying
your
other,
your
other
customers
other
than
Java
customers?
B
So
what
I
believe
is
relevant
is
something
like
workers,
so
basically
something
that
allows
you
to
still
use
Java
EE
api's.
On
top
of
these,
if
you
will
proprietary
service
platforms,
but
does
it
in
a
way
that
is
that
works
in
surplus
right,
so
in
surplus,
the
biggest
problem
is
shut
down
and
start
up
and
tear
down.
So
you
need
that
to
be
super
fast
in
a
service
environment.
So
I
think
that's
what
the
actual
console.
That's.
What
the
real
answer.
Practical
answer
of
there
is
now
that
is
not
to
say
something
like
eclipse.
B
Jimo
is
not
relevant
right,
so
that's
an
effort
where
it
is
taking
Djakarta
api's
and
creating
a
service
API.
On
top
of
it,
that's
supposed
to
be
running
on
cloud
providers
infrastructure,
but
again
from
a
practical
standpoint,
let
me
tell
you
in
serve
lists.
You
need,
like
optimization,
optimization,
optimization,
it's
more
much
easier
to
have
a
proprietary,
API
and
optimize
a
proprietary
API
in
proprietary
ways,
and
that's
very
difficult
to
do-
is
for
somebody
else,
that's
outside
of
that
cloud
provider.
So
maybe
it's
not
the
right
answer
that
we
want
to
hear
about.
B
A
B
Not
that
I
know
of
if
you
have
ideas
in
mind,
please
share
them.
I,
don't
I
haven't
used
JSP
and
ages,
I'm
a
JSF
guy
a
long
long
time
ago,
but
that
doesn't
mean
there
aren't
things
in
India,
which.
B
That's
a
really
tough
one,
so
core
by
interoperability
is
one
you
to
some
of
the
obscure
things
that
are
kind
of
being
superseded
by
Jacques,
a
security
like
Jack
and
jazz.
Those
would
be
good
candidates.
I
personally,
have
a
really
hard
time
saying
with
confidence
that
this
particular
technology
X
from
job
ie
has
should
be
pruned
because
we've
been
doing
that
for
a
while.
It's
we
started
this
work
in
Java
EE
6
12
years
ago
right,
so
we
already
have
done
a
lot
of
pruning.
B
A
Let
me
squeeze
one
more
and
then
we'll
have
to
move
to
next
session.
Jakarta
rust
is
officially
not
based
on
servants.
Do
you
think
it
should
be
so
people
don't
have
to
avoid
using
servant
api's
in
rust,
or
should
a
common,
smaller
API
be
split
off
from
servlet
and
used
by
both
server
in
Jakarta,
rust.
B
So
I'll
tell
you
the
little
bit
of
the
dynamics
behind
this
okay,
so
the
problem
is
that
the
rest
implementers
have
their
own
ideas
of
what
they
want
to
do
at
the
fundamental
protocol
layer
right.
So
a
lot
of
them
are
based
on
Nettie.
A
lot
of
them
are
based
on
even
something
like
grizzly,
and
they
have
good
reasons
to
be
doing
that,
so
they
have
a
good
reasons
to
decouple
those
sores
from
servlet
engines,
so
I
think
it's
best
to
trust
the
judgment
of
these
people.
B
I
mean
the
jack
services
is
a
pretty
successful
API.
It's
probably
a
mistake
to
try
to
tell
these
people.
No,
you
shouldn't
be
doing
what
you
want
to
be
doing,
and
you
must
use
us
for
bit
engine
under
the
hood
I
think
we
have
bigger
problems
to
worry
about
in
Jakarta
even
than
this,
and
forcing
jax-rs
vendors
to
implement
things
a
certain
way.