►
Description
This talk will walk through some of the ideas the Jakarta Concurrency team have identified for Jakarta EE 10. It will also cover how to get involved to shape Jakarta EE 10.
A
Hello,
everyone
and
welcome
to
another
jakarta
tech
talk
joining
us
today.
We
have
steve
millage
to
discuss,
jakarta,
concurrency
and
what's
next
steve,
is
the
founder
of
payera,
an
open
source
software
company
which
gained
large
market
recognition
and
blue
chip
customers
within
its
first
year,
and
if
you
have
any
questions
for
steve
as
we
move
through,
today's
presentation
feel
free
to
ask
it
in
the
chat
or
using
the
ask
a
questions
tab
at
the
bottom.
So
without
any
further
delay
steve
it's
over
to
you.
B
Thanks
yeah,
as
we
said,
we're
basically
going
to
be
talking
around
jakarta,
concurrency
present
and
future,
I'm
normally
the
project
lead
of
dakar
to
concurrency
specification
under
jakarta
ee.
So
as
project
lead,
my
goal
is
not
to
define
the
future
of
jakarta
concurrency,
but
it's
to
try
and
build
a
community
group
that
can
drive
the
specification
forward.
So,
basically,
part
of
that
is
this
presentation
and
we
start
to
do
other
presentations
to
different
groups
to
basically
help
people
to
get
involved.
B
B
So
we'll
basically
look
at
the
main
components,
and
then
we
look
at
futures
and
then
I'll
talk
a
bit
about
how
specifications
evolve
in
jakarta
working
group
and
how
you
know
as
an
individual,
you
can
get
involved
and
help
shape
shape
this
api,
okay,
so
first
kicking
that
off
is
is
basically.
Why
do
we
need
jakarta
concurrency?
So
we
look
at
what
it
is
and
some
of
the
key
use
cases
so
jakarta
concurrency
came
in
in
java
ee7.
B
So
obviously
it's
part
of
java,
ee
and
j2e
before
that,
it's
a
it's
a
obviously
jakarta.
Ej2E
java
ee
has
been
around
for
20
odd
years.
It's
got
a
lot
of
longevity
due
to
the
stability
and
the
use
cases
that
it
solves
for
developers
when
building
enterprise
applications
jakarta
con
currency
came
in
in
e7.
There
wasn't
any
changes
to
it
in
e8
and
then
you
know.
Since
java
e8
we've
been
moving
into
transition
to
the
eclipse
foundation
from
from
the
jcp.
B
The
first
release
at
the
eclipse
foundation
was
jakarta
eea
in
september
2019
and
from
a
jakarta
concurrency
perspective.
That
was
exactly
the
same
as
java
e8.
The
goal
for
jakarta
ee8
was
to
release
all
the
jakart
jakarta
specifications
that
were
equivalent
to
their
java
ee
ones,
using
the
eclipse
foundation
process,
key
reason
being
that
we
could
release
them
under
different
a
different
license.
B
The
next
stage
of
transitioning
java
ee
over
to
the
eclipse
foundation
was
the
move
to
and
release
of,
jakarta
ee9.
This
was
obviously
completed
december
last
year
and
what
this
did
is
it
moved
everything
to
the
new
jakarta,
namespace
away
from
the
javax
namespace,
the
javax,
being
a
copyright
of
oracle.
The
new
namespace
was
required.
B
You
know
to
release
these
apis
from
the
eclipse
foundation
and
similarly,
for
that,
as
part
of
that
jakarta,
concurrency
was
migrated
from
javx
to
the
jakarta
namespace
and
that
was
then
completed
on
december
2020
and
then
pretty
recently
this
year
may
2021
jakarta.
9.1
was
released
and
this
effectively
is
like
a
minor
update
to
bring
all
the
test
suites
and
everything
up
to
jdk11,
to
provide
effectively
provide
compatibility
with
gkdk11
in
the
sense
that
you
could
run
the
tck
and
prove
your
product
with
jakarta,
e9
compatible
on
jdk11.
B
The
reason
I'm
sort
of
saying
that
is
really
to
set
the
context
that
once
we've
done
this
transition,
which
we
did
completed
in
may
2021
we're
now
in
the
point
where
we
will
need
to
evolve
and
basically
innovate
and
move
forward.
These
specifications
like
jakarta,
concurrency
that'll,
be
going
looking
forward
into
ee10.
B
And
so
in
this
talk
I'll
really
cover
some
of
the
ideas
that
we
have
for
ee10
and
and
take
me
through
those
so
jakarta
from
currency,
as
I
said,
was
introduced
in
java
e7.
It
was
originally
called
jsr236,
concurrency
utilities
for
java
ee
and
if
you
want
to
use
it
directly,
this
guy
had
new
maven
coordinates
from
the
jcp
coordinates,
so
they've
obviously
moved
to
jakarta
and
for
jakarta
8,
which
is
still
in
the
javax
namespace,
it's
version
1.1.2
and
for
jakarta
9,
it's
version
2.0.
B
B
What
you
do
is
you
provide
your
application,
which
is
written
to
the
jakarta
ee
apis,
which
is
that
jigsaw
on
the
top
there,
and
then
you
take
that
application
and
you
deploy
it
to
a
jakarta
application
server
and
what
the
jakarta
application
server
or
runtime
is
doing
for
you
is.
It
provides
a
lot
of
services,
so
it
obviously
provides
threads,
so
thread
management
for
you
you,
it
manages
that
you
know
pooling
of
threads
executing
threads
based
on
http
requests
and
other
resource
management
around
threads.
B
It
also
provides
security.
So
you
know
you
can
just
declaratively
say
that
you
require
a
role
or
you
you
know
to
some
use
it
to
be
in
a
role
to
execute
a
specific
egb
call
or
something
like
that,
and
the
application
server
runtime
provides
that
for
you
in
all
the
security
checks.
Again,
it
also
provides
not
shown
here,
provides
cluster
loading
and
application
isolation.
If
you
deploy
multiple
applications-
and
it
also,
it
provides
you
logging
access
to
messaging
mit
metrics,
all
the
network
handling.
B
B
For
example,
as
I
mentioned
the
security,
so
it
struggles,
you
know
you
wouldn't
be
able
to
establish
a
security
context
on
that
newly
created
thread,
class
loader
context,
or
you
know,
if
you
were
in
cdi
other
contexts
like
that.
So
there's
a
whole
bunch
of
context,
information
that
application
servers
maintain
for
you
that
allows
you,
as
an
application
developer
to
quite
basically
concentrate
on
the
business
logic
and
not
worry
too
much
about
the
cross-cutting
concerns
like
security
and
essentially
jakarta
concurrency
as
we'll
see
solves
that
problem.
B
So
so
you
can
see
how
currently
you
can.
What
you
can
do
in
jakarta,
concurrency,
so
very
typical
use
case
is
basically
to
add
an
asynchronous
break
in
your
application
and
if
you've
got
old
applications
that
were
built.
Maybe
before
java
e7
on
before
jakarta,
concurrency
came
along
or
applications
that
were
built
where
people
were
totally
unaware
that
jakarta
concurrency
existed.
B
So
I
used
many
years
ago.
I
was
a
consultant
in
the
field
and
I
used
to
see
this
sort
of
this.
This
pattern
used
a
lot.
So,
for
example,
imagine
you
have
an
http
request.
It's
coming
into
a
servlet
or
a
rest
endpoint,
or
something
like
that
in
an
older
application,
and
you
wanted
to
kick
off
a
long-running
action.
You
know.
B
B
Typically
people
would
then
what
they
would
do.
Is
they
package
up
the
details
of
the
request?
Push
it
onto
a
jms
queue,
then
building
it
and
message
driven
bean.
That
would
take
the
data
for
the
request
process,
whatever
it
needed
to
do,
and
then
you
know
return
to
something,
either
store
something
and
it
results
in
a
database
for
a
for
a
later
request,
or
something
like
that.
So
you
see
this
a
lot
in
many
java
e
applications
and
some
applications
I
saw
in
the
past.
B
B
B
Your
long-running
action,
which
replaces
your
mdb
and
that
would
run
on
a
executive
service
thread,
but
the
key
difference
using
jakarta,
concurrency
api
rather
than
java
se,
is
that
that
thread
will
be
managed
by
the
jakarta
runtime
and
therefore
they'll
have
the
ability
to
apply
the
same
context
that
you
had
and
the
rest
request.
So
the
same
users.
You
know
the
same
class
loader
all
the
same
context,
to
use
all
the
jakarta,
ee
injection,
etc
within
that
action,
something
which
it
wouldn't
be
possible
with
java
se.
B
B
We
got
a
get
on
here
and
basically,
what
you?
What
you
do?
Is
you
inject
your
managed
executive
service
which
has
the
same
api
as
the
java?
Se
managed
executor,
sorry
same
the
javascript
executive
service
and
you
would
submit
a
runnable
to
that
and
you
can
obviously
use
a
lambda
as
I'm
doing
in
this
example,
and
that
would
basically
submit
it
into
the
executive
service
thread.
Pool
one
of
the
threads
would
pick
it
up.
B
So
another
typical
use
case
would
be
if
you
wanted
to
run
tasks
in
parallel
now
before
jakarta,
concurrency
in
in
java
e.
This
would
be
really
quite
tricky
thing
to
do,
but
with
jakarta
concurrency,
it's
quite
simple,
because
it's
follows
the
standard
java,
sc
primitives,
so
you've
got
a
rest
request
coming
in.
B
You
basically
want
to
run
two
tasks
in
parallel
and
then
maybe
merge
the
results
and
return
them
to
a
user.
So
you
can
run.
You
know,
maybe
gathered
information
from
different
remote
services.
For
example,
you
maybe
you
need
to
make
external
rest
requests,
correlate
collate
the
results
and
return
them
back
to
the
user.
B
If
you
did
that
with
jms,
that
would
be
incredibly
difficult
to
do
as
you
would
need
to
create
correlation
ids
to
send
messages
over
and
out
return,
then
listen
on
another
queue,
return
the
results
and
then
correlate
it
with
the
correlation
id
and
do
the
same
for
the
second
request
and
merge
them
back
together
by
listening
on
a
correlation
id.
So
that
would
be
extremely
advanced.
B
So
these
sort
of
things
typically
don't
get
done
in
java
applications.
But
since
java
java
e7
then
we've
we've
had
a
concurrency
that
can
do
that.
So
it's
very
easy
to
submit
tasks
and
merge
them
back
together.
Again,
if
you
want
again,
as
I
said
earlier,
both
of
those
requests,
those
two
lambdas
will
be
running
in
the
context
of
the
application
server
and
the
and
the
originating
request.
This
rest
request
so
security
context.
Things
like
that
are
propagated
to
your
to
your
code,
so
you
can
use
all
the
carter
capabilities.
B
So,
for
example,
you
have
a
rest
request
comes
in
and
you
want
to
schedule
some
periodic
tasks.
Perhaps
you
know
it's
some
sort
of
polling
of
some
remote
service
or
it's
a
job
that
you
need
to
run
on
a
fixed
schedule
by
date
or
something
like
that
and
and
you
want
that
task
to
run
in
the
same
context
as
the
request.
That's
that
basically
created
cr.
We
created
the
task
because
jakarta
concurrency
effectively
creates
a
managed
version
of
a
standard
java
scheduled
executive
service.
B
You
can
use
the
same
api
as
you
would
use
javasc
and
submit
and
create
periodic
tasks
or
basic
runnables
that
can
run
on
whatever
period
you
wish.
So
again,
you
could
start
that
deployment
time
if
you
needed
to
and
those
tasks
again
would
run
in
the
same
context,
same
class
loader
as
the
as
the
task
that
created
them.
B
B
B
So
basically,
the
first
piece
of
it
is
managed
executive
services.
So
what
these
are?
These
are
basically
analogous
components
that
map
across
to
their
java
se
equivalents.
So
in
java
sc
for
threads,
we
have
executive
servers.
We
have
scheduled
executive
service
in
jakarta
concurrency.
We
have
two
analysis
services,
one
called
managed
executive
service
and
one
called
managed
schedules
executive
service,
and
these
have
the
same
api
as
their
underlying
sc
versions.
B
You
can
also
create
additional
ones.
So
if
you
needed
to
sort
of
do
more
fine-grained
thread
handling
within
your
application,
you
run
different
tasks
on
different
pools.
Then
you
can
actually
create
additional
instances
currently
with
jakarta
concurrency.
The
only
way
to
do
that,
though,
at
the
moment
is
you
have
to
do
them
through
your
applications.
Administration
consoles
there's
no
standard
ways
to
deploy
different
configured,
executive
services
and
I'll
talk
a
little
bit
about
that
in
the
futures
section.
B
The
other
thing
you
can
add
on
to
a
scheduled
executive
service
is
something
called
the
trigger
interface
again.
What
this
is
is
the
basically
the
executive
service
calls.
This
calls
back
to
this
trigger
interface,
to
request
whether
it
can
run
the
job
or
the
task,
and
this
allows
you
to
create
programmatic
timers.
In
other
words,
so
you
could
write
business
logic
as
to
when
and
whether
a
timer
should
fire
or
a
scheduled
task
should
be.
You
know
executed.
B
B
B
So,
for
example,
we
have
a
analogous
component
last
analogous
to
a
thread
factory
in
java,
se
called
a
managed
thread
factory,
and
this
can
be
used
when
you
know
you
have
an
api
or
you
have
some
code
that
creates
its
own
executives
or
something
like
that,
but
has
no
knowledge
of
jakarta
ee,
so
it's
possible
that
you
can
pass
in
a
thread
factory.
For
example,
if
the
api
gave
you
access
through
your
java
sc
thread
factory,
then
you
could
pass
in
the
manage
management
factory.
B
So,
example,
in
this
code
ignore
the
rest
parts
of
it,
but
you
can
see
the
call
executives.new,
fixed
red
pool
to
comma
passing
and
manage
thread
factory.
That's
the
standard
java.
Se
api
so
managed
thread.
Factory
basically
gives
you
a
hook
to
call
into
apis
that
are
not
aware
of
jakarta
concurrency,
but
do
take
a
thread
factory
as
a
parameter
and
what
the
manage
thread
factory
does
is.
B
B
B
Another
sorry
I'll
just
go
back
to
this
one
again.
The
other
thing
to
note
is
that
you
do
get
a
default
managed
thread
factory,
so
you
can
just
inject
it
as
a
resource
there's
an
even
lower
level
component,
which
you
can
use
again
for
application
frameworks
or
libraries
that
aren't
aware
of
chicago
spawning
threads,
and
this
is
called
the
context
service.
B
B
You
create
yourself
a
runnable,
so
there's
a
runnable
here
and
then
what
you
can
do
is
using
that
context
service.
You
can
create
a
contextual
proxy.
So
what
that
does
it
will
create
a
proxy
to
it
to
any
runnable,
and
then
you
can
submit
that
proxy
onto
any
raw
thread.
So
not
so
if
the
api
was
basically
just
gonna
take
a
runnable,
then
you
can
submit
your
contextual
proxy
to
that
api.
B
B
B
B
B
So
the
first
one
is
deployable,
managed
objects
and,
as
I
mentioned
by
default,
the
current
concurrency
specification
says
you
will
have
a
default
managed
executor.
A
default
managed
scheduled
executor,
a
default
contact
service
and
a
default
thread
factory
to
create
additional
ones
configured
differently.
You
would
need
to
use
the
tools
of
your
application
server.
B
For
example,
in
payara
you
go
to
the
administration
console,
you
can
set
up
a
different
managed
executive
service
and
you
can
give
it
different
thread,
pool
settings
and
you
can
give
it
a
gndi
name
which
indie
name
so
moving
forward
into
the
sort
of
patterns
of
how
you
would
do
this
to
make
it
aligned
with
other
things
that
you
can
do
in
chicago
ee.
Eight
and
nine
is
you
know
we
have
deployable
application
scope,
data
sources,
you
know
in
cartridge
nine.
B
B
For
example,
you
could
set
up
your
own
managed,
executive
definition,
something
like
this.
This
is
an
idea.
It's
not
set
in
stone.
You
would
set
up,
you
know
the
jmdi
name
for
it.
You
would
set
up
the
what
context
service
it
uses
and
maybe
the
size
of
your
thread
pools
minimum
concurrency.
You
know
min
threads
max
threads
and
this
what
this.
So?
What
this
will
allow
you
to
do
if
you've
got
an
application
that
really
needs
to
have
fine-grained
control
of
the
concurrency,
the
threading,
the
pooling
of
threads.
B
Maybe
you
have
jobs
that
need
to
be
on
one
thread
that
needs
to
be
separated
from
you
know,
things
on
from
different
thread
pools,
so
you've
got
one,
maybe
what
maybe
for
one
for
long
running
jobs,
one
for
very
fast,
then
you
would
allow
and
allow
you
as
developer
without
having
to
use
administration
consoles
to
set
these
up.
So
you
could
attach
this
annotation
to
your
component
and
then
use
that
and
inject
it
and
use
that
to
submit
jobs.
B
You
may
not
say
you
may
need
to
do
that
if
you,
if
you
need
to
make
sure
you're
preventing
deadlocks
or
live
locks
in
a
very
highly
tuned
system.
So
it's
one
of
the
things
we're
looking
at
another
idea
is
basically
a
new
schedule
annotation.
This
would
be
like
the
egb
timer
annotation,
but
you
could
use
it
for
other
components.
B
B
We
could
also
extend
that
maybe
into
look
at
some
persistence
like
the
confidence
you
can
in
egb
time
is.
You
can
have
persistent
egb
timers
and
we
could
also
look
at
if
whether
and
what
the
semantics
are
in
a
cluster,
for
example,
you
know
the
egb
timer
spec
says
that
the
timer
fires
only
on
one
node
in
the
cluster,
and
perhaps
we
could
look
at
specifying
different,
different
semantics
than
that,
or
have
that
as
one
of
the
rules
on
the
cluster.
B
B
Okay,
another
one
we're
thinking
about
is
an
async
annotation
that
is
generic.
So
currently
there
are
async
annotations
in
jakarta,
ee,
but
they're
quite
specific
to
each
individual
specification.
So,
for
example,
egb
has
its
own.
The
rest,
client
has
its
own.
Sorry
rest
rest,
chicago
rest
has
its
own.
Servlet
has
its
own,
and
perhaps
we
could
create
another
one
in
the
first
instance,
but
that
could
be
also
used
with
cdi
beans.
So,
for
example,
we
could
have
an
application
scope,
cdi
bean
using
async
or
asynchronous,
depending
on
what
we
decide
give
it.
B
So
you
could
choose
different
thread,
pools
for
different
methods
and
those
sort
of
levels
of
detail.
So
once
we
had
this
annotation,
then
we
could
do
quite
a
bit
of
work.
I
think
unlikely
to
happen
in
ee10,
but
in
later
on,
we
could
start
to
remove
some
of
the
asynchronous
annotations
from
other
parts
of
the
jakarta
platform
and
actually
try
and
concentrate
onto
a
single
annotation.
B
Maybe
you
know
provided
by
jakarta
concurrency,
which
would
then
be
common
to
all
the
specifications
that
they
would
all
build
on.
So
that
again
we
we've
sort
of
simplified
the
platform
and
make
it
a
little
bit
more
unified
and
again.
If
we,
if
we
did
that,
then
you'd
be
able
to
specify
the
thread
pool
for
an
egb,
async
method
or
a
servlet
one
or
a
you
know
a
rest
one
as
well.
So
that
would
bring
in
simplicity
to
the
platform.
B
Okay,
there's
a
whole
bunch
of
work.
We
need
to
do
around
catching
up
with
java
util
concurrent,
as
I
mentioned,
jakarta's
concurrency
was
released
in
java
e7,
so
it
hasn't
really
been
brought
up
to
date
to
match
a
lot
of
the
concurrency
primitives
that
came
in
in
java,
9
and
obviously
been
built
on
in
java,
11
and,
and
you
know,
with
in
java
17
that
will
be
coming
so
some
of
the
things
we
need
to
do
around
here.
B
B
B
For
those
that
don't
know,
microprofile
is
a
similar
initiative
within
the
eclipse
foundation
that
is
building
new
apis
on
top
of
chicago
apis,
specifically
for
microservices
type
architectures,
but
some
of
the
work
that
was
done
in
my
profile
around
context.
Propagation
was
sort
of
done
because
jakarta
concurrency
was
stalled
if
you
like,
as
it
was
moving
through
the
transition
period,.
B
So
this
api
has
already
done
microprofile
context.
Propagation
api
has
already
got
a
introduced
apis
to
completable
features
and
also
provided
apis
to
capture
contexts
and
run
that
into
completion
stages
as
well.
So
there's
a
whole
bunch
of
work
there
that
we
need
to
move
into
jakarta.
Concurrency
and
that'll
that'll
do
some
of
the
work
required
to
map
back
on
to
the
java
latest
javasc
apis.
B
So
some
of
the
things
I'd
like
to
do
to
make
to
make
jakarta
a
bit
more
consistent
for
people
a
bit
more
simple
is
some
platform
alignment,
so
the
first
one
is,
you
know,
makes
your
car
to
concurrency
work
well
with
cdi
and
some
of
the
things
we've
we've
sort
of
suggested,
like
asynchronous
annotations,
schedule,
annotations,
etc.
They
would
all
support
cdi,
mac,
profile.
Context,
propagation
has
done
quite
a
bit
of
work
on
this
as
well,
and
so
that's
an
obvious
thing.
Cdi
is
obviously
now
fundamental
to
jakarta.
B
Ee
and
the
problem
is,
it
came
in
you
know
quite
late,
so
some
specs
don't
really
integrate
with
it
at
that
point
in
time
and
that
needs
to
be
fixed
incorporate
into
the
web
profile.
I
think
in
the
last
couple
of
weeks
that's
been
agreed.
Web
profile
currently
doesn't
have
to
categorical
currency
in
it,
which
is
a
bit
crazy.
Given
it's
essentially
a
fundamental
thrilling
api
and
has
nothing
you
know,
there's
nothing
complicated
about
it,
so
so
that
one's
been
agreed
and
that's
moving
forward.
B
And
allow
you
know
the
asynchronous
annotation
on
ejps
to
specify
which
managed
executive
service
you
use
and
that's
same
again
with
servlets
and
jax
rs.
We
could
sort
of
jakarta
rest.
We
could
map
those
async
annotations
and
move
them
onto
jakarta,
concurrency
and
then
again,
we'd
also
quite
like
to
re-implement
the
whole
of
jakarta
enterprise,
egb
timers
onto
jakarta,
concurrency
and
and
then
it
would
also
support
not
just
ejbs
but
support
any
managed
component.
B
B
So
the
first
thing
is,
I
said:
ducati
concurrency
came
in
in
ee7,
so
it
was
targeting
java,
se7
and
therefore
currently
date
time
apis
aren't
in
there
and
obviously
it's
quite
a
simple
thing
to
do,
but
we
need
to
provide
apis.
That's
the
take
date
java,
the
se8
date
and
time
support,
especially
for
things
like
triggers
and
apis
that
specify
schedules.
Things
like
that,
I
mentioned
earlier,
there's
a
sort
of
trigger
class.
This
is
something
you
can
pass
to
a
scheduled
executor
along
with
your
task
and
what
basically
the
executive
does.
B
Is
it
calls
your
trigger
class
to
see
whether
the
task
should
run
and
what
we
could
do
is
provide
some
concrete
triggers,
so
one
example
would
be
like
a
cron
trigger
and
something
that
spring
has
for
their
equivalent
to
this
api
and
you'd
be
able
to
specify
you
know
a
cron
schedule
or
something
like
that
and
pass
it
into
the
scheduled
executive
service,
along
with
your
your
runable,
and
we
can
think
of
others
as
well.
But
quran
is
the
most
obvious
one.
B
We
need
to
standardize
some
of
the
configuration
attributes.
This
is
getting
really
into
the
detail,
something
like
thread
pool
size,
mint,
threads,
max
threads.
Things
like
that
would
need
to
be
done.
The
api
is
a
little
bit
abstract,
so
it
doesn't
necessarily
mean
they're
threads,
so
you'd
probably
call
it
max
concurrency
or
min
concurrency
or
something
in
case
you
wanted
to
do
that.
B
B
B
Unlike
the
jcp,
where
you
had
an
expert
group
and
an
expert
group
lead,
the
eclipse
foundation
is
slightly
different.
A
project
is
an
open
source
project
and
the
project
leads
their
job.
Is
there
to
basically
make
sure
that
project
follows
open
source
principles,
but
not
to
essentially
be
the
the
leader
or
the
guy
who
thinks
about
everything
that
needs
to
be
done,
so
I'm
guessing
you
can
do
a
little
plea
of
how
to
get
involved.
B
So
the
tck
is
a
technology
compatibility
kit,
and
that
is
the
test
suite.
That
proves
that,
in
the
independent
implementations
of
this
api
meet
the
requirements
of
the
api
and
implement
it
fully,
so
the
tck
would
run
against,
say
something
like
payara,
which
has
its
own
currency
implementation
built
into
it,
and
what
the
tck
does
is
it
tests
that
piara
implements
all
that
api
correctly
and
in
accordance
with
both
the
spec
document
and
the
api
jar?
B
The
other
thing
you
do
need
to
have
which
isn't
on
the
slide
is
you
need
to
have
a
compatible
implementation
that
has
that
is
open
source,
well,
not
open,
source
freely
downloadable,
and
that
has
passed
the
tck
and
that's
really
just
a
gating
thing.
That
proves
that
your
api
that
you've
created
is
actually
implementable
by
somebody,
so
it's
not
something
that
nobody
can
implement
and
pass
the
tests
for.
B
So
when
it
comes
to
this,
we
basically,
if
someone
wants
to
get
involved,
we
can
get.
You
know
you
can
get
involved
in
each
and
every
part
of
this.
So
if
you're
more
interested
in
test
suites
and
things
like
that,
you
could
help
build
or
you
know,
tests
or
may
help
maintain
the
tck
or
make
requests
to
that,
and
obviously
the
more
broader
and
the
more
test
cases
we
have.
B
It
can
obviously
help
directly
on
the
api
and
shaping
things
like
schedule,
or
you
know
any
things
I
mentioned,
and
that
again
is
absolutely
welcome
to
work
out.
You
know
what
would
you
want
as
a
developer?
What
capabilities
would
you
want
in
jakarta,
concurrency
and
then
there's
also
help
needed
around
the
specification
document,
and
that
could
be
just
as
much
as
you
know.
Submitting
prs
to
for
typos
or
anything
like
that,
and
if
it's
anything
it's
welcome.
B
So
these
are
the
main
links
of
how
you
get
involved,
so
the
eclipse
project
there.
So
we
are
an
eclipse
project.
We
have
a
mailing
list
that
you
can
use.
If
you
only
talk
to
the
development
team,
but
I
mean
the
development
team.
Has
anybody,
so
anybody
who
subscribes
to
that
can
can
email
onto
that
list.
B
All
the
code
is
on
github.
The
whole
project
is
run
on
github
every
one
of
those
features
requests
that
I
talked
about
their
issues
on
github
and
we
can
discuss
them
on
just
by
using
github
issues
and
then
the
api
changes
would
result
in
a
pr
and
again
we
can
discuss
it
on
a
pr
before
it
gets
merged
into
the
api
code.
B
It's
it's
a
slightly
different
project,
but
essentially
it
is
an
implementation
of
the
concurrency
api
and
it's
used
in
glassfish
and
piara
and
it
may
be
using
others
as
well,
but
so
you
can
also
you
know,
as
I
mentioned
earlier,
to
get
a
specification
released.
Then
we
need
an
implementation
of
the
specification
that
can
pass
the
tck,
and
currently
this
is
the
one
that
we
use
and
that's
on
there
as
well
codes
on
github
and
anyone
can
get
involved
with
that.
B
B
I
know
it
can
often
seem
quite
scary
to
get
involved
in
something
like
this
and
try
and
shape
the
industry,
but
we
are
really
asking
for
people
to
get
involved
and
help.
So
if
you
do
have
any
desire
to
do
that,
then
you
know
either
just
comment
straight
on
github
or
you
can
reach
out
to
me
and
I'm
always
happy
to
to
introduce
people
and
bring
them
in.
B
I
know
when
I
first
ever
joined
an
expert
group
at
jcp.
It
can
seem
a
quick
a
bit
daunting,
that
the
people
are
mega
brains
and
may
not
want
your
input,
but
that's
absolutely
not
the
case,
especially
I'm
not
a
big
magic
brain.
So
if
you
want
to
get
involved,
please
do
and
that's
it.
Thank
you
very
much
and
any
questions.
A
Okay,
so
it
looks
like
we
have
one
question
here:
could
you
please
tell
us
more
about
the
current
integration
of
concurrency
with
cdi
and
ejbs,
I've
used
them
as
tasks,
but
I
always
found
it
difficult
to
manage
them
due
to
their
life
cycles.
Is
this
what
you
mean
by
further
the
integration
with
cvi
in
jakarta,
10
plus.
B
Yeah
I
mean
cdi
because
it
came
after
or
around
the
same
I
can't
remember
the
exact
timeline
or
so
or
a
similar
time
as
chicago
concurrency.
The
two
don't
necessarily
have
any
integration
other
than
the
context
can
set
up
some
things
to
do
that.
What
we're
looking
at
when
us,
when
we're
talking
about
deeper
integration,
is
trying
to
solve
those
problems,
really
look
at
in
much
more
detail
and
provide
concurrency
primitives
to
cdi,
which
don't
currently
exist
and
and
microprofile
context.
B
A
A
So
if
you're
interested
in
presenting,
we
have
the
sign
up
sheet
here
in
the
chat.
And
finally,
if
you
have
any
feedback
on
the
jakarta
tech
talks,
we
would
love
to
hear
it
from
you.
So
I'll
just
put
it
there's
a
green
button
at
the
bottom.
So
if
you
could
fill
that
out,
that'd
be
super
helpful
and
I'll
just
check
and
see.
I
think
we
have
one
more
question
here.
B
I
think
it's
anything
really.
If
you
want
to
get
involved,
I
would
say
everybody
is
looking
for
people
to
get
involved
at
all
levels
if
it's
development
yeah
absolutely
get
involved.
If
you
have
strong
views
of
how
jakarta
he
should
develop
and
evolve
as
a
developer
and
jakarta
developer
absolutely,
but
it's
not
just
that.
I
mean
the
whole
eclipse
foundation.
Working
group
is
looking
for
help
for
promotion
for
talks,
protect
the
tech
talks.
If
it
doesn't
have
to
be
just
project
leads,
I
do
tech
talks.