►
From YouTube: Jakarta EE Community Call | 2019-07-17
Description
The Jakarta EE Community call is a monthly meetup via Zoom that drives community conversation and provides a space for participants to ask questions on topics of interest in an Ask Me Anything (AMA) format.
// AGENDA
-Jakarta EE 8 release
-Status on progress and plans (Ed Bratt / Dmitry Kornilov )
-Jakarta EE TCK process update (Scott Stark )
-Brief update re. transitioning from javax namespace to the jakarta namespace (David Blevins)
-JakartaOne Livestream - (Tanja Obradovic)
-EclipseCon Europe - (Tanja Obradovic)
-Open discussion and questions
/// JOIN THE CALL
To join the next community call click the link to add it to your calendar: https://calendar.google.com/calendar/...
//// 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
A
A
There's
a
lot
of
activity
if
you're
subscribed
to
any
mailing
lists
or
or
watching
any
github
projects.
I'm
sure
you've
seen
you
know
a
some
smattering
of
discourse
going
back
and
forth.
It
certainly
has
ramped
up
in
the
past
several
weeks,
so
good
great,
to
see
all
that
progress,
the
the
just
to
sort
of
get
us
back
to
where
we
were
last
month
right.
The
deliverables
for
jacquard
e8
haven't
changed
at
all
right,
we're
still
planning
to
deliver
a
complete
set
of
Jakarta
e8
specifications,
and
these
will
each
consist
of
a
specification
document.
A
A
It
will
include
a
new
T
so
that
so
it's
a
new
API
with
that's
licensed
under
Eclipse
EPO
and
using
all
the
Eclipse
development
process
will
have
tcks.
There
are
where
we
have
produced
to
essentially
make
the
same
collection
of
tests
that
we
used
in
Java
EE
releases,
but
now
they're
there
they're
testing
for
compatibility
with
jacquard
ee
and
we're
essentially
introducing
this
new
component.
This
new
idea
about
what's
called
a
compatible
implementation,
and
so
in
that
again
I'll
talk
a
little
I.
A
Think
I'll
talk
a
little
bit
about
that
in
a
following
slide,
so
the
specification
process.
This
is
following
the
the
Eclipse
Foundation
specification
prior
process.
You
might
see
that
that
as
abbreviated
EF,
SP
yeah
and
one
thing
is,
there's
a
brand
new
version
that
was
just
ratified
and
as
I
think,
it's
posted
on
the
Eclipse
specifications
project
and
then,
along
with
that,
we've
also
done
a
rev
on
the
jacquard
EEE
specification
process.
So
what
the
way
Eclipse
makes
this
work
is
there's
a
sort
of
a
master
process.
A
They
it's
the
Eclipse
Foundation
specification
process
and
then
there's
a
then
each
specification
project
can
add
their
own
sort
of
special
nuances
to
the
overall
process.
Alright,
so
we've
just
ratified
a
new
version
of
that
I.
Don't
think
it
wasn't
posted
yesterday,
it's
probably
going
to
get
up
be
put
up
pretty
real
soon,
but
I
put
some
put
a
link
in
it.
They
both
of
these
links,
have
not
changed
from
what
they
were
before
have
them
in
a
web
page.
A
But
you
know
in
the
interest
of
time,
I'll
just
sort
of
skip
that
for
now
and
I
think
the
the
main
thing,
the
least,
as
the
sort
of
you
know,
worried
about
trying
to
get
this
out
on
time.
The
main
thing
that's
updated
in
the
new
jacquard
EEE
specification
is:
we've
dropped
the
minimum
ballot
period
from
30
days
to
2
weeks,
so
that
should
give
us
a
little
bit
of
breathing
time.
A
This
project,
okay,
so
the
specifications
our
goal
is:
if
you
have
a
Java
EE
eight
implementation,
you
should
be
able
to
just
unpack
the
the
new
tcks
and
run
them
in
exactly
the
same
way.
You
ran
them
before
and
you
should
be
able
to
achieve
a
compatibility.
A
you
know,
a
compatibility
test,
output
that
matches
what
you
had
in
Java
EE,
eight,
that's
a
key
goal
of
this
release.
A
Let's
see,
we
have
finished
revive
it
revising
all
of
the
the
specification
project.
So
now
there,
if
you
go
and
look
at
the
specifications,
oh
great,
that's
going
to
open
on
the
wrong
window.
So
alright!
So
when
you
look
at
the
e4j
top-level
project
page
over
here
on
the
right
side,
you
see
a
whole
bunch
of
them.
The
new
prod
many
projects
are
here.
A
lot
of
them
has
changed
names,
and
essentially
everything
that
starts
with
Jakarta
is
now
I.
A
Think
that's
a
pretty
good
metric
here
is
now
a
special,
an
API
specification
project,
and
this
these
will
all
these
all
constitute
the
the
the
sort
of
the
collection
of
Jakarta
api's
they
are
and
every
one
of
them
is
staged
poised
and
ready
for
a
release.
That's
what
that's
gonna
come
up
and
our
target
date
is
still
the
same.
September
10th
right
in
these
slides
and
I'll
put
the
I'll,
send
I'll
push
the
post
these
to
the
same
place.
We
hadn't
posted
them.
Last
month.
A
We
will
be
creating
ballad
submissions,
they
were
the
the
intent
is
to
use
the
github
pull
requests
to
to
as
a
way
of
submitting
them
and
then
tracking.
The
approvals
and
I
listed
a
couple
of
I
I
list
a
couple
of
these
pull
requests
here.
Just
so
we
you
know,
so
we,
if
you
want
to
if
you're,
interested
in
sort
of
voyeurism-
and
you
just
want
to
watch
these
projects-
you
could
just
watch
this
project.
A
Jakarta,
AE,
/
specifications
just
look
for
pull
requests
and
over
time,
you'll
see
more
and
more
of
the
specifications
themselves
show
up
here
and
you
can.
You
can
actually
open
any
one
of
these,
and
each
of
them
has
this
nice
collection
of
them
of
checkboxes.
All
those
need
to
be
satisfied
and
when
they're
all
checked
off
I
think
they
believe
that
that
means
that
that
specification
has
been
proved.
A
We
have
a
I
mentioned
the
jacquard
ee8
tcks.
So
from
a
test
perspective,
these
are
identical
to
what
used
to
be
licensed
to
Java,
EE
licensees
and
those
T
CK's
are
all
running
right.
Now
we
have,
we
have
essentially
have
the
same
level
of
of
operational.
You
know
reliability
as
we
had
with
them
with
Java
EE
accepted
they're.
Now
all
open
sourced
and
you
can.
You
could
download
the
test
versions
they're
available
right
now
or
you
can
once
they're
a
part
approved
as
part
of
the
specification
process.
A
Sorry
not
not
running
my
computer
correctly,
all
right,
so
we've
done
a
lot
with
the
TC
k
set
up.
Many
of
the
API
projects
are
now
are
busy
incorporating
TCK
test
jobs
in
directly
into
their
jacquard
ee
processes.
I've
listed
a
couple
of
of
the
pull
requests
that
people
I've
are
using
to
to
sort
of
document.
How
these
things
are
integrated
beyond
Cipolla
out
of
our
Prague
office
has
been
instrumental
in
trying
to
get
these
set
up.
A
And
I
don't
mean
if
I
didn't
mention
your
organization,
that
doesn't
mean
anything,
it's
just.
Those
were
the
two
that
I
could
think
of
right
away.
So
if
you
want
to
watch
things
right,
I
would
say
start
with
them:
get
up
calm
them
the
main
project
and
pick
an
API
project
that
you're
interested
in
and
you
know,
use
the
github
watch
button.
A
There's
an
awful
lot
of
back
and
forth
discussion
that
goes
along
that's
associated
with
the
pull
requests
and
with
issues
there
are
there's
a
giant
collection
of
mailing
lists
that
are
available
on
available
from
eclipse.
The
thing
is
that
you
know
the
the
data
from
those
two:
don't
really
intermingle.
So
if
you
want
the
full
view,
you
may
need
to
subscribe
to
both
for
the
projects
that
you're
interested
in
and
if
and
then
you
want
to
watch
these
PRS
pull
requests
to
the
github
Jakari
specifications
project.
A
That's
where
you'll
see
the
specifications
flowing
in
alright
and
I'm
now
at
my
deadline.
So
just
continue
to
remind
people
if
you,
if
you
are
interested
in
contributing
to
jacquard
EEE,
you
don't
need
to
be
a
developer.
There's
an
awful
lot
of
writing
level
things
right.
We
still
have
to
get
websites
created
for
most
of
these
projects.
A
We
have
a
template
and
a
a
mechanism
in
place
for
so
for
rolling
up
all
that
all
of
their
websites,
but
we
do
need
people
just
too
that
are
that
have
some
skills
with
them,
setting
up
web
websites
and
and
maybe
a
you
know,
can
either
write
text
for
them
or
maybe
can
write
them.
You
know,
can
put
them
into
into
markdown
flavored
pages.
We
can
certainly
use
help
for
all
of
that.
A
The
the
set
of
for
forums
joining
him
to
project
is
the
same
as
it
was
you
know.
Has
it's
been
I
think
with
the
coops
for
years
right
anyone
can
subscribe
to
the
mailing
lists.
You
can
always
follow
all
the
projects
and
activity
that's
going
on.
You
don't
have
to
have
anything
to
follow
github
projects
except
the
github
ID.
If
you
want
to
make
a
commit
or
submit
a
PR,
you
do
need
to
create
a
in
Eclipse
account
and
and
you'll
also
need
an
eclipse
account.
A
B
A
C
A
A
Earlier
something
about
the
specification
documents
in
this
initial
round
we're
basically
just
relying
on
the
collection
of
a
sort
of
a
framing
document,
which
you
know
it's
replacing.
What
used
to
be
the
the
detailed
specification
and
then
a
reference
to
you
know
the
the
specification
itself
will
include
the
Java
Docs.
So
the
API
is
the
details
about
how
to
use
the
api's
will
be
only
in
the
Java
Docs.
C
B
D
So
just
gonna
quick,
quick
update
on
what
the
specification
community's
been
up
to
the
past
ever
since
our
last
call
the
past
month,
and
primarily
the
focus
has
been
on
defining
the
TCK
process,
updating
ORD
of
filling
out
a
jacquard
ET
specification
process,
guide
and
operation
of
the
spec
committee
and
then
focus
on
what
does
that
actually
imply
for
api
projects
in
the
jacquard
ee8?
Really
so
take
a
quick
look
at
those
three
things.
D
So
we
just
last
last
week
we
released
the
initial
version,
one
of
the
TCK
process
and
announced
it
to
the
specification
leads
list.
You
can
find
that
document
here
in
the
public
public
drive
of
the
specification
committee.
The
highlights
were
that
we
define
the
materials
for
a
TCK
release
which
IDI
talked
about
in
his
presentation.
We
defined
a
process
to
challenge
TCK
tests,
and
then
we
defined
a
process
to
define
or
to
claim
compatibility
for
certified
implementations.
C
D
Most
of
the
content
they
move
forward
last
week
as
well.
They
announced
on
the
spec
lead
list
and
the
link
is
here
the
highlights
that
we
defined
a
number
of
operations.
The
suspect
committee
in
terms
of
boats
and
how
reviews
specific
aspect
released
reviews
were
we're
done,
in
particular
what
that
meant
from
the
perspective
of
a
specification
project
and
what
it
needed
to
do.
You
know
in
terms
of
actual
details
and
there's
a
one-page
wiki
that
tries
to
collapse
all
that
information
together.
D
That's
listed
here
about
how
to
prepare
API
projects
should
be
actually
for
Jakarta.
Eight
releases
that's
been
updated
to
reflect
those
changes
in
the
TCK
and
jess
ops
guide.
It's
a
living
document
that
were
we've
been
updating
pretty
much
on
a
daily
basis,
as
projects
are
going
through
this
process
and
were
you
know,
discussing
issues
that
are
run
into
on
the
on
the
spec
leads
and
platform
development
mainly
lifts.
D
If
you
have
questions
about
that,
then
definitely
get
on
the
spec
leads
list
and
then
send
those
in
or
if
you're,
not
if
you're,
not
the
leading.
You
still
have
a
question
because
you're
involved
in
the
project
probably
send
it
to
the
either
get
your
lead
to
do
it
or
send
it
to
the
the
public,
expect
committee
list
and
that's
pretty
much
what
we've
accomplished
so
far.
E
B
B
E
E
Okay,
so
the
that
you
know
the
Jakarta
eat
Java,
X
transition
conversations
largely
died
down
in
the
community,
but
I
do
think.
There's
an
important
aspect
that
we
are
missing
in
the
conversation
because
we've
become
you
know
focused
on
on
Big
Bang
versus
incremental,
but
it's
important
to
remember
that
in
the
definition
of
Big
Bang,
there's
still
the
option
for
us
not
to
move
everything,
and
there
are
really
good
reasons
to
do
that
and
that
that
that's
an
important
conversation
to
have
that
comes
for
free
in
the
incremental
perspective.
E
But
if
you
have
a
Big,
Bang
mindset,
you
still
need
to
keep
in
mind
some
aspects
that
people
have
that
are
issues
that
we
can
address
by
not
moving
everything.
One
is
that
you
know
we
know,
there's
a
cost
to
legacy
right,
there's
a
lot
of
stuff
that
people
don't
even
know
about
that
they
don't
use
and-
and
the
quote
I
don't
need.
That
is
a
very
big
thing
that
people
like
to
throw
at
Java
EE
now
Jakari
EE.
So
you
know
just
because
something
is
there
does
do.
E
We
need
to
actually
refresh
it
and
move
it
into
the
Jakarta
namespace,
or
is
it
fine
living
forever
the
rest
of
its
days
in
Java
X?
The
other
aspect
is
size.
People
will
often
say
things
like
Java
EE
is
too
big.
This
is
our
opportunity
to
address
that
kind
of
concept,
and
you
know
maybe
some
things
just
stay
where
they
are,
and
the
other
important
thing
to
remember
is
that
just
because
we
don't
move
it
to
Jakarta
doesn't
mean
it's
dead.
E
It
means
we
just
don't
see
any
reason
that
it
needs
to
evolve
and
it
can
continue
to
run
just
fine
under
Java
X,
and
so
just
because
something
doesn't
move
doesn't
mean
you
can't
use
it
anymore.
It
means
you're
not
going
to
have
to
invest
in
actually
updating
that
code
if
it's
old
and
fine
and
doesn't
need
to
be
messed
with
so
to
make
this,
you
know
kind
of
a
more
pragmatic
conversation.
I
wanted
to
highlight
four
specifications
that
that
make
this
commerce
the
necessity
for
this
conversation,
far
more
obvious.
E
Okay,
so
the
first
one
is
Java.
X
Enterprise
deploy
it's
a
package.
It
was
created
in
2000.
It
was
proposed
in
2000
and
released
in
2002,
and
it
never
moved
beyond
one
point:
oh
okay,
it
was
it's
point,
was
to
try
and
create
a
standard
way
to
deploy
into
a
Java
EE
platform
and
it
never
really
took
off
beyond
its
usage
in
the
TCK
itself.
E
E
Now
you
know
that's
an
important
aspect
of
the
conversation.
If
we
were
to
do
an
actual
enterprise
deploy
API,
we
would
want
support
from
cloud
vendors.
We
would
want
to
do
it
fresh
and
and
if
we
move
this
legacy,
API
into
jacquard
Enterprise
deploy
what
package
would
be
used
for
the
newer
API
and
how
would
we
explain
the
difference
to
people?
Well,
the
Jakarta
Enterprise
deploys
all
legacy,
but
the
jacquard
Enterprise,
even
better
package
is,
is
the
one
you
should
be
using.
How
do
we
tell
people
this?
E
Another
aspect
of
it
is
Java
acts
management
j2ee.
This
is
jsr
77
proposed
in
2000
and
released
in
2003
not
updated
for
13
years,
not
even
a
maintenance
revision
in
13
years
it
was
a
JMX
based
way
to
get
stats
from.
You
know
a
Java
EE
implementation,
and
you
know
a
modern
perspective
on
this-
would
use
a
REST
API
and
it
would
look
a
lot
like
micro
profile
metrics,
for
example.
You
know
is
this
something
that
we
need
to
be
migrating
from
Jakarta
to
from
job
X
to
Jakarta?
E
It
largely
reflects
the
industry's
first
attempt
at
soap
services
and
was
immediately
deprecated
by
jax-ws
in
2005
and
since
his
base.
You
know
that
was
13
years
ago
and
jax-ws
has
been
the
dominant
way
to
do
soap
for
Java
EE
in
the
last.
You
know,
13
years,
if
you're
using
soap
in
you
know
in
Java
EE
it
is
probably
jax-ws.
If
you
have
any
old,
Jax
RPC
api's,
why
would
we
want
what's
the
justification
for
us
making
you
change
that
code
right?
E
E
You
know
you're
not
going
to
be
writing
more
applications
in
that
you're
gonna
be
using
jax-ws.
If
you
are
using
soap,
so
do
we
need
to
migrate
this
API
or
do
we
leave
it
calmly,
fine
frozen
the
way?
It
is
another,
and
the
fourth
and
last
API
that
I'm
going
to
talk
about
is
Java
XML
registry.
This
is
jsr
93,
it's
also
another
very,
very
old
API.
E
E
Its
goal
was
to
try
and
create
an
API
that
would
allow
tools
and
us
all
to
create
an
ecosystem
around
uddi
and
things
like
that,
which
is
basically
a
way
to
register
soap
services
in
a
central
location.
So
they
can
be
discovered
and
looked
up
that
industry
never
really
formed
and
argue
that
if
there
is
any
implementation
of
a
tool
out
there
that
leverages
this
API,
it
is
17
years
old
and
would
likely
be
broken
and
forever
lost.
E
And
so
you
know
if
we
do
think
that
this
thing
has
any
value
our
best
thing,
for
it
is
probably
to
leave
it
where
it
is,
and
so
you
know
that
is
a
is
a
very
critical
data
point.
We
can't
just
simply
go
everything's
got
to
be
changed,
so
I
think
the
the
summary
of
this
is
that
big
bank
versus
incremental
is
not
the
most
important
part
of
the
discussion.
E
It
is
an
important
part
of
the
discussion
and
the
kind
of
sort
of
Big
Bang
is
we're
not
going
to
keep
moving
things
over
and
over
and
over
again
for
the
next
20
years.
We're
gonna
make
a
decision
now
and
we're
going
to
stick
to
it,
but
that
decision
doesn't
necessarily
mean
we
have
to
or
should
move
everything
we
do
have
legacy.
We
need
to
talk
about,
so
we
need
to
audit
each
specs
relevance
and
figure
out.
Is
this
something
that
needs
to
be
expanded
and
improved,
in
which
case
it
should
move
into
Jakarta?
E
Or
is
it
fine
as
it
is,
and
maybe
we
just
leave
it
in
Java
X
and
it
can
still
be
part
of
the
platform,
but
we
do
not
intend
to
migrate
to
update
this
thing
ever
also.
You
know
people
say
Java
EE
is
is
large
and
too
big.
If
we
don't
want
them,
saying
that
about
Jakarta
EE
now
is
the
time
to
address
our
size.
Are
there
some
things
that
we
have
control
over?
There
are
specifications
under
jacquard.
You
eat
that.
E
E
Do
we
want
to
occupy
the
Jakarta
namespace
with
a
bunch
of
things
we
think
are
legacy
and
are
not
going
anywhere
or
do
we
want
to
leave
the
Jakarta
namespace
for
the
things
which
are
definitely
relevant
even
a
little
relevant,
and
you
know
new
things,
but
certain
things
that
are
very
very
legacy
and
old?
Maybe
they
just
stay
there
in
the
Java,
X
namespace
and
not
move
forward.
So
that's
the
summary
of
it,
so
you
know
I.
That's
all
I
have
prepared
for
this.
E
B
E
E
Because
it's
not
used
anywhere
and
Jack's
are
the
last
one
we
showed
Jax.
Rpc
is
already
deprecated
and
that's
kind
of
a
good
point
to
note.
Is
that
because
it's
already
deprecated,
why
would
we
move
it
to
Jakarta
and
then
that
leaves
the
Java
X
Enterprise
deploy
package
and
deprecating?
That
is,
has
always
been
impossible
because
the
TC
cave
uses
it
to
do
all
the
deploys,
and
so
we,
you
know
we
could
say
it's
deprecated,
but
in
fact
we
would
all
still
have
to
support
it
until
it's
replaced.
E
B
C
E
Think
you
know:
there's
34
specifications,
there's
34
packages,
Java
packages
and
you
know
I-
think
what
we
need
to
do
is
kind
of
divide
and
conquer,
get
people
to
write
up.
We
need
to
do
an
analysis
of
how
long
it's
been
since
these
some
of
these
have
changed.
I,
particularly
I
would
like
to
do
a
binary
level
analysis
because
in
the
JCP
process,
a
lot
of
these
things
have
received
maintenance
updates
to
change
text
in
the
specification
and
things
like
that.
But
at
a
binary
level
the
API
has
stopped
moving
at
a
certain
date.
E
What
is
that
date?
And
so
you
know
getting
some
help
analyzing.
When
was
the
last
time
we
saw
the
method
signatures
of
this
ape.
I
change.
That's
that's
an
important
thing
to
know.
So
what
one
of
the
things
that
could
be
done
is
to
take
these
34
packages
that
are
on
or
our
control,
and
you
know,
do
it
like
a
binary
diff.
E
E
You
know
moved
in
the
to
the
Jakarta
namespace,
so
you
know
that
would
be
something
that
if
people
are,
if
someone
is
willing
to
help,
do
a
binary
diff,
let's
coordinate
on
the
Jakarta
e-platform
list
and
figure
out
how
to
get
that
done.
We're
collecting
a
lot
of
data
there
in
the
Jakara
de
platforms
best.
You
know
a
project
on
the
namespace
transition,
there's
a
dependency
tree.
That's
there.
People
have
contributed
graphs
based
upon
that
dependency
information.
So
I
think
this
is.
E
C
E
Right
so
big
bank
versus
incremental
Big
Bang,
you
know
if
we
all
decided
tomorrow,
we're
gonna
do
Big
Bang.
If
you
look
at
the
description
of
Big
Bang,
it
says
okay.
Now
the
follow-on
discussion
is
what
do
we
want
to
migrate
and
what
we
want
to
leave
there
in
Java,
X
and
and
then
obviously,
with
incremental
we're
having
the
same
conversation
but
we're
having
a
conversation
from
where
one
a
change
as
little
as
possible
from
Java
to
Jakarta
and
BIGBANG,
is
sort
of.
C
B
So
we
are
working
on
preparing
to
conferences,
so
it's
a
Jakarta
one
livestream
I
hope
you've
heard
about
that
one
in
in
last
couple
of
months
and
also
Eclipse
con
Europe
2019,
so
a
little
bit
about
Jakarta
one
livestream.
So
it
is
going
to
be
a
virtual
one-day
conference
that
is
dedicated
to
clouds
native
topics
and
in
particular,
Jakarta
ie,
Java,
EE
micro
profile.
B
The
date
is
the
September
10th,
2019
and
I
will
show
you.
The
website
were
continuously
working
on
this.
Is
it
sits
right
now
open
for
registration?
We
basically
want
to
get
a
sense
of
draw
people's
attention
and
get
a
sense
of
how
many
people
we
will
have
diving
in
on
that
day,
we
already
had
call
for
papers
and
it
was
closed
on
the
15th.
So
this
Monday
we
got
around
a
little
bit
less
than
50
talks,
and
the
program
committee
is
now
reviewing
those
talks.
B
What
we
plan
to
have
is
is
combination
of
keynote
talks,
demos,
discussions
and
we're
working
on
figuring
out
the
schedule
and
as
soon
as
we
have
that
we
will
publish
it
on
the
website
as
well.
Of
course,
we
will
be
tweeting
and
and
asking
for
your
help
to
spread
the
word,
and
hopefully
we
will
make
this
event
a
success.
So
there
is.
That
is
pretty
much
at
this
point
everything
I
have
to
share
with
regards
to
Jakarta
Yee,
sorry
Jakarta,
one
live
stream
and
yeah.
B
It
is
scheduled
for
October
21st
to
the
24th,
and
it
is
in
Germany
ludwigsburg
we
are
going
to
have
the
I
will
go
to
the
website
again
and
show
you
so
here.
Here's
the
website-
and
here
are
the
details-
were
that
you
can
find.
We
are
also
now
have
a
call
for
papers
closed.
So
far,
this
was
the
largest
number
of
talks.
B
B
So
the
invite
is
really
for
you
to
register
and
figure
out
the
accommodations,
because
you
know
through
the
in
last
few
years
we
were
realizing.
It
sells
out
pretty
quickly,
so
please
jump
on
and
and
register.
I
would
also
want
to
point
out
that
we're
working
on
community
related
events,
so
we
are
going
to
work
and
start
working
very
shortly
on
Jakarta
or
I
should
say:
I
should
call
it
cloud
native
related
community
day
and
a
community
evening.
B
I
believe
we
already
know
the
date
for
the
day,
for
both
so
community
day
is
going
to
be
Monday
and
then
community
evening
is
planned
for
Tuesday.
So
we
already
had
some
exchanges
on
Jakarta
emailing
community
mailing
lists
and
people
are
eager
and
interested
very
shortly.
We
are
going
to
start
organizing
those
and
this
these
community
events
will
be
community
driven
and
community
organized.
Of
course,
Eclipse
Foundation
will
take
part
in
it,
but
primarily
this
is
community
days
or
events
organized
for
the
community.
So
your
feedback
and
input
will
be
essential
here.
B
Okay,
so
if
nothing
on
the
conference's
I'm
hoping
that
we
can
take
the
rest
of
the
time
for
other
questions,
we
have
people
not
just
the
people
who
presented
but
other
people
very
much
involved
in
the
Jakarta
working
group
and
and
various
committees.
So
we're
welcoming
questions
and
discussions
on
any
of
the
topics.
B
C
B
B
B
F
You
know
what
silence
doesn't
mean
that
we're
happy,
and
once
again
this
is
Amelia
everyone.
Some
Diesel's
also
scared.
When
I
see
people
being
silent,
it
means,
or
there
are
no
brains
available
to
provide
valuable
feedback
or
were
just
so
not
care
enough
that
we're,
like
just
run
with
the
flow,
what's
going
to
be,
or
is
something
else
guys
come
on.
Let's
do
better.
G
What
so,
you
know
what
one
thing
that
I'm
concerned
about
might
come
later
with
jihad
or
ee9,
whether
we
do
incremental
a
big
bang
and
I,
don't
I,
don't
yeah,
we
call
scene
is
discussed
much
a
in
an
additional
wave.
I
guess
is
you
know
when,
when
we
switch
over
to
the
new
Yuji
Kaido
namespace-
and
there
are
maybe
third
party.
G
Artifacts
and
or
applications
out
there
that
are
sort
of
looking
at
the
transition
from
Java
X
to
jihad
or
name
space,
and
maybe
some
of
these
are
I,
don't
know
some
of
the
yeah
some
things
that
we
all
use
it
just
yeah
this
going
to
be.
Some
of
the
friction
will
be
some
of
these
projects.
Let's
just
say:
I,
don't
know
eclipse,
link
or
hibernate
or
other
other
ones.
G
You
know
we'll
have
some
difficulty
because
it's
sort
of
like
a
fork
for
them
and
they
want
to
continue
with
the
Jacana
ee8
namespace
and
also
move
into
you
know
incrementally
forward
either
big,
bang
or
incremental
with
this
other
port.
But
it's
it
it
it's
gone.
You
know
it
could
could
be
like
an
additional
wave
of.
G
You
know
that
impacts
things
out
of
the
control
of
what
we've
been
talking
about.
So
I,
don't
you
know
it's
a
concern.
I,
don't
think
we
need
an
action
plan
per
se,
but
if
there
is
one
way
that
helps
that
more
than
the
other
I'm,
not
sure
I
mean
incremental,
has
less
impact.
I
guess.
But
but
from
the
point
of
view
of
these
third-party
jars,
you
know
I
I,
don't
really
know
what
you
which
is
better
and
if
others
have
opinions
on
that
I'd
be
interested.
E
Yeah
I
know
that
I
was
trying
to
give
a
little
space
for
other
people
to
chime
in
before
I
came
bubbling
in
I
know,
I,
know
that,
like
there's
going
to
you're
right
there's
going
to
be
impact
on
communities
around
the
Jakari
community,
there's
gonna
be
impact
in
the
spring
community.
It's
going
to
be
impacted,
drop
wizard
and
basically
anybody
who
uses
these
types
of
api's
in
their.
E
E
You
know
it
is
an
aspect
of
all
of
the
puzzle
and
I
would
really
like
to
hear
from
those
people
in
this
discussion.
I
have
a
little
bit
of
nervous
energy
that
we're
only
hearing
from
the
jacquard
ee
people
like
the
true
jacquard
ET
people,
and
we
need
to
be
hearing
from
me
like
the
whole
industry.
So
I
would
like
to
hear
more
voices
in
the
discussion
that
we're
having
around
the
namespace,
because
we're
not
the
only
ones
affected.
C
E
So
I
want
to
be
clear
that
the
maybe
we
need
to
introduce
a
new
word
I
used
freeze.
So
there
is
the
opportunity
that
it
stays
in
the
platform
and
is
supported
it's
just
simply
still
in
the
Java
X
namespace.
So
we
do
have
the
option
to
take
specifications,
leave
them
in
the
full
profile.
They're.
Just
not
gonna,
be
migrated
from
Java
X
to
Jakarta.
E
C
C
Also
means,
then,
if
you're
talking
about
profiles
again
in
the
full
profile,
if
there's
not
any
specifications,
because
you
alt
always
drag
them
out
to
drag
them
along
right.
So
if
they
stay
in
the
full
profile
that,
for
example,
all
the
application
servers
that
are
going
to
migrate
with
if
evolution
of
the
platform
have
to
drag
these
along
is
that
I?
Don't
know
if
that's
going
to
be
a
problem,
I,
don't
think
the
discussion
about
Java,
EE
or
Jakarta
is
pick
or
not,
because
Spring
Framework
is
also
big.
C
E
So
the
concept
of
actually
deprecating
thing
is
somewhat
orthogonal
to
the
do.
We
move
it
or
not,
but
but
just
to
address
how
we've
handled
deprecation
in
the
past
is
typically.
It's
me.
You
know
it's
made
optional
and
the
platforms
that
you
know
have
customers
using
that
old
api
will
typically
still
support
it
and
others
don't
will
often
drop
it,
and
so
you
know,
Jax,
RPC
and
CMP
are
two
examples
made
optional
in
the
last
version
of
Java
and
I.
E
Think
yes,
I'm
typing
going
on
there
so
for
feet.
Maybe
everybody
could
mute,
but
anyway,
so
CMP
injects.
Rpc
were
made
optional,
for
example,
on
the
opening
GB
side
of
the
fence
and
Apache.
We
still
support
CMT
because
we
grow
our
C
implementation
on
top
of
JP
because
there
isn't
really
any
legacy
there
for
us
to
get
rid
of.
E
B
Thank
you,
so
is
what
we're
approaching
we'll
probably
can
squeeze
another
question,
but
as
we're
approaching
the
top
of
the
hour
just
once,
you
invite
people
to
use
the
document
that
the
media
started
and
leave
suggestions
in
that
document.
How
we
can
improve
this
meeting.
You
can
also
leave
questions
that
you
would
like
to
be
answered,
but
we
would
appreciate
if-
and
maybe
that
will
be
easier
way
to
collect
feedback
meeting
to
invite
people
to
to
actually
let
us
know
how
we
can
in
the
course
I
will.
E
E
I
know,
there's
are
a
lot
of
ideas
on
what
could
happen,
but
I
think
everyone's
so
focused
right
now
in
Jakarta
ee8
getting
that
out
the
door
that
it's
a
little
bit
difficult
to
to
think
about.
You
know
we
were
thinking
about
ee9
like
a
month
and
a
half
ago,
but
like
this
week
and
next
we
have
to
get
all
34
specifications
up
for
vote
and
make
all
the
all
the
namespace
all
the
branding
changes
that
are
required,
and
so
everyone's
basically
heads
down
but
I
think
maybe
next
month
or
the
month
after
that.