►
Description
Speaker: Kevin Sutter
We have finally made some real progress with Jakarta EE in 2019! Specifications, APIs, TCKs, Maven artifacts, Implementations, Releases, and, yes, even a little bit of required process. If you want to get caught up quickly on all of the activities, this session is for you. We will discuss the potential impact to both implementors as well as application developers as we move away from the JCP-defined javax world to the open-source world of Jakarta EE.
///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/jakartatechtalks_/events/
Join us on LinkedIn: https://www.linkedin.com/groups/13597...
Tag us: #JakartaEE #JakartaOneLivestream
A
Hello,
everyone-
this
is
my
name-
is
Tanya
broodwich
and
I'm
working
for
Eclipse
Foundation
as
Jakarta
a
program
manager.
Of
course
we're
all
here
beyond
excited
to
be
here
with
you
and
to
share
the
news
about
Jakarta
ie8
today
is
a
big
day
and
we
have
a
big
Jakarta,
1y
string
conference
and
we're
starting
off
with
our
MC
Adam
being
and
our
first
presentation
of
the
day,
which
is
with
Kevin
Sutter,
so
I
will
hand
it
over
to
Adam,
and
he
will
take
it
from
here.
Yeah.
B
Hello,
my
name
is
what
I
mean
and
I'm
working
for
Adam,
Dean
and
I
really
enjoy
I
hope
I
would
enjoy
the
next
15
hours
and
our
first
presenter
is
Kevin,
SATA
and
old,
same
old
but
well-known
Java,
EE
and
J
to
befriend.
You
did
I
think
Kevin.
You
did
a
lots
of
JP
Hebert
back
then,
and
now
yeah
and
now
you
are
focused
on
the
lightweight
stuff,
like
micro
profile,
jakarta
ii,
open
liberty
and
auto
texting
stuff
right,
correct.
C
A
C
C
This
is
this
is
a
big
day
for
us
you're,
going
to
hear
a
lot
of
different
presentations
today,
related
to
our,
of
course,
our
new
release
and
then
the
individual
technologies
that
Phil
that
are
part
of
Jakarta
ee,
so
I'm
going
to
be
starting
to
kind
of
get
everybody
up
to
speed.
So
this
is
a
good
introductory
course
to
give
a
little
bit
of
background
on
Jakarta
EE
I
do
have
to
point
out.
I've
been
you
know,
kind
of
practicing
this
pitch
with
with
various
people.
C
This
is
not
a
real
book,
I
kind
of
threw
this
together
as
just
kind
of
an
example.
You
know
to
show
that
it's
kind
of
one
of
those
you
know
for
dummies.
You
know
type
of
presentation
and
people
thought
that
this
book
looked
a
little
too
real
and
you
can't
find
it
on
Amazon.
So
don't
don't
go
looking
for
it.
This
was
just
a
you
know,
little
thing
that
I
threw
together
because
I
thought
it
was
kind
of
cute,
so
just
to
be
aware
so
I'm
going
to
do
a
very
brief
history.
C
Many
people
on
this
call
are
probably
already
aware
of
Jakarta
EE
and
where
it
came
from,
but
I
got
to
get
everybody
kind
of
on
the
same
page.
So
I'm
do
a
brief
history.
I'm.
The
majority
of
my
talk
is
going
to
be
talking
about
the
specifications
the
API
is
and
the
tcks
that
we
have
been
generating
over
the
last
several
months
in
order
to
release
Jakarta
ee8.
C
So,
first
of
all
a
little
bit
of
history,
this
chart
here
we
we
when
I
say
we
I'm
from
IBM
we've
been
using
this
chart
here
since
Java
1
of
2015,
one
of
our
guys
here
at
IBM.
He
he
had
a
lo
keynote
and
he
started
off
his
presentation
with
this
chart
and
he
he
was
asking
at
that
time.
Java
EE,
Enterprise
Java.
Is
it
relevant
or
is
it
an
elephant?
You
know
what
what's?
C
Where
are
we
going
with
Java
EE
I
mean
my
career
services
was
just
starting
about
that
time,
and
so
does
Java
EE
still
come
into
play
at
that
time.
So
this
was
2015.
When
we
were
first
presenting
this,
we,
the
industry,
Oracle
everybody.
The
warning
signs
were
kind
of
ignored.
With
Java
EE
after
Java
EE
8
came
out,
there
was
a
lull.
There
was
very
little
activity,
whether
it
was
from
Oracle
or
the
other
companies.
We
really
didn't
have
a
direction
beyond
Java
EE
8.
C
There
was
talk
sometimes,
and
sometimes
the
talk
would
get
started
and
then
it
would
die
off
and
we'd
see
some
activity
happening
on
Jay
SRS
and
then
it
would
die
off
and
there'd
be
some
definition
of
Java
EE
9
and
then
it
would
die
off
and
we're
just
kind
of
like
ok.
What
what
are
we
going
to
do?
We've
got
we
now
the
industry.
We
have
a
large
set
of
customers
that
are
dependent
on
enterprise
Java.
So
what
are
we
going
to
be
doing
to
go
forward.
C
So
in
2016,
just
to
give
a
little
bit
of
history
here,
some
of
us
industry
leaders
we
got
together
inside
ok,
Java
EE,
we
don't
know,
what's
happening
with
that.
It's
there.
We
have
Java
EE
8,
but
what's
really
going
to
be
happening
with
it,
and
so
we
started
to
look
at
micro
services.
What
can
we
do
from
like
your
services
in
the
enterprise
Java
environment?
And
we
came
up
with
this
idea
of
micro
profile,
so
we
established
a
community
at
Eclipse
and
we
brought
in
a
lot
of
different
participants.
C
Both
you
know,
industry
players
as
well
as
individuals,
and
we
started
this
micro
profile
initiative.
It
has
taken
off
extremely
well
I
mean
since
2016,
so
basically
that
was
Java
1
2016,
you
know
2019.
In
three
years
time
we
have
produced
nine
platform
releases
and
like
21
or
22
component
releases,
so
we've
been
very
active
in
this
environment
for
coming
up
with
these
components.
These
features
that
help
people
with
developing
micro
services
in
an
enterprise,
Java,
environment,
I.
C
Mentioned
that
we've
had
a
lot
of
participants
with
micah
profile
and
we
we
have
several
compatible
implementations,
I'm
personally
involved
with
Open
Liberty
in
websphere
liberty,
but
we
also
high
up
implementations
from
Red
Hat
payara
Apache,
even
Oracle,
with
a
Heligan
I.
Oh
that's
an
Oracle
implementation
and
Oracle
open
source
project.
That
is
utilizing
some
of
the
capabilities
of
micro
profile.
C
So
we
have
a
lot
of
industry
that
was
interested
in
what
we
were
doing
with
like
a
profile,
and
this
turned
out
to
be
kind
of
interesting,
because
what
happened
here,
Micro
profile
was
getting
so
much
attention
that
we
kind
of
claimed
that
this
kind
of
woke
up
Oracle
and
it
says
we'll
wait
a
minute.
We
still
have
this
Java
EE
thing
and,
like
your
profile,
is
really
kind
of
taking
off
and
look
at
what
they're
doing
in
the
open-source
environment.
C
So
maybe
we
should
be
contributing
Java
EE
to
the
open
source
environment
and
that's
what
started
car
EE.
So,
yes,
it
was
two
years
ago
2017.
But
you
know
it
sounds
like
a
long
time,
but
as
you'll
see,
there's
been
a
lot
of
work
that
has
been
put
into
place
in
order
to
finally
release
card
at
the
g8.
C
Now
you'll
notice
that
at
the
Eclipse
Foundation
we
have
the
two
leading
programming
models
for
developing
cloud
native
Java.
We've
got
the
micro
profile
initiative,
and
now
we
have
Jakarta
EE
and
they
are
very
much
related
I'm
going
to
touch
on
this
a
little
bit
later.
You
know,
there's
some
synergy
between
the
two
that
we're
gonna,
you
know
be
capitalizing
on,
and
there
are
some
things
that
we
still
have
to
work
on,
but
having
them
both
at
Eclipse
is
fantastic
news
and
it's
you
know
going
to
be
good
for
the
industry.
C
One
thing
I
want
to
point
out,
even
though
Java
EE,
as
a
source
code
was
contributed
to
eclipse.
Oracle
is
still
protecting
some
of
their
Java
trademarks
and
I'll
be
touching
on
that
a
little
bit
later.
That
will
affect
us
after
Jakarta,
ee8
and
I'll
touch
on
that
towards
the
end
of
the
presentation.
C
So
this
is
a
chart
that
the
Eclipse
Foundation
put
together
and
I've
used
it
a
couple
of
times
with
very
good
results,
because
what
this
shows
is,
how
did
we
do
stuff
before
with
the
JCP
and
Java
EE,
and
how
are
we
doing
it
with
Jakarta
EE,
so
you'll
notice
here
like
right
off
the
top,
although
some
of
this
has
been
changing
along
the
way,
Java
EE
was
really
specification.
First,
especially
the
early
specifications.
C
It
was,
you
know,
we'll
do
the
specification
first
and
then
try
to
write
the
code
to
see
if
we
can
implement
that
spec
which
occurred
EEE.
We
want
code
first
or
at
least
simultaneous
with
the
specification,
because
we
want
to
be
able
to
prove
that
everything
is
implementable
and
testable
right
off
the
bat.
In
the
past,
the
various
GSRs
were
led
by
a
specification
lead
and
that
lead
was
appointed.
It
was
either
you
know,
Oracle
or
one
of
the
participants
of
the
JCP
were
death.
C
They
were
designated
as
a
specification
lead
and
what
was
special
about
that
is
that
then
all
of
the
IPE
flowed
through
that
specification
lead
and
then
back
to
Oracle
in
this
case,
which
occurred
EEE.
Even
though
we
have
project
leads,
they
are
not
designated
as
specification
leads.
The
specifications
are
defined
in
a
collaborative
environment
and
we
have
identified
the
appropriate
licensing
agreement
so
that
it
is
all
collaborative
and
then
it
can
be.
The
IP
can
then
easily
be
distributed
to
the
participants
in
the
past.
The
documents
in
the
tcks
are
closed
source.
C
There
were
some
exceptions
to
those
you
know
some
of
the
items
that
were
produced
by
Red
Hat
and
IBM.
They
were
open
sourced,
but
the
actual
final
results
of
the
documents,
and
especially
the
T
CK's.
They
were
closed
now
with
Jakarta
EE.
This
is
really
special,
especially
the
TC
case,
being
open
source
having
full
access
to
the
source
code
being
able
to
look
at
the
test
cases
and
understanding
them.
C
Okay,
so
specification
process
I
just
want
to
touch
on
this
I'm
not
going
to
take
you
through
all
of
the
text.
Once
these
presentations
are
available,
you
can
follow
the
links.
If
you
want
to
read
all
of
the
boring
detail,
but
what
I
want
to
highlight
is
when
we're
going
through
the
specification
process.
There
are
certain
things
that
we
have
to
create
and
we
have
to
create
a
specification.
We
have
to
create
Javadoc
that
corresponds
to
the
API
we
have
to
court.
C
C
So
just
to
give
you
a
little
bit
of
background
on
the
the
amount
of
work-
and
you
know-
and
most
people
are
saying,
I-
don't
care
how
much
work
it
took.
You
know
what
are
you
producing
and
I'm
gonna
get
to
everything
that
we're
producing,
but
I
do
want
to
point
out
that
there
was
a
lot
of
activity
that
had
to
be
done,
because
we
wanted
checks
and
balances.
We
didn't
want
any
one
particular
person
or
any
one
particular
organization
to
be
able
to
have
control.
C
So
we
had
a
lot
of
reviewing
a
lot
of
approving
a
lot
of
meetings
going
through
this
information
to
ensure
that
we
are
creating
the
proper
specifications.
Api's
javadocs
TCK
is
compatible
implementations
and
everybody
is
reviewing
all
of
this
to
ensure
that
we
have
consistent
results.
All
the
way
across
and
I
do
want
to
point
out
the
very
bottom
bullet
a
few
process.
Adjustments
along
the
way.
This
is
what
was
really
nice
because,
as
you
know
up
front,
we
can
define
various
processes,
the
specification
process,
the
TCK
process.
C
You
know
we
discovered
along
the
way
that
Oh
May
and
we
were
a
little
too
stringent
on
that
I
mean
one
example.
Our
original
review
process
said
that
we
needed
30
days
to
allow
for
a
review
as
a
minimum
and
it's
just
kind
of
like
okay.
That's
too
long
we're
in
constant
communication
with
everybody,
I
mean
granted.
We
want
to
talk
with
other
people
within
our
respective
organizations,
but
we
don't
need
30
days
for
that.
C
Okay,
so
let's
touch
on
specifications
now,
what
is
really
cool
is
because
overnight
we
actually
completed
all
of
this
activity
got
all
of
the
you
know,
eyes
dotted
and
t's
crossed,
so
actually
I'm
going
to
be
jumping
out
here,
and
hopefully
this
all
works
yep.
So
now,
you'll
see
this
is
the
live
page
for
all
of
our
specifications.
C
So
you
can
see
as
I
scroll
down
here
all
of
the
various
specifications
that
we
have
been
working
on
for
job
jacquard,
EEE,
okay,
so
as
an
example,
I'm
gonna
just
pop
back
up
here,
so
we
can
walk
through
one
together.
If
you
pick
jacquard
EEE
platform,
it
comes
up
right
now
we
only
have
Jakarta
ee8.
As
we
develop
additional
platforms.
C
There
will
be
additional
entries
on
the
screen
for
Java
EE
9,
w
10,
whatever
so
I'm
going
to
click
on
this,
and
now
we
have
a
one-stop
shop
for
all
of
the
information
related
to
jacquard
EEE
platform.
So
if
you
want
to
look
at
the
specification
document,
you
can
click
here
and
up
comes
the
PDF,
so
here's
the
PDF
for
the
whole
specification
document
for
the
platform.
C
C
C
C
C
C
Now
one
thing
to
point
out
here:
the
compatible
implementation
listed
here
is
the
one
that
was
submitted
in
order
to
support
the
specification.
So
when
we
define
a
specification,
you
have
to
define
the
specification,
the
API,
the
TCK
and
a
compatible
implementation.
So
we
used
the
Eclipse
GlassFish
implementation
as
the
compatible
implementation
for
the
Jakarta
ee8
specification.
C
Ok,
so
because
I
didn't
know
whether
or
not
we
would
have
all
the
pay
is
up
and
running,
I
had
these
as
backup
so
I'm
just
going
to
kind
of
go
through
this,
because
I
already
talked
about
it.
Okay,
so
the
content
of
these
specifications
now
I
showed
you
the
platform
one
and
it's
very
complete
it's
very
much
like
Java
EE,
the
platform
and
web
profile
specifications
are
complete.
They
came
from
Oracle,
they
were
contributed.
We
have
massaged
them.
You
know
made
them
pretty
and
put
them
into
a
format
that
is
a
readable
and
consumable.
C
Bean
validation
and
c-d-I
are
in
the
same
boat,
they're.
Also
complete.
Now
the
thing
that
we're
a
little
light
on
is
that
all
the
rest
of
the
components
specification.
So
if
you're
talking
about
JPA
and
persistence,
JMS
messaging,
all
of
those
are
skeletal
specifications.
At
this
point.
They're
very
brief:
it's
got,
you
know
basically
a
title
in
a
scope
statement
and
then
we're
going
to
rely
on
the
Java
doc
as
the
specification
for
Jakarta
ee8
I
know.
C
We
all
agree,
it's
not
complete,
but
it
is
a
start
and
the
rest
of
the
specifications
from
Oracle
are
being
contributed
and
they're
going
through
the
final
phases
of
the
you
know:
clearance
the
copyright,
the
IP
clearances
and
eventually
they
will
become
part
of
Jakarta
ee8
and
we'll
have
a
more
complete
specification
library.
But
until
that
happens,
we're
just
going
to
rely
on
these
skeletal
specifications
and
the
Javadoc
for
most
of
the
components.
C
Ok,
api's
I,
that
on
the
other
page
at
the
bottom
of
each
of
the
specification
pages,
are
the
Maven
coordinates.
You
can
click
on
that
maven
coordinate
and
it
will
take
you
out
to
maven
and
show
you
the
results.
It'll
have
the
API
the
sources
and
the
Javadoc
files,
so
all
three
of
them
are
available
via
that
link.
C
C
If
you
just
like
to
navigate
and
go
around
and
search
and
take
a
look
around
the
other
way
of
doing
it
is
doing
a
search,
and
so,
if
you
go
up
to
me
even
central
and
do
a
search
on
Jakarta
Splatt,
this
will
come
up
with
all
of
the
group
IDs
that
start
with
Jakarta,
and
this
is
another
nice
way
of
taking
a
look.
So
if
we
go
back
out
to
the
same
location,
that
I
did
the
Jakarta
platform,
maybe
I
should
make
this
a
little
bigger
as
well.
C
C
Ok,
so
now,
let's
talk
a
little
bit
about
the
TC
case
in
the
past.
In
order
to
get
excuse
me
in
order
to
get
access
to
the
TC
case
for
Java
EE,
you
had
to
sign
a
license,
some
type
of
license
with
Oracle.
You
had
to
get
some
type
of
legal
agreement
in
place
that
would
allow
you
access
to
the
tcks
and
even
then,
even
when
he
did
get
access
to
the
TC
case,
you
had
to
be
careful
on
who
actually
got
to
look
at
the
tcks
and
work
with
them.
C
This
was
not
helpful
to
a
lot
of
organizations.
There
were
a
lot
organizations
that
were
interested
in
being
Java
EE
compatible,
but
either
they
didn't
have
the
resources
to
sign
a
licensing
agreement,
or
maybe
there
are
some
other
disagreement
that
you
know
didn't
allow
that
type
of
licensing
to
occur
or
whatever
the
reason
there
were
a
lot
of
organizations
that
were
not
able
to
get
at
these
tcks.
Okay,
so
now
look
at
Jakarta
EE.
We
have
all
of
the
tcks
now
available,
keep
losing
my
mouse.
I
have
to
keep
going
back.
C
So
let's
go
out
here.
You'll
notice
here
that
now
here
are
all
of
the
different
components
that
make
up
to
card
EEE
and
you
can
go
into
one
of
these
folders
and
there's
version.
8
and
here
are
all
of
the
tcks.
Now
you'll
notice,
multiple
names,
we
kind
of
had
a
hiccup
right
at
the
end
where
some
of
them
were
named
Eclipse
and
the
ultimate
goal
was
to
have
them
called
Jakarta
and
because
some
of
them
were
already
promoted,
we
decided
okay,
let's
just
have
them
both
out
there.
So
we're
using
this.
C
You
know
just
renaming
they're
the
exact
same
content,
whether
you
pick
Eclipse
or
Jakarta,
but
they're
both
out
there.
So
now
here's
access,
if
you
click
on
one
of
these,
you
can
get
the
complete
TCK
zip
file
and
that
zip
file
contains
everything
that
you
need
to
know.
In
order
to
run
the
TCK,
it's
got
a
user's
guide.
That's
most
of
them
have
read
Me's
if
it
needs
certain
utilities
in
order
to
execute
the
TCK
it'll
outline
all
of
the
requirements
so
that
you
can
get
set
up
and
executing
the
TCK.
C
C
Okay,
and
that
just
shows
that
ou
should
point
out
the
little
thing
at
the
yellow
at
the
bottom.
So,
even
though
you
have
access
to
all
these
tcks
and
everybody
can
get
access
to
them,
can
execute
them
and
play
with
them.
There's
still
some
separate
additional
branding
requirements
if
you
want
to
be
branded
as
being
Jakarta,
EE
compliant
they're
pretty
easy
to
get.
So
you
know,
don't
don't
think
of
this
as
a
big
hurdle.
C
Ok
compatible
implementations.
This
is
where
it
was
fun,
so
I
got
to
start
I'm
gonna
back
up
just
a
little
bit,
because
I
want
to
talk
about
micro
profile
and
jacquard
EEE.
So
if
you
remember
on
the
previous
chart,
it
had
shown
Eclipse
micro
profile
and
the
Java
EE
was
off
to
the
left
on
my
screen
and
now
that
we
have
Java
EE
moved
over
to
eclipse
under
Jakarta
EE.
That,
eventually
can
be
the
new
stack
right
now:
Java
EE
in
Jakarta
ee,
8
they're
equivalent.
C
So
if
we
say
that
Myka
profile
sits
on
top
of
Java
EE
8
the
four
technologies
at
the
bottom,
they
will
also
work
on
top
of
Jakarta
ee
8
with
those
four
technologies.
Now,
maybe
at
some
time
there
will
be
additional
Jakarta
EE
technologies
that
we
will
be
on
dependent
on
or
some
new
revision.
Maybe
CDI
comes
out
with
a
2.1
release:
that's
jakarta
ee
8
and
then
maybe
you
will
have
to
modify
market
profile
to
be
more
to
Carnegie
compliant
than
Java
EE.
But
will
you
know
we'll
look
at
that
down
the
road?
C
C
What
we
needed
to
prove
is
that
all
of
this
stuff,
from
Java
EE
8
all
of
the
specifications,
the
code,
the
API-
is
the
tcks
everything
we
can
move
over
to
Jakarta
EE
and
we
can
use
an
open
source
process
and
environment
in
order
to
create
a
new
release
of
Jakarta
ee
8.
So
the
second
bullet
there
we
even
have
some
existing
warts
and
wrinkles.
So
we
hit
a
couple
of
hiccups
with
Java
with
Jakarta
ee
8
late
in
the
cycle,
and
we
said
ok,
but
they
existed
in
Java,
EE
8
as
well.
C
So
we
had
to
kind
of
adjust
that
a
little
bit
to
figure
out
okay.
How
much
of
this
do
we
really
need
over
there?
And
you
know
I'll
say
it's
99.9%
the
same
between
Java
EE,
8
and
Jakarta,
ee
8,
and
the
reason
that
we
did.
That
was
the
third
bullet,
because
we
wanted
as
soon
as
Jakarta
ee
8
became
available.
We
wanted
it
easy
for
the
existing
Java
EE
8
app
servers
to
be
Jakarta,
ee,
8
compliant.
C
C
So
in
order
to
claim
yourself
as
being
Jakarta
ee
8,
you
need
to
do
a
certification
request
and
I'm
going
to
just
take
you
out
to
take
a
look
at
one.
This
is
the
one
that
we
filed
for
open,
Liberty
and
there's
a
certain
format
that
you
have
to
adhere
to.
You
have
to
indicate,
while
who's
the
organisation,
what
version
of
the
product
that
you
are
trying
to
certify
and
all
of
these
are
links
so
would
take
you
out
to
the
specific
implementation.
C
What
specification
is
being
tested
which
TCK
was
being
used
now.
One
thing
that
you'll
notice.
This
is
eight
point.
Zero
point
one:
this
is
one
of
those
little
hiccups
that
we
found
late
in
the
Jakarta
ee8
cycle
and
so
actually
respawn
the
TCK
for
the
platform
in
order
to
pick
up
one
one
more
fix,
so
we
actually
have
an
eight
zero
zero
version
of
the
TCK
and
we
have
an
eight
zero
one
version
of
the
TCK
and
both
of
them
are
usable
for
testing
your
compatible
implementation.
C
You
have
a
link
for
the
test.
Results
and
I'll
show
that
in
a
little
bit,
if
there's
other
additional
certification
requirements,
so
right
now,
dependency
injection,
CDI
in
bean
validation.
They
were
produced
by
Red
Hat
and
they
have
their
own
TCK
requirements,
and
so
we
have
those
you
have
to
test
those.
In
addition
to
the
overall
test
bucket
for
the
platform,
you
have
to
talk
a
little
bit
about
your
runtime.
What
are
you
using
for
the
oracle
or
for
the
java
environment?
C
If
there's
anything
special
with
the
databases
that
you're
using
on
whether
or
not
you
accept
the
licensing?
And
in
this
particular
case
we
had
a
signature
test
that
needed
a
challenge,
and
then
you
can
see
I'll
just
quickly
breeze
through
here.
You
can
see
the
discussion
that
was
happening
on
this
after
we
submitted
it.
C
So
the
end
goal
is
to
get
this
little
thing
right
here
that
says
accepted,
and
so
we
submitted
the
certification
and
after
the
review
and
people
took
a
look
at
it,
it
was
accepted
and
then
that
allows
the
certification
request
to
go
forward.
So
before
I
get
off
of
this
page.
Let
me
show
you
this,
so
one
of
the
things
that
you
have
to
do
is
provide
a
URL
for
the
TCK
results,
so
this
page
is
out
on
our
open,
Liberty
web
site.
You
can
see
here
open,
Liberty,
dot,
IO.
C
Let
me
get
this
a
little
bit
bigger
again,
make
it
a
little
bit
easier
to
read
and
a
lot
of
the
same
information
as
a
certification
request.
You
know
what
version
of
the
product
what
version
of
the
spec
the
TCK
that's
in
use,
but
the
unique
thing
here
is
at
the
bottom.
So
here's
where
we
include
all
of
the
test
results.
So
when
you're
doing
the
platform
test,
I
don't
know
how
many
of
you
are
familiar
with
it.
C
C
Okay,
this
is
a
TCK
results
chart.
We
just
went
through
that.
So
here's
our
big
announcement,
this
just
came,
live
overnight
and
so
here's
our
the
page
is
to
carded
ite
compatibility
and,
let's
just
go
out
there,
just
a
show
that
it
really
is
live,
and
you
can
see
that
right
now
we
have
two
products
listed.
C
We
have
eclipse
GlassFish
and
the
open
Liberty
release
and
both
of
them
are
full
platform
compatible
and
web
profile
compatible
now
also
late.
Yesterday,
the
wild
fly
project.
They
submitted
certification
requests
for
their
wild
play,
a
product
to
be
Jakarta,
ee8
compliant,
and
we
just
didn't
have
the
time
to
go
through
all
of
the
verification
overnight.
The
certification
requests
have
been
accepted
so
I'm
guessing.
We
just
have
a
little
bit
more
paper
working
a
little
bit
more
website
to
update
and
they'll
be
listed
here
as
well.
I'm
also
assuming
I
know
from
talking
with
them.
C
C
The
biggest
hurdle
that's
going
to
be
in
front
of
us
is
the
Java
X
namespace
is
frozen,
so
I
mentioned
early
on
how
Oracle
is
still
protecting
some
other
Java
trademarks
and
they
have
included
Java
X
in
this
protection.
So
this
means
that
moving
forward
we
have
to
move
to
a
new
namespace
for
all
of
the
API
and
I
have
a
separate
chart
that
we'll
be
talking
about
this.
But
that's
something
to
keep
in
mind.
That's
going
to
be
something
that
affects
us,
post,
Jakarta,
ee8.
C
C
We
get
a
lot
of
that
scrubbing
in
the
specifications
as
we
came
forward
and
as
we
get
more
of
the
specification
source
code
into
eclipse,
we'll
have
to
do
more
of
that
scrubbing
just
to
make
sure
that
we
are
utilizing
acronyms
appropriately
and
then
the
bottom
bullet
there
just
to
emphasize
the
micro
profile
community
and
the
jacquard
EEE
community
I
did
I
I
had
a
chart
from
a
previous
presentation
that
I
probably
should
have
included
here
the
main
participants
in
the
community.
They
are
really
overlapping
between
micro
profile
in
Jakarta
EE.
C
So
if
anybody
thinks
that
we're
competing
and
butting
heads
just
throw
that
out
the
window,
we
we
are
working
together,
we're
trying
to
figure
out
the
right
solution
for
micro
profile
and
Jakarta
EE.
You
know
we
have
a
little
bit
different
processes.
Like
I
mentioned,
we
have
done
how
many
nine
platform
releases
a
microp
roll
file
and
22
component
releases
in
the
last
three
years.
It's
taken
us
a
year
and
a
half
to
two
years
to
do
one
release
here.
You
know
now
that
we
have
the
whole
process
in
place.
C
We're
going
to
be
able
to
do
a
much
quicker
turnaround
for
Jakarta
EE,
but
are
we
going
to
be
able
to
match
what
we've
been
doing
with
micro
profile?
So
that's
some
of
the
stuff
that
we
have
to
figure
out
and
we
are
working
together
with
the
Eclipse
Foundation
and
both
of
the
communities,
and
we
will.
We
will
get
this
figured
out
eventually.
C
Okay,
so
the
big
thing
here,
Java
xq2
card,
a
namespace-
we
have
to
do
something
different
I
even
put
the
the
example
in
here.
If
you
have
a
simple
update
to
any
new
value,
you
know
whether
you're
adding
a
new
value
or
you're
modifying
the
name.
You
know
something
any
simple
update
that
has
to
move
to
a
Jakarta
namespace,
the
Java
X
namespace,
everything
associated
it
with
it
is
frozen
with
Java
EE
8.
We
can
continue
to
use
them
which
occur
EE
8,
but
any
changes
require
a
move
to
Jakarta.
C
So
the
big
question
is:
okay:
did
we
do
it
like
a
band-aid?
Do
we
do
the
big
bang
and
say?
Okay,
this
is
gonna
hurt,
but
let's
just
do
it
all
at
once
and
we're
gonna
move
everything
that's
in
Jakarta
ee8
and
move
it
to
the
new
Jakarta
namespace.
So
that's
one
way
to
look
at
it
now.
There
are
two
variations
that
I
listed
here.
One
of
them
says
everything.
C
That's
in
Jakarta
ee8
we're
going
to
move
to
Jakarta
all
at
once
or
the
other
one
is
just
a
slight
variation
where
we
say
well
most
everything,
because
there's
a
few
technologies
in
Jakarta
ee8
that
are
stabilized
and
no
one
is
really
using
them.
So
why
should
we
move
those
forward?
Should
we
just
cut
those
off
now
and
then
move
that
forward?
But
that's
such
a
small
piece,
it
really
is
basically
saying:
should
we
be
moving
everything
all
at
once
in
one
big
release?
C
The
other
approach,
that's
getting
a
lot
of
discussion
as
well
is
an
incremental
approach.
So,
instead
of
doing
everything,
let's
just
do
the
components
that
are
required.
So
if
we
have,
you
know,
let's
say
jax-rs
because
I
know
that
they're
a
very
active
community
and
they
want
to
do
a
new
release
of
jax-rs
for
Jakarta
ee9,
okay.
Well,
then
they
would
have
to
make
changes
to
be
in
the
Jakarta
namespace
and
then,
if
there's
any
dependencies
on
them,
you
know
or
through
them,
then
maybe
they
would
have
to
change
as
well.
C
But
you
know,
let's
just
do
the
ones
that
are
required.
Instead
of
doing
everything.
All
at
once,
another
idea
that
has
been
proposed
is
the
idea
of
extending
the
Java
X
namespace,
and
this
is
very
similar
to
what
we
did
with
micah
profile,
where
we
had
the
base
features
from
Java
EE
and
some
of
those
other
features
from
micro
profile
were
just
extensions
of
the
capabilities
in
Java
EE.
So
maybe
we
can
do
something
like
that.
It's
another
alternative,
that's
being
discussed
and,
of
course,
the
bottom
link
there.
C
There
could
be
many
other
variations
to
this,
and
so
this
this
bottom
link
will
just
take
you
to
our
whole
discussion,
and
so
you
could
do
a
new
PR
if
you
have
a
third
fourth,
fifth
idea
for
what
we
do
with
this
namespace
move
feel
free,
open
up
a
pea
and
let's
discuss
it
and
and
see
if
it,
you
know,
meshes
with
some
of
our
current
ideas
or
not.
So
we
are
looking
for
community
input.
C
So
I've
been
talking
a
little
bit
about
the
content
of
these
various
releases
and
we
also
have
to
look
at
the
timeline.
So
one
thing
that
we
are,
probably
you
know
we're
kind
of
wondering:
do
we
do
this
change
for
the
Jakarta
namespace?
Do
we
do
it
all
at
once?
You
know
Big
Bang
or
do
we
do
the
incremental
and
one
of
the
things
that
has
come
up
is
maybe
it's
going
to
come
down
to
the
ability
of
these
different
components
to
step
up
to
this
work?
C
If
we
do
a
Big
Bang,
that
means
every
one
of
the
components
has
to
do
this
work,
and
that
means
you
have
to
update
your
specification.
Your
API
is
your
tcks
compatible
implementations,
all
the
tools,
all
the
helpful.
You
know
things
and
the
IDE
everything
has
to
be
done
all
at
once.
That's
a
huge
effort
and
do
we
have
the
resources
signed
up
in
order
to
actually
do
all
of
this
work?
So
that's
one
way
to
look
at
it
now.
C
C
Jsf
JavaServer
faces
Jakarta
caught
myself,
Jakarta
server
faces,
so
maybe
those
are
the
only
ones
that
could
sign
up
to
do
the
work
and
then
along
you
know,
maybe
that's
the
content
of
Jakarta
ve9
and
maybe
that's
our
incremental
approach,
but
then,
on
the
other
hand,
if
we
get
a
lot
of
components
that
are
raising
their
hand
and
saying
yes,
we
can
do
this.
We
we
want
to
do
this
and
then
you
look
at
the
ripple
effect
on
the
dependencies.
C
C
That's
where
we
need
help
from
all
of
you.
I
put
several
links
here,
the
platform
project.
That's
the
project,
that's
going
to
be
defined
or
that
will
be
defining
the
content
of
the
platform.
So,
as
we
are
looking
at
Jakarta
ee9
Jakarta
EE
10,
that's
the
project.
That's
going
to
be
responsible.
So
if
you
have
an
interest,
get
involved,
I
mentioned,
there's
the
mailing
list
for
the
platform
developers.
We've
got
the
github
issues,
pull
requests.
We
had.
C
You
know
a
lot
of
ways
to
get
involved
directly
with
the
platform,
but
maybe
the
platform
is
just
too
big.
Maybe
you
have
more
interest
in
just
helping
out
JPA
in
the
persistence
and
that's
great
so
go
out
and
take
a
look,
find
your
project
of
interest
and
help
them
out
so
as
we're
working
through
the
content
for
Jakarta
ee9.
If
you
can,
how
about
one
of
those
components
reach
their
goals
and
that's
going
to
help
us
reach
the
Jakarta
ee9
goals?
Okay,
so
this
is
where
we
are
looking
for
a
lot
of
community
involvement.
C
C
This
is
where
you
know
the
wild
hares,
the
wild
ideas
they
first
come
up
and
through
that
discussion,
then
maybe
that
will
feed
back
into
the
platform
and
says:
okay,
look.
This
was
a
good
idea.
We
got
do
something
along
these
lines
and
we
can
pull
that
information.
Oh
the
community
mailing
list
feed
it
into
the
platform
and
hopefully
move
from
there.
C
C
A
C
So
right
now
there
is
nothing
definitely
in
plan
for
dropping
any
of
the
features.
So
right
now,
there's
nothing
that
I
could
point
at.
That
would
say
that
we
are,
you
know,
dropping
anything.
I,
think
that's
where
we
are
looking
for
input.
I,
guess:
I
was
kind
of
emphasizing
the
developer
input.
What
we
really
need.
The
customer
input
as
well
so
I
know
a
lot
of
people
on
the
call,
are
you
know,
consultants
and
they
work
with
many
different
customers?
C
It
would
be
good
to
start
talking
with
them
and
finding
out
what
kind
of
impact
are
they
willing
to
accept?
You
know
whether
it's
dropping
some
of
these
older,
stable
features,
doing
the
Big
Bang
versus
the
incremental.
Any
of
that
input
from
real
customer
bases
on
that.
That
would
be
very
helpful
in
helping
us
decide
the
direction.
A
C
A
Can
you
please
clarify
situation
with
the
Java
as
scene,
Jakarta
version
compatibility?
Is
there
any
limitation
or
recommendations?
For
example,
since
version
11
Java
removes
any
packages
from
Java
x,
XM,
l,
WS,
java
xml
bind
and
transactions,
but
last
one
still
not
do
not
include
to
me
mature
I'm,
told
upon
this
question.
I
do.
C
C
A
C
C
Now
the
other
app
servers
I
can
come
along
I,
don't
know,
I,
don't
know
what
their
plans
are,
but
I
can
tell
you
about
open
Liberty
the
support
for
Java
SE
versions
after
Java
SE
8.
That
definitely
is
one
of
our
considerations
for
Jakarta
ee9.
We
we
have
to
look
at
that
because,
like
the
questioner
mentioned,
there
are
some
packages
that
were
removed
from
Java
SE
11
and
we
have
to
allow
for
that
in
our
definition
for
Jakarta
ee9
going
forward.
So
on
the
situation
we
already
have
documented
in
various
issues
on
the
platform.
A
Okay,
thanks
Kevin,
the
questions
are
coming
in
and
just
to
let
everyone
know
the
community
is
out
there.
Also
monitoring
the
chat
and
I
see
many
questions
that
are
being
posted
in
the
chat
are
already
being
answered.
So
thanks,
everyone
for
pitching
in
it's
a
true
open
source
and
community
driven
event.
As
we
appreciate
in
the
ask
questions
section,
let
me
find
another
one.
Tell
us
about
Java,
EE
Jakarta
skeleton
framework.
Are
you
do
you
have.
C
C
C
So
that's
the
only
reason
that
we
have
a
skeletal
specification
in
place
as
far
as
applications
skeletal
skeletons,
you
know
templates
for
applications,
I
would
say
that's
probably
outside-
and
this
is
me
speaking,
it's
probably
outside
the
scope
of
Jakarta
EE,
but
maybe
as
part
of
the
IDE
s,
that
will
be
providing
support
for
Jakarta
88
on
the
road.
So
maybe
that's
something
that
they
can
be
looking
at.
I,
don't
know
that
we
as
a
platform
want
to
define
it.
C
Yes,
they
are
all
of
the
source
code
is
in
github
repositories.
You
can
anybody,
can
download
them
and
take
a
look
at
them
modifying
themselves.
If
there
are
problems
with
them,
they
can
be
submitted
as
issues
or
pull
requests.
That's
the
neat
thing
with
this
is
that
it
is
completely
open
and-
and
you
are
able
to
contribute,
if
there's
missing
test
cases,
that's
one
thing
that
we
find
quite
often
as
we're
going
through
that
you
know.
A
C
C
Well,
I
mean
even
open.
Liberty
is
a
ready
for
production.
You
know
application
server,
we
actually
tested.
The
version
that
we
tested
is
what
about
three
four
months
old,
but
that's
one
that
we
started
with.
So
that's
the
one
that
we
stuck
with
what
their
that's
fully
ready
for
production
use.
So,
yes,
Jakarta
eeh,
is
ready
for
production
are.
C
A
C
You
know
what
I'm
referring
to
right
at
the
end,
when
we
were
trying
to
figure
out
the
tcks
and
because
everything
was
open
and
we
had
a
good
discussion
on
it,
we
came
to
a
suitable
resolution
that
satisfied
everybody
that
was
participating
and
it
just
like
that.
This
is
perfect.
This
is
why
we're
doing
everything
in
the
open
and
it's
it
worked
out
very
well.
So.
A
At
this
point,
because
we're
two
minutes
from
the
next
session,
I
would
like
to
thank
Kevin.
This
is
an
amazing
opening
session.
Thank
everyone
for
joining
this
session
and
all
the
questions
and
I'd
like
to
invite
people
to
move
on
to
the
next
session,
which
is
with
the
Josh
Juneau
and
then
we'll
let
Kevin
to
have
his
coffee
from
Jakarta.
One
live
stream
on
the
cartel
any
t-shirt
on
so
welcome.
Yes,
thank
you,
Kevin!
Thank
you!