►
From YouTube: Jakarta EE 9 Release Plan | 2019-12-11
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
I'm
gonna
get
an
update
of
Ducati
9,
where
we
are
in
our
planning
so
I'm.
Obviously,
the
founder
of
parara
I'm,
also
one
of
the
project
leads
on
the
car
tree
platform
and
for
the
Jakarta
ee9
release
I'm
what
we're
calling
a
co-pilot
with
with
Kevin
Sutter
from
IBM,
so
we're
currently
in
the
phase
of
putting
together
and
the
plan
that
will
go
in
for
review
to
work.
A
The
steering
committee
in
the
specification
committee
just
to
go
through
a
bit
of
the
process,
so
I
did
a
similar
update
a
month
ago,
when
this
is
really
going
to
come.
Follow
on
from
that
it
has
some
more
decisions
to
be
made
since
then,
just
to
recap
a
little
bit
of
where
we
are
so
Carter
e8
was
out
in
September,
and
that
was
the
compact
bility
release.
A
So
that
covers
that
was
based
in
the
Java
X
namespace
and
big
thing
is
that
we
we
have
open
specifications
that
are
managed
through
the
Eclipse
Foundation
specification
process
and
we
have
an
open
source,
TCK
and
an
open
source
development
process,
and
so
that,
but
that
completed
the
evolution
of
specifications.
The
API
is
from
from
the
JCP
and
now
we're
in
the
phase
of
creating
too
cartoony
9
so
which
car
tree
9
we're
sort
of
targeting
this.
Is
it
as
a
tooling
release
and
a
little
bit
about
what
we
mean
by
that.
A
But
it's
gonna
be
a
limited
scope
in
that.
What
we're
going
to
do
is
change
the
namespace
to
the
Jakarta
namespace
and
we're
gonna
deprecated
and
remove
some
api's
and
we've
got
some
slides
on
which
api's
are
remaining,
which
ones
are
you
deprecating
and
which
ones
we're
adding
and
also
we're
gonna
update
the
base
JDK
and
in
parallel
to
a
large
extent,
to
that.
A
So
the
reason
we
stopped
saying
it's
a
tooling
releases
that
we're
not
adding
any
specifications
other
than
some
have
been
pruned
from
Jakarta.
Sorry
from
java
SE
8
we're
not
really
looking
to
make
any
breaking
changes,
so
not
introducing
any
new
api's,
no
breaking
changes
other
than
the
namespace.
Obviously,
and
maybe
some
upward
compatible
changes,
whether
small
but
predominately,
is
the
move
from
dev
X
to
Jakarta
that
we'll
be
completing
in
API
package
names.
So
what
we
wanted
to
do
is
create
a
base
for
people
to
sort
of
target
when
dealing
with
their
names.
A
Similarly,
it
gives
us
an
opportunity,
for
you
know:
vendors,
like
payara,
to
explore
how
we
sort
of
also
help
end
users
and
developers
move
this
names,
so
we
could
cross
the
namespaces
and
make
their
transition
as
smooth
as
possible.
So
we
can
look
at
explore
and
explore
compatibility
layers.
We
can
collaborate
with
with
other
vendors
on
how
we
can
build
compatibility
layers
to
support
old
applications
running
on
car
tree
line
and
then
finally
also
end
users
and
developers
out
there.
A
A
So
if
you,
if
you've
been
on
the
previous
call
there,
we
were
still
in
there
in
a
flux
and
what
is
the
scope
which
Carter
ee9,
which
API
czar
in
which
API
czar
out
and
there's
been
a
lot
of
chatter
on
the
platform
mailing
lists
and
based
on
the
call
this
Tuesday
we're
in
a
position
where
we
believe
that
this
is
all
agreed.
It's
still
going
to
be
put
into
the
release
plan
and
still
going
to
be
signed
off,
but
most
of
the
discussions
have
now
been
settled.
A
So
what
we're
going
to
do
is
prune
a
number
of
legacy.
Api's
and
they'll.
Be
removed
completely
from
takara
tree
9,
we
know
to
add
in
some
AP
guys
might
used
to
be
in
Java
SE
eight,
but
are
no
longer
there,
so
they
were
pruned
from
from
SE
and
we're
going
to
add
those
in
as
optional
api's
in
to
Tecate,
nine
and
again
I
got
more
slides
on
this.
A
A
If
we'd
left
the
baseline
at
SC
8,
then
obviously
they
would
exist
in
there
in
Java
SE
and
in
Jakarta
EE,
which
could
be
confusing
so
we're
taking
opportunity
by
bringing
these
in
to
also
operate
the
minimum
for
compatibility.
Saying
that,
though,
we're
going
to
require
that
API
jars
are
released,
so
they're
suitable
for
use
with
JDK
individually.
So
what
that
means
is
that
they
will
be
compiled
using
Java
SE,
a
class
file
format,
so
we're
not
going
to
compile
them
into
Java
SE
11
tasks,
file
format.
A
As
we
know,
the
API
jars
are
often
used
widely
outside
then
in
the
general
ecosystem,
and
there's
no
need
given
we're
not
allowing
any
API
changes
of
any
significance
to
not
do
this,
because
no
one
is
going
to
be
pushing
to
put
SU
leavening.
Only
API
is
into
the
API
signatures,
so
move
on
to
actually
in
details
of
each
specification.
A
A
You
decided
not
to
prune
it
because
it's
quite
complex
from
and
they
would
have
delayed
the
project
due
to
the
mix
and
match
of
namespaces
and
exception
hierarchies
and
things
between
the
current
age
Fe
and
the
older
eg
B.
So
you
doing
that
on
picking
work
was
decided
to
was
too
complicated
and
we're
also
pruning
the
old
enterprise
web
services,
which
is
a
web
service
that
predates
the
XML
web
services,
objects
WS,
as
was,
and.
A
So,
even
though,
to
get
compatibility,
something
there,
payara
doesn't
need
to
implement
these
api's.
When
we
actually
release
the
specification,
then
the
implementation
that
goes
along
with
a
specification
release
has
to
support
all
these.
So
there's
a
burden
on
the
specification
team
and
the
compatible
implementation
to
support
optional
api's.
But
at
the
same
time
you
still
meet
our
goals,
which
is
to
sort
reduce
the
footprint
of
de
Carter
e8
storage
carter,
e9
for
new
vendors.
So
new
vendors
wouldn't
need
to
support
any
of
these
optional
api's.
A
Most
of
them
will
be
optional,
so
you
Jakarta
activation
will
be
added
into
country
9
that
supports
Java
male
and
that
so
that
probably
Monday
tree
and
then
Java
Jack's
B,
as
well
as
Jakarta,
xml,
binding
or
jax-ws,
as
well
as
which
is
Jakarta
Rex
my
web
services
and
there
are
other
associated
web
services.
Api
is
and
specifications
well
now
all
be
added
into
T.
Carter
e9
has
optional
api's
and
in
addition
to
that,
we're
going
to
move
all
these
five
api's
into
Jakarta
namespace.
That
was
really
driven
by
community
feedback.
A
So
there
was
a
lot
of
community
feedback
that
these
api's
are
still
in
a
lot
of
use
and
they
wanted
to
see
them
move
into
the
Carter
namespace
again
from
a
specification
point
of
view.
It
was,
it
was
a
burden
to
support
these
and
move
them.
However,
because
of
the
community
feedback,
we
decided
to
take
that
work
on,
and
you
know
bring
them
in
to
Jakarta
3:9
to
find
a
solid
base
as
to
where
you
know
where
these
api's
have
gone
and
that
they
will
be
available
to
applications
in
runtimes
that
support
them
again.
A
So
so
that
covers,
you
know
what
we're
adding
removing
what's
in
and
what's
out
v9.
So
just
and
then
a
you
know,
as
we
said,
will
be
based
on
Java,
SE
11
for
implementations
and
then
so,
if
you're
moving
to
the
planning.
So
we
haven't
got
full
dates
for
this.
But
what
we'll
be
doing
is
from
a
project
plan
perspective.
We
we're
moving
forward
in
seven
waves.
A
So
essentially
this
is
a
rough
view
of
what
depends
on
what
so
from
the
first
wave
will
be
the
lowest
level
api's
that
have
the
minimal
dependencies.
So
that
includes
Jakarta
concurrency,
annotations
messaging,
as
with
JMS
and
then
wave
2
again
brings
in
some
other
API.
Is
that,
may
you
know
depend
on
wave
1,
then
we
bring
in
the
big
one,
which
is
Jakarta,
Kahn
context
and
dependency
injections,
wait
three
and
then
you
know,
following
on
for
that
further
and
further
higher
and
higher
API,
so
dependent
on
the
most
lower-level
api's.
A
A
You
know
that
there's
a
fixed
quantum
work
that
needs
to
be
done,
so
we
have
to
pick
a
date
when
that
work
can
be
finished
when
we
move
into
maybe
10
11
and
beyond,
and
we
can
follow
a
more
release.
Train
mode
whereby
we'd
be
able
to
you
know,
pick
a
date
for
the
release
and
then
just
pick
up
the
api's
that
are
ready
that
date
and
release
a
platform
that
way.
But
for
a
bit
we
have
to
do
all
this
namespace
change,
so
the
quantum
work
is
fairly
fixed.
A
So
when
it
comes
to
API
jars,
we're
going
to
try
and
get
those
out
earlier
than
suggested
from
from
the
wave
diagram.
So
essentially
when
I
say:
artifact
I'm
talking
about
jar
files
really
from
those
people,
so
we're
going
to
release
our
seesaw
released.
Api
jars,
as
soon
as
possible
into
Maidan
central.
A
You
know,
without
going
through
the
full
spec
process
and
and
everything
so
that
centered
essentially
they'll
be
available
for
later
waves
and
to
willing
and
GlassFish
clips
Russ
efficient,
which
I'm
a
project
lead
of,
can
use
those
jars
early
as
early
as
possible,
and
that
will
speed
up
the
delivery.
So
we
won't,
you
know
we
won't
have
to
release.
A
A
Individual
specs,
because
obviously
I'm
just
on
the
platform
project,
which
is
an
umbrella.
Each
of
those
can
release
a
final
specification
at
any
time
subject
to
them.
Following
the
Eclipse
specification
process,
another
step
would
be
aiming
to
do
is
once
all
the
API
jars
have
been
released
and
we're
intending
to
do
like
a
release
candidate
of
the
full
platform.
So
that
will
include
the
API
jars,
a
compatible
implementation
and
the
TCK,
but
it
won't
have
gone
through
the
full.
You
know
spec
process.
A
All
the
documents
necessarily
want
me
ready
now,
I'll
give
an
opportunity
for
us
to
look
at
to
willing
and
and
make
sure
that
everything
is
working
before
we
then
have
a
sort
of
a
window
which
maybe
a
couple
of
months.
Where
we'll
then
do
the
final
release
and
put
the
you
know
final
artifacts
up
into
maven
central
and
they
all
the
specification
documents
etc
and
go
through
the
formal
votes,
an
IP
flow,
etc.
A
So
again,
these
dates
are
gonna,
get
a
bit
more
nailed
down
in
the
next
week
and
we
have
to
give
any
new
projected
date
by
next
Tuesday
I
believe
before
Christmas
and
we'll
put
that
into
a
release
plan
so
that
that's
where
we
are,
we
have
the
scope
nailed
down.
We
have
a
tentative
Porter
that
we're
going
to
release
things
on
and
we
have
a
plan
in
the
sense
we
have
the
order
of
things
that
we're
going
to
happen.
The
only
thing
where's
now
missing
is
the
date.
A
Anybody
can
contribute.
There's
a
lot
of
this
conversations
on
the
platform,
their
mailing
list
on
the
community
list
we
to
get
to
a
date.
I'll
just
show
that
we
are
putting
together
and
tracking
on
a
spreadsheet
of
when
api's
can
move
to
the
namespace
and
what
you'll
see
is
actually
most
of
the
way
one
api's
PRS
are
already
done,
and
some
of
them
are
already
merged,
actually
doing
the
API
change
itself.
Isn't
it's
not
a
big
deal?
A
Getting
the
implementations
in
the
TCK
will
be
a
bigger
deal,
but
we've
already
making
progress
on
this
and
I
say
many.
The
Piazza
provide
for
an
already
done
once
we
can
get
those
into
maven
central
as
released
candidate,
then
the
API
changes
can
be
done
on
wave
2
and
then
some
of
the
TCK
work
and
then
follow
on.
Basically,
we
just
need
artifacts
for
these.
A
A
You
can
raise
issues
and,
like
I,
said
that
they're,
probably
at
the
beginning,
is
Jakarta.
E10
itself
can
also
start
progressing
and,
with
you
know,
I'm
Project
Lead
for
concurrency
and
we're
already
creating
issues
for
that
in
a
separate
branches,
and
that
can
work
in
parallel
to
the
API
work.
So
a
lot
of
the
the
namespace
work
is
just
some
boilerplate
type
work,
so
the
innovative
work
and
having
them
in
parallel
so
just
want
to
stress
that
as
well.