►
From YouTube: Jakarta EE Community Call | 2019-05-08
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.
In the Jakarta EE Community call on May 2019-05-08, Eclipse Foundation's Executive Director, Mike Milinkovich, provides an update on Jakarta EE, David Blevins follows up with a Specification Committee Update, then the floor is opened up to Q&A on Trademark topic.
To join the next call or read the previous agenda meeting minutes, click the link here:
https://docs.google.com/document/d/1TH_p_m-z3v9HZyhgwW41JzXWTFIwrClGLaSDIy0Sf5w/edit?usp=sharing
///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
B
You
know
we've
been
having
these
calls
every
month,
it's
a
chance
for
us
to
get
together
in
the
working
group
and
those
interested
in
Jakarta
EE
to
find
out
what's
happening
to
talk
about
any
issues
that
are
out
there
and
it
just
generally
make
sure
that
information
is
being
shared.
We
do
it
in
a
variety
of
formats,
both
through
the
newsletter
that
we
just
put
out
by
the
mailing
list
and
so
on,
but
I
think
just
having
a
chance
to
actually
speak.
Have
some
of
the
folks
who
are
leading
some
of
the
activities.
B
Talk
is
useful
but
more
important
to
get
questions
so
so
the
agenda,
hopefully
you
can
see
my
screen
that
we
put
together
is
is,
is
fairly
packed
in
terms
of
topics.
We
know
that
there's
a
couple
of
key
things
that
are
going
on
as
we
work
towards
Jakarta,
ee8
and
so
we'll.
Let
each
of
the
speakers
get
to
those
topics
and
then
we'll
open
the
floor
up
for
questions
at
the
end
of
each
of
those
topics.
The
first
one
is
going
to
be
Mike
Milankovitch.
B
Who
is
going
to
talk
about
just
general
updates
and
then
essentially
both
the
blog
that
he
put
up
last
Friday
and
and
Mike
is
actually
on
a
short
leash
in
terms
of
time,
so
we'll
let
him
go
and
then
you
can
ask
whatever
questions
you
have
for
him
and
then
he's
going
to
have
to
slip
away.
So
with
that
Mike.
Are
you
online
and
ready
to
roll.
A
C
B
D
Do
the
next
slide,
please
routine
so
and,
as
Paul
said,
I
apologize
in
advance.
I
can
stay
for
about
30
minutes
and
then
I'll
have
to
head
over.
To
do
a
repeat
of
this.
Talk
at
the
on
the
floor.
Sumit
in
the
community.
Central
so
highlights
the
progress
so
far,
so
code
has
contributed
the
T
CK's
open-sourced,
GlassFish
5.1
is
Java,
EE
8
certified
and
is
released
from
eclipse
and
it.
So
it's
gone
through
its
its
first
release
review
through
the
ecliptic
development
process.
D
We
at
the
Eclipse
Foundation,
in
conjunction
with
the
jacquard
EE
working
group,
have
created
the
Eclipse
Foundation
spec
process
and
from
that
created
the
the
jacquard
EEE
spec
process
can't
I.
You
know
amp
the
over
emphasize
how
much
work
it
was
to
create
an
entirely
new
community-based
specification
process
process
from
from
scratch,
and
that's
that's
actually
a
pretty
major
accomplishment
in
its
own
right
and
stay
tuned
for
tomorrow,
because
we're
gonna
be
publishing
our
2019
Jakarta
EE,
developer
survey
and
there's
some
some
interesting
results
there
as
well.
So
next
slide.
D
Dev
mailing
list,
and
just
so
everybody
understands
the
jakarta
platform-
is
the
specification
project
that
is
going
to
be
responsible
for
the
definition
of
the
platform
specification
going
forward.
So
this
is
where
these
platform
level
conversations
will
be
happening
not
just
now,
but
in
the
future,
for
many
to
Kyle
next
slide.
Okay,.
D
So
I'm
ascending
I
know
that
David
Blevins
is
also
talking
about
this
after
me,
so
I'm
not
going
to
steal
his
thunder,
but-
and
this
is
the
basis
of
a
blog
post
that
I
put
out
this
morning
as
well
on
behalf
of
the
jacquard,
a
steering
committee.
So
in
a
nutshell,
Jakarta
ee8
is
going
to
be
fully
compatible
with
Java
EE
8.
So
it
still
will
use
the
Java
X
namespace
and
we'll
be
using
the
the
T
CK's
that
have
been
open
sourced
at
eclipse
without
without
any
changes.
D
So
the
news
from
my
blog
post
last
week
is
that
the
main
news
is
that
the
Java
X
namespace
is
not
going
to
be
evolved
by
the
Jakarta
spec
process
and
we're
actually
gonna
have
to
change
the
names
of
the
specifications
themselves.
So
what
that
means
is
that
there
is
four
things.
Obviously,
things
cannot
stay
static
forever.
So,
where
are
changes
required?
It's
gonna
have
to
happen
in
a
different
namespace,
most
likely
the
Jakarta
namespace,
and
this
is
but
this
is
the
exact
topic.
D
That's
under
conversation,
the
the
mailing
list
that
I
pointed
to
you
earlier
for
new
kind
of
platform.
So
if
you
want
to
dive
in
and
participate
that
conversation
by
all
means,
please
do
next
slide
and
to
repeat
ourselves
again,
because
every
we've
seen
this
show
up
a
few
times
with
some
major
misunderstandings.
D
So
we've
done
the
first
two
steps
on
this
on
this
journey,
so
eclipse
GlassFish
5.2,
it
might
actually
be
5.1
if
it
works.
Just
if
it
works
unaltered
will
be
shipped
using
Jakarta,
a
branding
and
we're
currently
expecting
that
to
happen
in
the
early
fall
so
on
or
around
so
you
know,
think
of
September,
1st
plus
or
minus
is
is
the
date
for
for
that,
and
then
that
is
the
contents.
What
we
decide
is
the
content
for
Jakarta
ee9
is
going
to
really
determine
when
it
shifts.
B
A
D
D
E
Hi
this
is
Tobias,
I,
don't
know
if
this
is
appropriate
at
this
time.
But
since
you
spend
a
lot
of
the
time
in
in
dealing
with
with
Oracle
and
their
lawyers,
it
would
be
really
really
beneficial
for
all
of
the
community
to
learn
a
bit
more.
What
the
problems
were
in
that
process.
I
know
that
you
agreed
not
to
talk
too
much
about
that,
but
there
is
a
lot
of
speculation
going
on
on
one
of
the
people
that
they
try
to
figure
out
what
what
happened
and
is
there
any
chance?
E
D
D
We
thought
were
constraining
the
freedom
of
action
of
the
Eclipse
Foundation
and
its
communities
in
ways
that
we
could
not
accept-
and
some
of
this
has
talked
about
in
the
in
the
board
meeting
minutes
that
I
pointed
to
in
my
blog
as
well.
I
know
it's
a
little
bit
hard
to
to
try
to
understand
out
of
there,
but
I.
D
B
D
E
A
F
It's
important
to
mention,
too,
that
this
isn't
something
that
was
just
figured
out
in
the
last
week,
I
mean
Mike
and
others
have
been
working
with
Oracle
for
oh,
you
know
a
year
and
a
half
to
try
to
iron
out
these
issues,
and
so
there's
a
lot
of
consideration
that
goes
in
there
and
that
can't
be
captured
in
Mike's
brief
summary.
But
it
is
something
we
have
been
around
and
around
and
around
about
so
many
times
that
I
can't
believe
that
Oracle
would
ever
change
their
mind
about
the
situation.
F
E
Laughed
I'm
here
from
the
London
Java
community
that
sort
of
had
a
question
around
the
infrastructure,
etcetera
around
continuing
to
pass
tcks
all
over
some
specifications
under
the
Jakarta
brand.
Is
that
all
happening
now
on
Eclipse
or
on
shore
common
infrastructure?
Or
are
we
still
rely
on
individual.
D
We
haven't
yet
made
any
commitments
that
we
will
run
all
of
the
tcks
for
all
products
on
the
Klipsch
infrastructure,
because,
as
you
can
imagine,
that
could
get
pretty
expensive.
But
it's
certainly
something
that
we're
considering.
You
know
it
could
be
a
benefit
of
membership
in
to
Jakarta
working
group,
for
example,
but
so
it's
something
we're
considering
but
other
than
GlassFish.
D
At
this
moment
the
answer
is
no
I
mean
I,
mean
that,
but
I
would
point
out
that
what
we
have
accomplished
over
the
last
you
know,
six
to
eight
months
on
the
on
the
build
and
infrastructure
side
in
terms
of
being
able
to
build
GlassFish
and
run.
The
tcks
has
alone
represented
an
awful
lot
of
work
for
for
quite
a
few
people.
So
it's
it's
been
a
big
undertaking
for
sure.
D
E
E
E
So,
just
because,
of
course,
some
of
the
tests
would
also
be
by
vendors,
who
want
to
prove
that
they
are
compatible
and
with
regards
to
open
JDK.
If
a
vendor
has
their
own
KDK,
can
they
tests
that
on
a
neutral
infrastructure
under
the
open,
JDK
umbrella,
or
do
they
need
their
own
GIS,
service
and
stuff
like
that?
Well,.
D
E
A
E
D
A
So
about
the
blog's
that
we're
having
let
me
go
in
here,
many
of
you
have
written
blogs
and
for
those
of
you
who
did
not
know
or
were
shocked,
with
the
blog
update
by
convention
where
and
when
here
scared
what's
going
on
and
on
the
level
of
whoa,
what
is
happening
as
a
developer?
Can
we
go
into
the
impact,
the
emotional
and
whatever
you're
working
on?
Just
let's
be
a
little
more
focused
on.
You
are
working
on
something.
What
happened?
Oh.
C
C
There
we
go,
I
am
now
not
muted,
okay,
so
we're
having
a
discussion
right
now
out
in
the
open
in
terms
of
how
to
do
the
migration
from
the
Java
X
namespace
to
the
Jakarta
namespace,
and
you
know
how
we
do
this
is
completely
up
to
us
and
you
know
I
guess.
The
important
thing
to
point
out
is
once
we're
on
the
other
side
of
any
migration.
What
we
do
from
there
on
out
is
more
or
less
free
from
any
trade
market
restrictions
or
external
licensing
restrictions.
C
So
you
know,
obviously
we
under
our
own
restrictions
at
that
moment,
but
for
us
to
decide
as
a
community,
so
the
North
Star
sentence
that
I
would
say
is
what
we're
focusing
on
is
we
want
to
maximize
compatibility
with
Java,
create
and
Jakarta
EE
for
Q
conversions
without
stifling
innovation,
so
that
last
point
is
important.
So
basically,
we
want
to
remain
as
compatible
as
much
as
possible
for
as
long
as
possible,
within
the
bounds
that
we
shouldn't
make
it
hard
to
innovate
in
our
space.
We
want
people
to
be
able
to
enter
into
the
Jakarta.
C
Just
just
a
quick
highlight
of
what
I'm
gonna
cover
is
what
it
means
to
transfer
from
the
java
x
to
jakarta
namespace,
what
we're
imagining
in
terms
of
compatibility
and
then
the
couple
proposals
we
have
going
on
and
by
the
way
I
can't
read
any
chat.
So
if
anybody
has
any
questions,
you're
welcome
to
interrupt
me
at
any
time.
A
E
A
B
C
For
example,
bean
validation
will
go
from
Java,
X
validation
to
Jakarta
validation,
jax-rs
would
go
from
Java,
X,
W
SRS
to
Jakarta,
WS,
RS
and
so
on,
and
even
CDI
would
have
to
move.
That
was
one
of
the
questions
that
I
had
you
know.
Cdi
is
technically
not
an
Oracle
specs,
it's
still
affected
and
the
answer
is
yes,
anything
in
the
Java,
EE
or
Jakarta
EE
umbrella.
That
is
now
going
to
be
developed
up.
The
Eclipse
Foundation
is
affected,
so
some
things
which
are
not
affected.
C
There
are
several
Java
X
packages
in
JVM
and
outside
Java
EE
in
Jakarta
II
that
are
not
affected
and
some
of
them
are
are
not
the
ones
you
would
think
so.
You
know,
for
example,
Java
X,
RMI
and
Java
X
naming,
which
is
J
and
E
I
they're
not
affected
jonathan
x
sequel,
which
is
all
of
JDBC,
that's
not
affected.
There
are
several
XML
packages
like
stream,
transform
and
XPath
all
not
affected
as
well.
C
There
is
JMX
types
things
which
are:
none
of
that
is
affected,
so
I
was
one
of
the
very
first
rounds
of
feedback
that
that
we
noticed
when
the
tweets
were
happening.
Is
people
imagining
like
all
Java
X
is
gone.
That
is
not
the
case,
and
they
were
also
imagining
that
you
could
just
do
a
simple
one:
Java
X
to
Jakarta
mapping
and
you're
done.
It
won't
be
in
the
case,
it'll
be
more
like
50,
60
mappings.
C
There
won't
be
hundreds,
but
in
being
that
ballpark,
okay,
important
topic
to
clear
out
when
would
repackaging
be
required?
Okay,
what
would
cause
you
to
have
to
repackage
something
from
Java
X
into
Jakarta?
If
we
were
to
add
a
method
to
a
class?
That's
in
the
Java
X
API
could
be
as
simple
as
adding
a
parameter
to
a
method,
overloading
a
method
changing
the
method.
Changing
this
the
exception
handling.
C
Any
of
that
type
of
change
would
require
a
move
from
Java
X
into
another
package
like
Jakarta,
and
then,
if
we're
going
to
even
do
something
as
small
as
add
an
enum
value
right
say
we
have.
We
want
to
add
HTTP
patch
to
serve
less
okay.
That
requires
a
change
and
then
therefore
everything's
gotta
get
moved
from
jerk
Java
acts
to
Jakarta
changing
the
behavior
of
any
class,
so
we're
not
changing
the
method
signature,
but
we're
fundamentally
changing
how
the
implementation
works
or
how
the
design
of
the
of
the
code
should
work.
C
That
requires
a
move.
Alright,
so
Java
mail
is
inherently
one
of
those
specifications.
That
almost
is
entirely.
You
can't
separate
the
interface
from
implementation.
Any
change
in
that
that
requires
a
repackaging.
Even
a
bug,
face
things
that
do
not
require
a
repackaging
would
be
just
superficial
changes
to
documentation
types
of
things
right.
So
if
we
wanted
to
update
the
Java
doc,
that
does
not
require
that
the
code
move
from
Java
X
to
Jakarta.
We
want
to
update
the
specification
document
to
expand
some.
C
Some
things
make
some
things
clear
that
does
not
require
a
a
release
or
migration
of
Ning
spaces.
They
want
to
update
the
TCK
simply
to
fill
it
out
to
be
more
complete,
assuming
we
don't
need
to
change
into
the
api's.
That
does
not
require
a
Java
ex
to
Jakarta
transition,
so
important
compatibility
notes.
So
Mike
mentioned
it
already.
C
Jakarta
ee8
will
not
have
any
namespace
changes
at
all
and
will
be
released.
Basically,
as
is
all
under
the
Java
X
namespace.
So
there
would
be
no
potential
compatibility
concerns
in
that
release.
Al
Jakarta,
EE
next
will
be
compatible
and
that
will
have
to
use
some
form
of
tooling
to
provide
that
compatibility,
because
it
will
contain
some
form
of
Java
X
to
Jakarta
switch
at
least
to
some
level.
How
much
is
the
discussion
we're
having
now
and
that's
open
and
we'll
get
to
that?
C
We've
got
a
stretch
that
existing
applications
will
run
and
it
won't
be.
You
know,
you've
got
to
figure
that
up
for
yourself
user.
It
will
be
the
vendors
providing
tools
that
allow
those
old
applications
to
run.
So
it
will
be
us
making
sure
that
these
things
happen
and
we'll
be
accountable
for
it.
It
will
likely
not
be
a
requirement
of
the
spec,
because
we
want
to
make
sure
that
someone
new
can
enter
the
ecosystem
and
implement
just
the
Jakarta
namespace
or
whatever
mix
of
Jakarta
and
Java.
C
C
A
C
E
Either,
for
was
the
there
was
a
fear
that
having
a
toccata
he
ate
with
the
Java
X
namespace
in
the
Jakarta,
nine,
with
Jakarta
Todd
Starnes
namespace
would
confuse
use
them.
Wouldn't
it
be
better
to
have
a
different
name
for
the
Jakarta
8
version,
something
which
probably
doesn't
have
Trotter
in
it
or
whatever,
so
that
people
later
can
have
a
clear
distinction
between
Jakarta
is
the
thing
with
Jakarta
X
Jakarta
dot
star
as
packages,
and
it
would
be
a
clean
rule.
Otherwise
we
have
the
same
name
but
completely
different
things.
Yeah.
C
C
Let's,
let's
go
ahead
so
effectively
right
now,
what's
being
issued
is
two
proposals.
These
are
not
the
end
of
all
proposals.
This
is
to
get
the
conversation
going
and
so
people
can
understand
kind
of
what
it
is
that
are
the
high-level
options
that
that
could
be
done.
Other
options
are
available.
The
discussion
is
happening
right
now
on
the
Jakarta
ee
platform
dev
mailing
list.
Everybody
is
welcome
to
join
that
mailing
list.
C
We
have
spent
you
know,
18
months
or
more
getting
to
this
point,
so
we
do
not
want
to
spend
another
three
months
arguing
about
how
to
handle
the
namespace
change
want
to
get
this
done
quickly.
So
the
conversation
is
is
set
to
terminate
and
stop
and
conclude
on
June
19th
at
that
on
June
9th.
Hopefully
we
have
a
very
clear
community
consensus
at
that
point
and
we
are
organizing
ourselves
to
get
to
that
level
consensus.
C
If
no
consensus
is
reached,
then,
ultimately,
it
will
fall
in
the
hands
of
the
spirit
of
the
specification
committee
to
just
make
a
choice,
but
you
know
we're
giving
it
a
month-long
shot
on
the
community
to
handle.
So
there's
basically
two
schools
of
thought
on
this
type
of
move.
One
school
of
thought
is
Big
Bang
that
we
do
everything
all
at
once
and
the
other
one
is
incremental.
C
You
know
what
things
we
would
want
the
ability
to
modify
at
any
point
in
the
future,
maybe
not
immediately
even,
but
we
would
move
them
into
the
Jakarta
namespace.
If
we
felt
that
it
was
a
specification
we
wanted
to
work
on
in
the
future
right
now
or
in
the
future.
So
all
that
stuff
will
get
moved.
We
would
do
it
at
once.
Okay,
and
then
the
the
thinking
on
top
of
that
is.
C
If
we
were
going
to
do
this,
it
would
make
sense
to
release
that
immediately
as
Jakarta
EE
9,
so
that
the
industry
had
an
opportunity
to
absorb
the
change
now
most
people
when
they
hear
that
they
go
that's
a
very
boring
release.
I
want
new
features,
we
can
have
a
conversation,
but
we
have
to
understand
that
the
industry
is
bigger
than
application
server,
vendors
and
application
server
users.
There
are
monitoring
tools.
C
There
are
cloud
platforms
there
IDs
there
are
projects
like
primefaces
built
on
top
of
JMS
JFS
JSF
and
all
those
things
have
to
migrate
and
a
lot
of
times
they
have
to
migrate
before
you
can
really
absorb
a
change.
So
that
is
one
of
the
reasons
that
a
push
out
and
immediately
release
the
Jakarta
ee9
with
only
a
job
x2
Jakarta
namespace
change
is
on
the
table
right,
jakarta.
C
There
are
pros
and
cons
to
this
in
the
pearls
list
is
all
the
industry
gets
one
shot
to
do
the
to
do.
The
change
does
not
have
to
keep
dealing
with
this
over
and
over
again
effectively.
The
investment
happens
once
and
once
the
once.
The
dust
settles
we're
done
with
it.
The
other
Pro
is
that,
on
the
other
side
of
this,
we're
completely
free
to
do
all
the
changes
we
want
and
without
having
to
worry
about
it.
We
are
not
carrying
Java
X
forward
any
longer
than
we
have
to.
C
There
are
cons
to
this.
This
is
the
largest
upfront
cost
for
all
in
the
industry,
effectively
wet
the
choke
down
the
main
space
change
in
one
shot,
and
so
it
does
raise
the
bar
in
some
regards
for
people,
and
that
does
you
know,
make
potential
migrations
of
apps,
maybe
a
little
more
complicated.
This
is
more
surface
area
on
the
change,
but
basically
those
are
those
are
the
high-level
pros
and
cons.
B
C
Ego
though
the
intent
is
that
so
that
that
question
hasn't
been
discussed,
I
mean
I
mean.
So
if
the
specification
moved
into
Java
X,
obviously
the
test
would
be
testing
against
Java
X.
That's
not
a
question.
That's
a
that's
a
certainty.
The
question
would
be.
Is
there
going
to
be
some
way
if
a
vendor
claims
it
can
run
the
Java
X
equivalent?
Are
there
going
to
be
some
way
to
prove
that
the
in
test?
E
C
Effectively,
the
statement
you
think
you're
trying
to
make
is
whether
you
write
the
tooling
and
it
handles
sixty
main
spaces
or
thirty.
The
tooling
has
to
be
same
level
of
quality,
yes,
yeah
more
or
less
so.
The
incremental
approach
is
we
move
as
needed
over
time,
and
you
know
theoretically,
the
least
noisy
of
all
changes
right.
So
you
know
there
are
good
50
or
60
packages
we
have,
and
potentially
we
only
move
things
like
jax-rs
CI
bean
validation,
JPA
stuff,
that
we
really
do
clearly
know.
We
want
to
modify
and
borderline
things
like
Java
mail.
C
You
know,
maybe
perhaps
connector
definitely
the
old.
You
know
jsr
88
in
77,
which
were
management
and
deployment.
They
kind
of
didn't
go
anywhere.
Even
at
lunch
and
they've
been
nothing
has
happened
with
them
for
15
years.
You
know
that
stuff
would
clearly
stay
and
then,
of
course,
if
we
did
want
to
say
if
we
did
a
release
of
Jakarta
89
and
contained
say
you
know
Java
X
Mail
still,
but
in
Jakarta
de
10
we
wanted
to
change
java
xml.
C
It
would
become
jakarta
male
in
jakarta
de
10,
and
that
would
mean
you
would
have
to
keep
straight
in
your
head.
Was
that
one
Java
X,
or
was
that
one
Jakarta
in
Jakarta,
ee,
11
I
can't
remember?
When
did
we
switch
that
one?
So
that
would
be
one
of
the
considerations,
but
again
the
the
positive
of
this
one?
Is
we
don't
have
to
speculate
on
anything
that
we
would
want
to
move?
C
We
simply
move
it
when
it
is
seeing
that
we
want
to
move
it
in
the
list
of
cons
is
that
the
industry
effectively
would
have
to
absorb
a
change
on
potentially
every
Jakarta
release,
and
it
could
become
a
theme.
Oh
gosh,
every
time
I
go
to
update,
there's
more
package
changes
and
I
gotta
I
gotta,
migrate,
more
source
code
to
use
the
new
features
and
I
don't
really
like
them.
So
that's
a
potential
downside
of
it.
C
So
the
timelines
of
these
things
are
unchanged
and
I
want
to
kind
of
point
that
out.
It
is
very,
very
common
for
people
to
try
to
do
kind
of
horse
trading
because
say
you
know
a
is
a
constant
and
nine
is
the
next
version
number.
They
view
9
as
a
date,
and
they
want
to
cram
as
much
as
they
possibly
can
into
the
number
nine,
as
if
that's
how
things
work,
that's
not
how
things
work
so
not
using
version
numbers.
C
Even
we're
going
to
be
any
new
features
at
all,
even
discussions
of
to
pruning
or
deprecating
or
removing
api's,
then
we're
talking
next
year.
Okay.
So
this
is
important
to
talk
about,
because
the
level
of
effort
doesn't
change
based
upon
what
version
number
you
put
on
it.
So
one
of
the
most
immediate
feedback
that
people
got
was
I
want
the
next
version
to
become
have
new
feature
because
I've
waited
too
long.
C
Well,
that
means
that
you're
that
you're
advocating
we
skip
doing
the
two
releases
we
could
do
in
the
interim
and
only
do
the
one
released
next
year.
It
doesn't
mean
that
that
new
feature
release
comes
any
sooner.
It
just
means
now:
there'll
be
no
new
releases
and
the
industry
doesn't
have
the
opportunity
to
absorb
the
change
while
I
work
at
all
of
them.
You'll
read
with
new
releases,
so
there
isn't
really
anything
we
can
do
to
change
these
timelines.
C
C
Now
want
to
be
clear.
This,
yes
did
were
the
discussions
of
all
the
steering
committee.
You
know
Kevin
Sutter
mark
littell
our
en
times.
You
know
he.
Our
angle
is
because
the
guy
who
proposed
the
dakar
db9
immediate
release,
you
know
just
tons
of
people
I'm
only
the
messenger,
and
so
you
know
that
you
know
very
big.
Thank
you
to
all
this
specification.
C
E
We
could
do
in
the
meantime
is
to
think
about
applications
because
that
technically
doesn't
hurt
any
binary
compatibility.
So
we
should,
I
perfectly
agree
with
your
arguments
that
we
shouldn't
cram
into
in
new
features,
but
we
probably
if
people
have
spare
time
they
can
think
about
what
features
to
deprecate
or
not,
because
we
would
just
mark
them.
We
would
not
remove
anything
yet,
but
people
kind
of
have
a
little
bit
more
time
upfront
to
plan
for
stuff
which
likely
will
be
removed
in
let's
say
Jakarta
in
that
au,
10
or
11.
So.
C
So
defecating
is
one
thing
actually
moving
as
a
way
higher
mark.
So
I
agree
with
you
that
you
know
actually
moving
stuff
could
happen,
but
now
we're
talking
about
like
a
release
next
year,
at
least
in
my
opinion,
so
I
don't
know
if
others
have
opinions,
I
want
to
be
the
only
one
talking
at
this.
At
some
point
we
should
hear
the
more
on
this
investigation
from
anybody.
C
C
A
E
C
E
Yeah
so
when
I
read
Mike's
blog
post
I
failed
a
lot
of
anger
and
I
think
that
was
some
kind
of
motivator
to
opt
for
the
Big
Bang.
This
was
first
my
preferred
option
and
then
I
read
a
Richards
proposal
of
a
legacy
profile
and
I
I,
really
liked
the
the
perspective
of
not
having
to
carry
the
cargo
forward
from
all
the
past
we
had
and
now
I'm
trying
to
figure
out.
What's
really
the
difference
between
that
legacy
profile
proposal
and
the
incremental
approach
can?
Can
you
outline
it
at
our
day
or
perhaps
even
richer?
F
Yeah,
so
this
is
Richard
thanks
for
the
question.
The
legacy.
Okay,
so
call
classic
are
called
legacy,
but
at
any
rate,
the
difference
is
that
it's
always
maintained
as
a
separate
thing.
Whereas
when
you
do
the
incremental
poets
you'll
be
mixing
Java
X
along
with
Jakarta
namespaces
together-
and
my
thinking
is,
if
you
can
add
by
the
Java
X
stuff
as
the
as
the
legacy
profile,
sort
of
speak
or
classic
profile,
then
you
can.
The
rest
of
the
platformer
can
evolve
without
being
polluted
by
the
Java
X
namespace.
F
I
mean
I
just
sent
out
another
email,
that
kind
of
all
kinds
a
little
bit
more,
but
basically
the
even
if
you
do
a
big
bang
with
Java
x2,
the
Jakarta
namespace.
That
BIGBANG
becomes
a
profile
like
classic
or
legacy
that
anyone
can
implement,
but
the
actual
Jakarta
platform
is
independent
of
that,
so
it
only
evolved
with
its
own
profiles
and
that
sort
of
thing
and
the
Java
X
namespace,
or
that
what
we
identify
as
the
java
ee
8
platform
will
be
its
own.
E
C
C
This
is
the
only
it'd
be
done
once
and
you
don't
have
to
worry
about
paying
this
cost
all
the
time
and
is
it
something
you
can
rely
on
as
a
user
or
to
developer
of
tools
or
anything
that
you're
not
going
to
be
doing
this
for
the
next
10
years,
and
so
both
would
involve
potentially
a
subset
being
moved.
Obviously,
with
the
Big
Bang,
we
got
to
put
a
lot
more
thought
into
what
we
move
up
front
and
with
incremental
we
don't.
C
It
sounds
like
the
concept
of,
although
you
know
call
it,
you
know,
there's
a
it's
not
look
at
the
classic
profile.
Whatever
is
basically
on
top
of
either
of
those
everything
that's
in
the
Jakarta,
namespace
is
the
new
stuff
and
everything
that's
Java.
X
is
classic,
and
so
it
sounds
like
that
kind
of
concept
could
apply
to
either
Big
Bang
or
incremental.
Does
that
does
that
match
your
understanding,
Richard
yeah.
F
I
mean
I
thought
of
it,
both
in
terms
of
Big
Bang.
The
important
part
is
that
that
classic
profile
is
frozen,
it's
frozen
set
aside.
Vendors
can
choose
to
implement
it
if
they
want
to,
but
you
don't
have
to
implement
to
be
considered
Jakarta
compliant
there.
The
Jakarta
platform
itself
will
evolve
with
many
other
kinds
of
profiles
that
you
can
combine
in
that
classics.
Just
what's.
E
The
difference
to
just
having
an
old
application
server
running
I
mean
nowadays
the
the
days
of
the
big
islands,
where
you
have
one
server
and
thousands
applications
106
occasions
running
on
them
they're
over.
Usually
you
have
one
or
two
applications
running
on
the
same
server.
If
you
have
another
application,
start
up
a
new
server
so
and
those
old
applications
couldn't
could
run
on
the
old
file.
So
I
don't
see
a
reason
why
we
should
have
a
runtime
supplying
or
supporting
both
versions.
The
old
ntinue
one
you.
C
B
E
Problems.
The
reason
why
we
were
discussing
this
is
why?
Because
we
want
to
provide
compatibility-
and
that
means
that
you
have
an
existing
big
application-
that
probably
is
not
not
so
easy
to
migrate
in
in
one
big
goal,
so
you
will
pick
parts
of
it
and
and
migrate
it
to
the
New
World
to
the
Jakarta
world
and
over
time
you
will
be
able
to
then
leave
the
classic
profile
behind.
So
this
is
how
it
will
be
used
and
and
how
it
can
can
be
done
in
a.
C
Clear,
you
don't
intend
say,
say
you,
you
are
a
jacquard
EEE
user
and
you
have
an
app
that
already
runs
and
jacquard
EEE
11
comes
out.
Let's,
let's
go
let's
say:
jacquard
89
is
actually
safe.
When
you
talk
about,
you
want
to
not
update
your
application
and
running
on
the
Jakarta
9
server
or
the
existing
vendors
we've
all
committed
to
making
sure
that
that
application
will
run
without
modification.
So
the
only
time
that
you
would
have
to
do
any
work
on
your
side
is
it.
C
C
The
packages
looked
at
backwards
there,
but
more
than
likely
there
will
be
plugins
in
Eclipse,
IntelliJ
and
so
on
so
forth
that
helped
you
do
that
source
code
migration,
so
you
can
take
advantage
of
the
new
features
and
start
coding
against
them,
because
we
won't
be
able
to
modify
the
Java
X
namespace.
It
also
Richards
key
point
about
the
classic
profile
that
it's
frozen.
It
never
changes.
That's
always
going
to
be
the
case,
because
we
can't
legally
change
Java
X.
So
it's
not
a
it's,
not
a
proposal.
C
It's
a
constant
that
part
of
the
proposal,
but
anyway,
so
the
only
time
you
would
have
to
do
any
work
on
your
side
as
a
user
is
when
you
want
to
use
any
enhancements
that
are
made
to
existing
api's,
because
they'll
always
be
under
the
java
acts,
namespace
and
so
realistically,
say
jakarta.
Ee
11
is
going
to
contain
some
mix
of
formerly
Java
X
api's
moved
in
Jakarta
and
completely
brand-new
Jakarta.
Api
sites
like
this
was
a
imagine
a
couple
years
on.
The
future
right
will
be
both
a
little
bit
mix
of
both.
C
E
A
B
Put
it
back
up
David
that
would
be
great
yeah,
just
just
to
wrap
this
up.
Thank
you,
everyone
for
the
questions
and
David.
Thank
you
very,
very
much
for
going
through
this.
It's
useful
just
to
kind
of
walk
through
what
the
choices
are.
So
so
it's
been
useful
for
me,
and
hopefully
others
on
the
call.
Also
thanks
to
Mike
I
know,
he's
had
to
leave,
but
I
appreciate
him
doing
this
as
well.
The
conversation
continues
right
on
the
mailing
list.
B
B
Is
you
know
the
planning
and
the
work
that
has
to
go
in
to
get
Jakarta
ee8
out
the
door,
so
we
you
know
most
of
what
David
has
talked
about
is
assuming
that
you
cardig
is
done,
and
then,
where
do
we
go
from
there
right?
So
we're
gonna
be
calling
on
all
of
you
who
are
on
this
call
to
engage
in
helping
us
get
that
done
and
so
watch
for
that
discussion.
I
think
over
the
next
few
days
and
weeks,
because
you
know
they
as
as
as
was
talked
about
either
by
micro
David.