►
From YouTube: Studio Jakarta EE - Interview with Juergen Hoeller (Spring) | JakartaOne Livestream 2020
Description
Juergen Hoeller and Ivar Grimstad chat between the sessions at Studio Jakarta EE during JakartaOne Livestream 2020
A
A
B
So
hello,
everyone,
my
pleasure
to
be
here
for
start
thanks
for
having
me
I'm
juggin,
I
have
been
doing
doing
the
spring
framework
business
for
a
long
long
time.
I've
been
co-founding
the
project
a
long
time
ago,
back
in
2003
and
have
been
serving
as
the
project
need
for
the
spring
framework
open
source
project.
What
we
call
the
core
project,
pretty
pretty
large
core
project,
but
I
have
been
serving
as
the
project
of
this
for
the
longest
time.
I
always
have
to
check
the
calendar.
A
A
B
So
it
obviously
is
a
big
deal
and
in
in
in
the
java
space
on
the
java
virtual
machine.
Unfortunately,
namespace
changes
are
a
little
hard
to
deal
with
right.
It's
a
totally
incompatible
change.
You
can,
you
can
barely
do
anything
about
it.
You
really
have
to
just
jump
over
and
move
on
with
the
new
namespace
at
some
point-
and
I
guess
that's
exactly
where
we're
in
now
so
yeah
yeah,
it's
up
now
right,
yeah,.
A
As
far
as
it
is
and
and
the
message
we
are
going
with
it
is
that
if
you
are
out
there
and
think
that
this
doesn't
affect
you,
because
you're
not
using
jakarta
e
technologists
and
well
welcome
you're
using
spring
framework,
and
it
will
affect
you
and
but
I
guess
you
are
in
sort
of
a
lucky
position
since
since
you're
a
you're
having
an
abstraction
layer
on
top
of
these
apis.
In
most
cases,.
B
B
A
B
B
So
there's
no
way
out,
as
as
a
current
spring
from
a
5,
3x
user
or
a
spring
boot
to
the
tax
user,
you're
bound
to
the
javax
namespaces,
and
you
will
be
in
that
generation.
We're
not
going
to
do
anything
within
these
these
lines
right.
Those
lines
are
java,
e7,
8
baselines
and
they
you're
supposed
to
use
a
preferably
chubby.
E8
based,
random
environment
hid
10
right.
All
of
those
would
still
be
perfect
choices
or
will
be
in
the
case
of
jd
tennants
just
released
right.
A
B
Yeah
I
mean
chad
11
is
not
kind
of
co
co-managed
now
with
genie
10.
So
it's
effectively
out
right.
It's
you,
you
can
choose
between
chinese
10
and
11.
You
get
the
same
feature
set
just
a
different
name:
space
for
the
survey
api
and
tomcat
nine
and
ten
last
time
I
checked
at
least
they
were
pretty
close
to
that
arrangement,
also
not
differing
much
in
terms
of
their
internals.
B
Pretty
much
co-managed
same
changes,
same
fixes
applied
to
both
branches,
tonkit,
nine
being
x,
namespace
from
kit,
10,
being
jakarta
namespace
and
for
current
spring
applications
and
current
spring
boot
applications.
You
have
to
choose
the
hrx
namespace
like
tomcat9
or
jd10,
but
you
get
basically
all
the
runtime
benefits
because
they
don't
differ
so
tonka,
10
or
jd
11
wouldn't
actually
buy
you
any
any
provider
level
benefits.
They
would
literally
pretty
much
only
give
you
the
new
name
space.
That's
that's
the
point
right
and
that's
also
the
point
of
jakarta
e9.
B
A
B
So
yeah
yeah
it
would.
If
we
don't
change
our
mind,
those
will
be
the
version
numbers
attached
yeah.
We
are
planning
for
spring
for
max
6
and
spring
boot.
3..
We
don't
have
a
fixed
target
tampering
yet
because
it's
they
are
driven
by
several
forces.
The
the
whole
static
image
topic
grounding
native
images,
project
laden,
loom
integration.
B
There
are
quite
a
few
topics
out
there
that
are
of
strategic
relevance
and
that
where
we
would
like
to
pick
up
as
kind
of
essential
pillars
of
of
what
springfield,
6
and
spring
group
3
will
be
move
to
the
jakarta.
Namespace
is
also
a
at
this
point,
a
fixed
part
of
it
right.
So
unless
something
earth
shattering
happens,
springfield
max
6
and
springboard
3
will
be
using
the
jakarta
names
based
servlet,
api
persistence,
api
beam
edition,
api
and
so
forth.
B
B
A
B
It's
the
availability
of
the
providers
in
generally
available
versions
in
production
versions
that
we
can
pick
up
in
particular
for
sprinkle.
Three
we
need
to
bring
in.
We
are
doing
dependency
management
for
those
providers,
so
we
need
to
to
bring
in
a
a
complete
set
of
providers
that
work
in
the
given
arrangement.
B
So
at
this
point
this
is,
I
would
say
at
least
it
we're
talking
about
late
next
year
as
a
rough
guidance
right,
but
it's
hard
to
tell
we
might
if
there
are
forces
that
allow
us
to
release
a
little
implant.
We
will
take
that
opportunity
if
there's
something
to
wait
for
something
very
strategically
important
to
wait
for
our
particular
open
gdk
generation.
B
This
might
also
influence
the
plan,
but
the
good
thing
is
we're
going
to
get
jdk
17,
with
the
assumption
that
it's
going
to
be
a
long-term
support
release
again
in
september
next
year.
So
that
is
also
an
important
part
of
the
plan
and
certainly
something
we're
waiting
for,
because
everything
that
is
coming
together,
there
is
of
of
total
importance
to
our
audience
right.
We're
currently
supporting
basically
the
average
jdk
up
from
eight
and
upwards,
but
we'd
really
like
to
move
on
from
the
current
jdk8
baseline
to
something
higher.
B
So
jdk
17
is
a
very
important
part
of
this,
and
and
provided
a
lot
of
things
with
with
integrating
with
so
yeah
that
those
are
the
the
things
need
to
come
together.
Kdk
17
should
be
out
before
springfield
six
and
put
three
will
go,
live
yeah,
we'll
we'll
we'll
see
what
what's
happening,
but
I'm
I'm
sure
that,
with
the
pace
that
this
industry,
the
java
industry
had
in
the
like
past
couple
of
years
and
this
year
still,
we
will
see
a
lot
happening
next
year
in
2021.
B
Yeah,
well
quite
a
few.
Actually
I
would
I
would
have
to
look
it
up
specifically,
but
on
the
expert
groups
we
are
on
definitely
on
general
persistence,
quite
active
sort
of
engaged
with
beam
validation,
even
if
not
immediately
in
the
expert
group.
So
there's
there's
quite
a
few
that
we
have
contributed
to
in
some
form
right
and
in
particular,
a
lot
of
the
providers
we
we
are
pretty
active
in
contributing
to
the
reference
implementations
or
the
common
common
providers
of
quite
a
few
of
those
apis
out
there.
B
So
we
are
very
much
connected
to
the
to
the
ecosystem
out
there.
It
is
now
going
to
move
on
to
jakarta
apis
right,
jakarta
names
based
apis,
and
this
is
also
part
of
what
we
intend
to
to
move
on
with
right.
We
we
not
only
want
to
have
been
involved
in
some
jsrs
in
the
past
somewhere.
We
also
want
to
be
involved
in
where
those
those
jakarta
names
based
apis
and
their
where
they
are
going
right.
B
The
next
steps,
after
jakarta
e9
are
almost
more
important
for
us
than
the
name
space
question.
There's
there's
always
room
for
improvement.
I
would
argue
in
the
case
of
the
java
persistence,
api
and
jakarta
persistence,
api
and
a
few
others
there's
actually
a
backlog
of
things
that
should
have
happened
for
many
years
already,
so
we're
looking
forward
to
helping
out
in
in
processing
that
backlog
and
kind
of
bringing
the
apis
up
to
date
with
where
they,
where
they
really
should
be
in
2021
and
onwards.