►
Description
Ryan Cuprak Presents:
Jakarta EE is now over 20 years old and despite its age, it is as relevant today as it was back in 1999. It is one of the few open standards for developing enterprise applications with multiple independent vendor implementations. Its APIs are central to developing Java based cloud solutions. It is as relevant today as it was back in 1999. This presentation will provide context to Jakarta EE and why businesses choose to use it.
Get Social!
Website: jakarta.ee
Subscribe: https://www.youtube.com/user/EclipseF...
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
Want more great Eclipse Community webinars? Become a member of our Jakarta Tech Talks Meetup: https://www.meetup.com/jakartatechtalks
A
Hey
hello,
everyone
I'd
like
to
welcome
you
to
today's
tech.
Talk
on
why
jakarta
ee
matters,
I'm
ryan,
cooperack,
president
of
the
jakarta
e
ambassadors.
You
can
find
me
on
twitter
at
several
different
places.
I
also
run
the
connecticut
java
users
group
a
little
background
on
me.
As
I
mentioned,
I
work
in
charge
of
the
jacardi
ambassadors.
I
work
for
daso
systems
on
chemical
formulation,
software.
I
run
the
connecticut
java
users
group
and
I'm
also
author
of
a
co-author
on
ejb3
in
action
second
edition,
and
also
the
netbean
certification
guide
my
day
job.
A
It
adventure
mode,
so
today's
presentation
I'm
going
to
go
over.
Basically,
why
jakarta
matters
for
those
of
you
who
might
be
new
to
cardi
e
or
joining
this
for
the
first
time?
Jacardi
is
a
community
and
vendor
driven
open
standard.
It
was
originally
named,
javi
or
j2e
and
you'll
commonly
see
that
on
job
postings
etc.
So
you'll
see
you
know
given
its
long
history
that
referred
to
as
either
javi
or
j2ee,
and
you
often
need
both
of
those
on
a
resume
in
order
to
get
picked
up
by
the
resume
systems.
A
Nowadays,
it
transitioned
from
oracle
to
the
eclipse
foundation
in
2018
originally
was
developed
by
sun
microsystems.
It
is
composed
of
multiple
specifications
covering
messaging
web
services,
security,
websockets,
jsps,
object,
relational
mapping,
mail
distributed
transactions,
etc.
It
actually
covers
numerous
things
and,
although
many
developers
think
of
as
monolithic,
it
is
actually
multiple
multiple
specifications
underneath
the
hood
that
you
can
use
independently
I'll
kind
of
cover
that,
as
I
go
through
the
presentation,
there
are
multiple
open
source
and
commercial
implementations
of
it.
Specifications
include
a
compatibility
test
for
verifying
conformance.
A
So
when
you're
using
the
different
implementations,
you
could
there's.
Actually,
they
actually
have
to
pass
a
test
at
verifying
their
conformance
with
the
specifications,
and
you
know,
as
as
I
mentioned,
the
implication
implementations
must
support.
The
tc
must
pass
the
tck
jacardi
has
a
long
history.
It
was
first
released
in
1999.
A
Rewrite
every
day
many
developers
out
there
don't
know
many
java
developers
out
there
don't
necessarily
consider
themselves
jacardi
ee,
because
they
only
use
a
small
portion
of
the
specification.
So
you
might
you'll
see
on
resumes
somebody's,
an
expert
in
hibernate
or
servlets
or
web
services
or
messaging.
Those
are
actually
all
jacardi
technologies
and
there's
no
requirement
that
you
use
all.
You
know
that
your
application
uses
all
of
the
technologies.
A
A
It
jacardi
e
has
evolved
over
the
years,
so
it
started
as
jpe
jpe
way
back
in
1999
and
continued
to
evolve.
First
with
serverlets-
and
you
know,
container
managed
means
the
real
inflection
point
came
around
2005
with
java
e5,
which
which
leveraged
annotations
and
has
considered
continued
to
evolve
further.
So
back
at
the
when
jakarta
eve
or
java
e
first
came
out,
soap
and
web
services
were
big
today,
we're
seeing
things
like
http,
2,
json,
web
sockets,
etc.
A
A
A
25
years
old
and
some
of
the
technologies
out
there
like
that,
like
c,
which
are
used
for
develop,
which
are
heavily,
are
still
heavily
used,
are
almost
50
years
old,
so
jacardi
is
relatively
young
compared
to
many
of
the
other
technologies
out
there
I
mean,
for
example,
python,
which
is
which
has
garnered
a
lot
of
interest.
The
last
couple
of
years
is
over
30
years
old.
Now
is
so
terrible,
not
as
old
as
some
of
the
other
technologies
that
are
out
there,
but
it
does
have
a
pretty
long
track
record
jakarta.
A
So
it
covers
the
gamut
of
practically
anything.
An
enterprise
application
would
need
to
do
some
of
the
more
recent
evolution
of
jacardi
has
included.
You
know:
support
for
for
json,
for
example,
a
json
pointer,
which
added
support
for
patching
and
merging
streaming
api
for
processing,
large
json
files,
etc
kind
of
more
example,
code
here,
where
it's
working
with
jsonpointer
for
pulling
data
out
of
it
out
of
a
out
of
a
json
file.
A
Also
jason
patch,
which
allows
you
to
modify
parts
of
a
json
document
and
make
changes
to
it
more
information
down
below
on
what
it
patches
with
with
verbs
and
as
we
can
see
right
here,
some
example
code
just
making
changes
to
that.
These
are
some
of
the
more
more
recent
things
that
have
been
added
to
jacardi,
enabling
you
to
work
with.
You
know,
json
coming
from
the
javascript
world
and
work
with
front-end
javascript
applications,
so
it
provides.
A
These
are
standard
apis
that
are
available
in
multiple
containers
and
you
can
use
independently
for
just
running
a
java
se
application
for
working
with
json
today.
So
it's
you
know,
it
started
out
way
back
in
2000s
with
a
focus
on
xml
and
has
continued
to
evolve
and
adapt
and
add
support
for
js
standardized
json
apis.
A
This
is
an
example
here
of
using
bean
validation,
key
feature
of
it,
allowing
you
to
validate
data
so
that
we
can,
just
you
know,
assert
that
if
we
have
a
list
of
email
addresses
that
they're
actually
valid
addresses,
you
know
basically
and
and
these
annotations
that
are
going
on
the
methods
here.
These
are
standard
annotations
from
jacardi
e
for
validating
data,
so
these
can
be
used
for
validating
data,
that's
coming
from
json
from
coming
from
web
services
from
coming
from
a
database.
A
Json
for
pojos,
et
cetera
kind
of
going
to
the
power
of
jakarta
is
that
you
know
you
can
be
a
a
standard
java,
regular
java
developer,
using
json
b,
which
comes
from
jacardi
in
order
to
get
you
know
to
to
work
with
json
data,
some
json
mapping
example:
okay,
so
there's
too
many
specifications
to
cover,
but
it
provides
a
lot
of
the
core
technologies
that
java
developers
use
every
day
for
getting
their
job
done.
If
it's
working
with
json
data,
if
it's
working
with
databases,
validating
data
jacardi,
has
a
specification
and
implementation
to
help.
A
You
address
those
business
names.
So
what
is
a
jaccard
ee
application?
I
think
there's
a
lot
of
confusion
about
this,
so
many
developers,
especially
developers
that
have
been
at
cardi
e
space,
a
long
time
think
of
monolithic
applications.
First,
those
are
applications
that
are
running
in
the
container
might
be
multiple
applications
running
in
a
container
but
they're
monolithic,
they're,
not
microservices,
architect,
are
like
microservices
application.
A
There
are
also
cloud
applications,
so
applications
that
might
that
you
know
that
are
running,
maybe
as
aws
lambda
or
you
know
some.
You
know
lightweight
application
up
there.
In
the
cloud
running
inside
of
tomcat,
you
know
providing
a
set
of
microservices
et
cetera.
Those
are
also
jacardi
applications
command
line
applications.
As
I
mentioned,
you
can
use
the
specifications
to
to
write
command
lines
as
well
as
desktop
applications.
I've
used
jpa
and
cdi
to
to
put
together
small
desktop
applications,
and
so
that's
that's.
A
A
So,
if
you're
writing
something
for
like
aws
lambda,
you
could
use
a
couple
of
jakarta
ee
technologies
for
processing
json
for
pulling
data
from
a
database,
and
there
you
go.
That's
still
you're
still
using
security
technologies,
so
jacardi
application
can
be
hosted
in
application.
Containers
such
as
jboss
wildfly,
you
know,
etc.
It
could
be
hosted
in
a
web
container
such
as
tomcat
jetty,
java
java
sc
application
using
cdi
context,
dependency
injection
with
jpa
for
retrieving
data
from
a
database
with
beam
validation
and
a
desktop
application,
or
even
a
microservice
application.
A
A
Application
containers
range
from
paera
micro,
which
is
a
single
jar
file
which
basically
kind
of
think
of
it
as
a
full,
jakarta
ee
application
container.
Something
like
you
know,
a
full
full
container
in
a
single
jar
file,
and
you
just
pass
it
in
do
java.
Dash
jar
run,
run
it
and
give
it
your
war
file
and
your
application
is
up
and
running
or
weblogic
websphere,
which
are
complex
application
servers.
A
A
If
you
are
implementing
restful
service,
calls
you're
going
to
use
jack's
rs
to
implement
the
service
of
which
you
know
you're,
either
going
to
use
apache
cxf
wrestling
jersey,
et
cetera,
and
these
are
all
implementations
of
jakarta
ee
and
they
have.
They
have
additional
features
beyond
what
the
specifications
provide.
So
the
specifications
define
the
required
features
and
then
the
implementations
can
add.
Additional
features
have
different
performance
characteristics
allowing
you
to
pick
whichever
one
you
you
know,
based
upon
cost
and
feature
set
that
you
would
like
to
use
card
e
specifications.
A
There's
specifications
for
sending
mail
for
validating
data
pass
for
web
service,
as
we
saw
before
bean
validation,
doing
dependency
injection
two
primary
implementations
of
that
are
the
weld
and
apache
open
web
beams
and
all
of
these
specifications
can
be
used
standalone.
So,
for
example,
you
can
use
jax
rs
as
standalone
to
implement
web
services.
You
can
use
the
java
mail
api
to
you
know,
implement
a
desktop
mail
application
if
you
so
choose
so
that
all
the
specifications
can
be
used
outside
of
the
container.
A
A
A
If
you
go
to
the
specifications,
then
you're
not
locked
into
a
particular
vendor,
so
you
can
easily
switch
implementations
of
a
standard.
If
you
just
code
to
the
specification
and
coding
to
the
specification,
gives
you
you
know
a
baseline
of
how
to
use
you
know
the
different
implementations
so
for
web
services.
A
If
you
are
familiar
with
jax
rs,
switching
between
restlet
and
apache
cfx
cxf
is
not
that
hard
because
they
basically
work
the
same.
You
use
the
same
annotations
between
the
two
of
them.
It
allows
you
to
easily
transition
between
between
different
implementations,
java
ee
transitioned
from
the
jcp
to
the
eclipse
foundation
as
jakarta
ee.
So
originally
it
was
a
java
yi
and
has
been
since
now
renamed
as
jakarta
ee.
It
has
an
open
governance
and
open
source,
has
open
governance,
it's
open
source
and
has
open
compatibility
tests.
A
So
if
you
are
a
cardi
developer,
you're
using
hibernate
or
you're
using
spring
batch,
or
something
like
that,
you
can
get
involved
with
your
cardi
and
drive
it
forward.
Unlike
other
technology
stacks
that
are
proprietary,
jaccardi
enables
the
end
users
of
the
technology
to
actually
get
involved
and
push
it
forward.
So,
if
you
know
there's
no,
you
know
I've
heard
developers
in
the
past
that
my
job
users
will
say
you
know.
A
Why
did
sun
do
this,
or
why
did
oracle
do
this
when
in
fact
they
can
actually
get
involved
and
make
the
changes
themselves
if
they
want
to
see
a
specific
feature
go
in
a
specific
direction?
It
is
easy
to
get
involved
with
jaccardi
and
pushing
it
forward,
and
it's
actually
surprising
how
few
people
actually
get
you
know
given
the
the
size
of
the
ecosystem
and
how
many
people
depend
upon
it,
how
few
people
are
actually
participating,
sometimes
so,
with
that
being
said,
main
page
for
jakarta
ee.
A
Jakarta
e
and
open
source
chicago
specifications
and
compatibility
tester
open
source.
As
I
mentioned,
you
code
against
the
apis,
not
the
implementations,
and
you
only
use
something
specific
for
the
implementation,
if
you're
after
a
specific
feature
for
that
implementation
right.
So
if
you're
using
pierre-
and
you
want,
you
know
to
use
some
additional
feature
that
they've
added
you,
then
you
know
depend
upon
that.
But
you,
your
baseline
code,
is
depending
against
the
interface
for
jacardi,
enabling
you
to
easily
transition
to
other
implementations
or
use
code
that
was
written
for
other
implementations.
A
A
So
all
the
what
you're
guaranteed
is
that
they
all
implement
the
standards,
and
then
you
get
to
pick
which,
which
one
you
want
which
one
you
want
to
use,
depending
upon
the
crate.
Depending
upon
your
criteria,
a
development
is
controlled
via
the
jakarta
e
specification
process,
is
vendor
neutral
and
has
a
level
playing
field
for
all
participants.
It's
got
policies
governing
ip
flow
and
ownership
around
it,
and
the
goal
with
jakarta
ee
is
really
to
maintain
continuity
and
backwards.
Compatibility.
A
You
know
in
that
direction
or
multiple
people
are
using
that,
and
it's
got
a
20
currently
got
a
20
year
plus
track
record
of
releases,
which
is
pretty
good
for
technologies,
because
many
technologies
don't
necessarily
especially
last
that
long
and,
as
I
mentioned
earlier
in
the
presentation,
an
application
written
back
in
2002,
you
can
still
run
on
a
container
today
and
it's
got
a
large,
diverse
ecosystem
built
on
top
of
it.
So
this
is
a
slide
that
I
threw,
together
with
some
of
the
different
implementations
of
specifications
and
containers
etc.
A
So
all
of
these
are
implementations
of
standards.
Implementations
of
the
standards
that
you
can
leverage
some
of
them
like
are
killian,
are
used
for
testing
applications,
so
there's
a
complete
end
to
end
it's.
A
huge,
jakarta
e
is
a
huge
ecosystem
and,
as
I
mentioned
earlier
in
the
presentation,
practically
every
java
developer
out
there
uses
something
that
is
derived
or
comes
from
jacardi
either
one
of
the
specif,
an
implementation
of
one
of
the
specifications,
if
not
a
container
itself,
and
for
many
developers
this
comes
as
a
surprise.
A
A
So
jakarta
e
is
critical
to
the
java
ecosystem
and
to
the
cloud
currently
25
to
35
percent
of
java
applications
run
on
jakarta
e
application
servers,
those
being
like
web
logic,
web
server,
liberty,
pair,
etc
and
70
to
80
percent
of
java
applications
depend
on
at
least
one
or
more
jacardi
apis
and
below.
We
can
kind
of
see
a
breakdown
of
of
the
different
different
server
side
technologies,
spring
jacardi
e
and
the
percentage
within
the
community,
and
all
of
these
depend
upon
some
on
on
different
jakarta
e
specifications.
A
The
data
for
this
came
from
jacardi
e
developer
survey
back
last
year,
jakarta
e
versions
and
productions
so
for
applications
that
are
deploying
to
an
application
of
jakarta
ee
application.
Con
server,
the
bulk
of
them
at
least
as
of
last
year,
we're
still
in
jakarta,
ee
or
java
ee7,
with
slightly
more
than
a
third
on
java.
A
Ee8
and
many
of
these
are
large
applications,
so
they
take
a
little
bit
longer
to
port
and
I
suspect
some
of
the
transition
issues
that
people
are
dealing
with
are
more
of
the
java
8
to
11
issues
that
have
been
slowing
things
down
recently
in
terms
of
cardi
e
specification
usage,
79
percent
of
developers
out
there
use
jpa
cdi
jax
rrs,
so
you
can
kind
of
see
a
breakdown
of
you
know
many
applications
used.
You
know
because
these
don't
add
up
to
100
use
multiple
multiple
specifications
for
implementing
the.
A
B
A
It
is
an
open
source
set
of
specifications
and
it
originally
started
as
a
push
to
push
java
ee
innovation
forward.
So
there
was
a
time
when
oracle
was
kind
of
evaluating
their
future
and
kind
of
getting
walloped
by
not
transitioning
the
cloud
faster
and
they
lost
a
little
bit
of
focus
on
java
ee
at
the
time
and
so
micro
profile
was
an
effort
to
to
push
to
try
to
push
it
forward,
because
it
is
such
a
valuable
and
important
piece
of
every
java
java,
developer's
toolkit,
so
there's
multiple
implementations
of
micro
profile.
A
Micro
profile,
does
use
a
baseline
subset
of
jacardi
e
technologies
that
being
cdi
jax
rs
and
a
couple
of
others.
The
current
release.
As
of
last
check
was
four
now
jacardi
micro
profile.
There's
been
some
confusion
as
a
relationship
between
the
two
of
them.
They
are
two
independent
eclipse
projects
microprofile,
unlike
jacardi
e,
that
the
standards
the
individual
specifications
aren't
necessarily
standalone,
so
you
can't
use
them
outside
of
a
micro
profile
implementation,
not
all
jaccardi
containers
support
micro
profile.
A
And
not
all
microprofile
implementations
support,
jakarta
ee
or
the
full
set
of
jakarta
ee
will
jacardi
and
micro
profile
merge.
Probably
not
it
doesn't
look
like
so
at
this
point
there
were
like
release
cycles
between
the
two
of
them
microprofile
releases
four
times
a
year
or
quarterly,
or
that's
been
the
goal
and
carte
the
the
goal
is
hopefully
at
least
once
per
year.
A
Jacardi,
of
course,
is,
will
evolve
a
little
bit
slowly.
Micro
profile
has
more
of
the
get
stuff
out
there
fast
and
see
what
succeeds
or
fails,
whereas
jacardi
is
more
focused
on
standardization.
Once
something
is
adopted
into
jakarta,
it's
going
to
be
there
for
a
long
time.
Can
jacardi
apps
use
microprofile
apis?
Yes,
do
microprofile
apis
require
microservice
architecture.
A
No,
so
if
you
are
developing
a
monolithic
application-
and
you
want
to
use
some
micro
profile
features,
it
doesn't
mean
that
you
have
to
rewrite
your
application
as
a
micro
service
in
order
to
leverage
them
so
the
benefits
of
micro
profile
are.
It
gives
you
the
ability
for
doing
application.
Monitoring
standardized
configuration
standardized
configuration
the
config
api
right
now
is
actually
in
the
process
of
moving
over
to
jakarta
ee,
so
it's
being
standardized
into
the
standardized
integer
carte
and
will
be
used
by
jakarta
e
specifications
going
forward
for
standardizing
configuration
rest
documentation.
A
Some
of
the
other
micro
profile
features
are
fault,
tolerance,
scalability
service
tracing
and
security
with
jwt,
whichever
web
token.
So,
as
I
mentioned
microprofile,
the
current
release.
4-0
release
of
micro
profile
depends
upon
the
card
e
standard
cdi,
jsonp,
jax,
rs
and
also
json
before
for
binding,
json
back
and
forth
to
java
objects.
A
It's
very
easy
to
add
this
onto
an
additional
sorry
in
existing
jax,
rs
endpoint
to
add
documentation
to
it,
and
you
end
up
with
your
swagger
documents
automatically
generated.
You
can
also
provide
swagger
documents
that
will
serve
them
up.
Fault
tolerance
separates
execution
from
execution
logic,
so
this
once
again
is
tying
into
web
services.
You
don't
have
to
rewrite
your
application
as
a
microservice
to
take
advantage
of
that.
If
you
already
have
restful
endpoints,
you
can
add,
you
know
retry
logic,
etc.
A
A
Health
checks
provide
a
way
of
probing
an
application
to
find
out
how
it's
doing
so.
For
example,
you
know
if
you're
deploying
an
application
to
a
kubernetes
cluster,
and
you
want
to
have
have
it
monitor
for
use
this
for
determining
whether
the
application
is
up
or
down
et
cetera.
So
the
primary
target
for
health
checks
is
something
cloud
environments.
A
The
config
api,
which
recently
was
announced,
is
moving
over
to
cardi.
This
provides
config
standardized
configuration
for
applications
so
a
way
of
injecting
configurations
into
an
application.
So
you
can.
You
know
inject
from
this
example
over
here.
You
know
the
default
client
name
into
an
application
code
and
you
can
have
that
configuration
being
pulled
from
a
database,
a
properties
file
system
properties.
A
Microprofile
is
used
heavily
for
development
of
microservices
and
cloud
development,
as
I
mentioned,
and
also
most
chicago
e
containers
also
do
support
micro
profile
so
with
chicardi
e
and
careers
when
the
technology
dies.
So
can
your
career
and
I've
I've
seen
this
with
many
in
with
developers
that
they've,
you
know,
picked
a
given
technology,
they've
gone
head
over
heels
into
it,
and
then
the
vendor
says
oops.
You
know
we've
decided
to
go
in
a
different
direction
for
whatever
reason
where
they've
gone
out
of
business,
so
technologies,
you
use,
determine
your
career.
A
Often
developers
are
accused
of
resume
driven
development
because
you
can
see
what's
changing
and
then
you
pick
technologies
based
upon
what
you
think
the
market
demand
will
be
going
forward.
So
you
know
you're,
obviously
not
going
to
pick
something
like
debase
for
your
next
project,
because
that's
not
going
to
get
you
any
jobs
anywhere
else.
A
So
many
java
developers
do
not
consider
themselves
jaccard
ee
developers,
but
it
has
provided
a
basically
a
standard
set
of
technologies
that
java
developers
use
and
what
what
goes
on
with
what
they
put
on
their
resumes.
So,
even
if
a
java
developer
currently
does
not
consider
themselves
a
jicardi
developer,
their
resumes
are
probably
full
of
or
definitely
full
of,
jaccardi
acronyms.
A
And
I'll
have
to
slide
on
that
in
a
second,
but
just
to
stress,
tying
yourself
to
a
single
vendor
is
a
bad
long-term
strategy
for
a
developer,
because
vendors
change
and
change
directions
on
a
fairly
regular
basis.
So
the
nice
thing
with
jakarta
dee
and
what
has
provided
java
developers
over
the
last
20
years
is
a
consistent
set
of
technologies
on
which
to
build
your
career
and
which
to
learn,
because
you
know
they've
been
around
so
long
as
applications
that
are
out
there.
A
So
you
can
easily
move
between
companies,
so
you
can.
If
one
company
is
using
wrestling
and
another
one
is
using
apache
cfx,
you
know
you
can
easily
say
yes,
I
know
jax
rs.
You
know,
I
know
how
to
write
web
services
and
you
just
need
to
learn
some
of
the
idiosyncrasies
of
that
particular.
You
know
how
to
configure
a
particular
implementation,
but
you
can
you
can
on
day
one
be
writing
code.
It's
not
something
completely
new,
so
it
allows
developers
to
easily
you
know,
move
across
companies.
A
It
enables
companies
to
easily
hire
developers
and
know
what
you
know
know
that
they
know
how
to
write
web
services
right.
Whether
they've
you
know
worked
on
weblogic
at
the
previous
company.
They
primarily
work
with
tomcat
or
they're.
Writing
microservices,
there's
a
standard
set
of
skills
that
they
that
you
know
that
they
will
have
if
they
have
that
if
they
list
that
technology
on
their
resume.
A
So
if
we
look
at
this
example
resume
that
I
pulled
offline
now,
it's
full
of
jakarta
ee
technologies
right
it
uses
it,
has
the
old
j2ee,
because
a
lot
of
recruiters
etc
still
ask
for
j2ee
and
hiring
in
hr
departments.
But
you
know
it's
a
smorgasbord
of
every.
You
know
specification
coming
from
jakarta
e.
They
don't
say
at
the
top
of
the
resume.
A
A
A
You
know
a
developer
knows
that
the
skills
that
they're
learning
are
going
to
be
transferable
to
multiple
companies
and
companies
know
that
they
are
picking
a
standard,
a
technology
stack
which
has
a
developer
ecosystem
and
a
set
of
implementations
to
choose
from
that
are
relatively
stable
over
you
know
now,
20
years
and
just
to
drive
the
point
home.
This
is
a
technology
graveyard
that
I
put
together
of
once
hot
technologies
that
are
now
basically
dead.
A
So
you
know,
we've
got
powersoft
if
people
remember
that
or
adf
web
objects,
which
were
big
in
the
apple
ecosystem,
I
mean
there
were
people
that
that
built
their
entire
career
and
companies
off
of
web
objects.
And
then
you
know
one
day:
apple
decided
nope,
we're
not
going
to
it.
Wasn't
a
standard
we're
not
going
to
continue
pushing
this
forward,
we're
going
to
drop
it
as
a
product.
What
do
you
do?
A
I
had
a
recruiter
at
the
connecticut
job
users
group
that
was
previously
an
employer.
He
had
based
his
company
and,
I
think,
a
consulting
firm
off
of
micro,
microsoft,
silverlight.
When
microsoft
decided,
you
know
they
were
going
to
drop
silverlight.
There
went
his
business
and
there
went
his
career
right
because
it
was
based
upon
the
vendor
technologies.
A
A
The
test
compatibility
kit
is
open
source
and
you
can
run
it
yourself.
You
can
even
add
tests
to
it.
So
if
you,
you
know,
decide
that
you
know
there's
some
inconsistency
or
you
want
to
make
sure
that
you
know
you
want
to
you
just
you
discover
that
there's
difference
between
pyro
and
web
lib.
You
know
open
liberty
or
something
like
that.
You
can
actually
augment
the
tck.
A
This
is
a
little
bit
about
background
on
them
and
until
they
submitted
this,
I
actually
wasn't
familiar
with
them.
But
if
we
look
at
that,
you
can
actually
dive
down
in
and
look
at
the
compatibility
tests
right.
So,
if
you're
a
writing,
jacks
are,
you
know,
writing
restful
web
services
or
you
know
in
this
case
batch
services.
A
You
can
look
through
the
test,
so
you
can
see
that
they.
You
know
that
this
is
a
valid
implementation
is
passing
a
test,
so
you
have
a
pretty
high
confidence
that
your
code
is
going
to
run
on
this
container.
If
you
decided
to
to
support
it
or
if
you
decided
to
put
your
application
to
it
same
thing
for
websockets
and
we
can
see
the
number
of
tests
here,
I
mean
there's
tests,
you
know
over
11.
A
A
A
Jakarta
e9
was
released
this
past
december.
The
there
was
a
probably
the
biggest
change
to
applications
running
on
jakarta.
He
was
namespace
change.
That
doesn't
mean
that
the
application
that
you
have
to
completely
port
your
application,
because
containers
are
free
to
to
support
both
the
new
and
the
old
name.
Space
and
old
applications
will
continue
to
run
on
containers.
A
So
there's
no
feature,
there's
no
feature
change
with
that.
With
the
nine
release,
the
goal
is
just
to
simplify
the
name
space
transitions
for
applications
that
are
doing
that
at
this
time.
Containers,
as
I
mentioned,
can
support
the
older
name
space.
So
they
can
run.
You
know:
jacardi
application,
ee
eat
application.
A
If
the
container
so
chooses
to
support
that
jakarta
e9.1,
I
think
it's
coming
out
shortly,
if
it
hasn't
already
with
java
11
support,
there's
no
other
changes
other
than
that
and
right
now,
planning
is
going
on
for
jakarta
ee10
and
you
can
get
involved
with
that.
For
you
know
adding
you
know
for
specifying
what
features
you'd
like
to
see
added
to
it,
but
its
feature
is
bright
because
it
is,
it
successfully
pulled
off
multiple
transitions
over
his
lifetime
right,
so
jacardi
dropped
e.
A
It
was
open
sourced,
successfully
open
sourced,
using
the
eclipse
foundation
and
has
oracle
and
all
the
companies
that
were
behind
it
back
then
are
still
behind
it
today
and
release
cycle
is
moving
forward
and
there's
been
some
fairly
big
changes
in
the
java
ecosystem.
I
mean
java
8
to
java
9.
You
know
the
jump
to
java
11
is
a
big
is,
is
a
big
transition
that
many
other
technologies
or
other
technology
stacks
probably
wouldn't
have
survived
this
type
of
transition.
A
So
these
are
fairly
major
changes
that
are
going
on
here
and
they're
they're
being
pulled
off
successfully
and
it's
got
an
active
community,
pushing
it
forward
so
going
forward,
features
that
you
know
will
be
added
or
looking
at
being
added
to
it.
There's
you
know
more
alignment
with
cdi.
You
know
adding
in
support
for
asynchronous
pulling
stuff
out
of,
like
the
ejb
specification,
adding
in
support
for
message,
listeners
java,
se
alignment,
adding
in
completable
and
completable
future
and
concurrency
improving
bootstrap
apis,
decoupling,
the
tcks
and
modularization.
A
So,
for
example,
taking
advantage
of
like
java
e
sorry,
the
modularization
support
that
was
added
in
java
9.,
closing
some
of
the
standardization
gaps
on
security
batch
and
concurrency
persistence
transactions.
You
know
adding
in
standardizing
things
that
you
know
weren't
standardized
in
the
first
go
around.
You
know
it's
become
obvious
that
they
need
to
be
updated
or
extended,
and
then
some
innovations
you
know
support
for
nosql
configuration
which
is
now
being
which
is
now
in
the
process
of
being
moved
over
and
so,
for
example.
A
These
are
some
of
the
kind
of
going
over
some
of
the
proposals,
but
you
know
modernize
messaging
so
that
all
we
have
to
do
is
add
an
annotation
to
a
pojo
class
to
make
it
a
message
listener.
You
know
adding
in
support
for
standalone
bootstrap
api
kafka
interoperability.
So
these
are
things
that
are
being
discussed
for
jakarta,
ee10
and
reasons
for
getting
involved.
A
So
developers
are
really
can
the
community
can
really
drive
this
forward
so
if
you're
an
employer
or
you're
working
with
something
and
you're
saying
well
geez,
I
wish
it
did
this
or
this
needs
to
be
standardized
because
you
know
I
look
at
there's
like
10
different
ways
of
doing
this
depending
upon
you
know
which
which
vendor
I
use.
Then
you
know
when
everybody's
trying
to
do
the
same
thing,
then
that's
something
that
should
be
standardized.
A
Also,
looking
at
being
standard
making
it
into
jakarta,
e10
is
support
for
nosql
standardizing
nosql
database
access.
Now
that
nosql
databases
have
been
around
for
quite
a
while.
So
you
know,
some
of
the
different
jpa
implementations
do
support
nosql,
and
so
this
is
basically
just
standardizing
how
they
will
work
so
that
you
know
everyone
has
a
common.
You
know
understanding
as
to
how
the
apis
work.
A
Applications
can
be.
You
know,
built
going
against
the
standard
so
that
they
can
easily.
You
know
you
know
work
with
different
data,
different
nosql
database
sources
and
then
have
them
behave.
The
same
way
it's
kind
of
like
what
jdbc
gives
us
originally
gave
java,
and
then
you
know
externalizing
beam
validation
and
configuration.
A
Now
many
of
these
containers
already
support
these,
so
what's
actually
being
done
is
standardizing
it
so
that
all
of
the
containers
have
support
for
it
and
that
the
support
is
uniform
across
all
of
the
containers,
so
that
that
being
jaccard
to
e
is
just
a
stress
is
is
a
standard.
So
it's
trying
to
you
know
after
everyone
has
said,
okay,
jwt
is
the
way
to
go.
Let's
standardize
how
this
works
with
your
your
java
application,
so
that
you're
not
dealing
with
different
implementations,
different
idiosyncrasies
and
different
versions
of
those
implementations.
A
And
then
begin
beyond
jacardi
10
persistence,
alignment
with
java
sc
records,
so
the
language
java
language
is
now
evolving
more
rapidly.
So
you
know
aligning
the
persistence
with
the
java.
The
record
support
that
was
added
in
java,
adding
in
support
for
json,
schema,
reactive,
more
reactive,
support
to
servlets
and
persistence
and
making
modularity
embedded
and
improving
upon
modular
modularity
and
leveraging
the
modularity
changes
that
were
added
in
in
java
sc9.
A
So
those
are
some
of
the
things
that
are
looking
forward.
So
there's
there's
discussions
right
now.
What
what's
going
to
go
into
jakarta,
e10
now
that
9.1
is
basically
out
and
then
you
know
further
down
the
road.
You
know
what
what's
going
to
happen
with
java
s.
You
know
ee
11,
etc.
So
you
know
it
is.
It
is
moving
forward
and
there's
discussions
about.
A
What's
going
on
in
the
future,
over
at
the
jacardi
ambassadors,
we
had
put
together
a
google
doc
trying
to
pull
and
get
people
from
the
community
to
say
you
know
what
they
would
like
to
see
involved
in
that.
So
we've
been
working
on
a
document
that
that
members
can,
you
know,
jump
in
and
say
well,
this
needs
to
be
addressed.
You
know
I'd
like
to
see
this
added
to
messaging
or
these
changes
to
it.
A
So
you
know
just
to
stress
the
point
that
this
is
something
that
jakarta
de
is
very
relevant
because
developers
can
get
involved
and
drive
it
forward,
so
you're
not
dependent
upon
a
corporation
and
say
you
know
a
single
manager
or
executive
deciding
which
way,
which
way
it's
going
to
go.
It's
still
commun
it's
it's
community,
driven
allowing
the
end-use
and
developers
to
to
drive
it
forward
and
there's
multiple
implementations
of
that.
So
there's
a
very
rich
ecosystem
and
exchange
of
ideas
going
on
so
at
least.
A
Eighty
percent
of
java
applications
use
a
jakarta
e
api
of
some
sort
and
I
actually
kind
of
think
it's
kind
of
under
because
you
know
practically
everything
you
know
unless
you're
writing.
You
know
a
pure
desktop
application,
that's
not
using
web
services
or
anything
else.
That's
about
the
only
way
that
you
would
not
be
using
a
java.
Jar2
technology
underpins
many
of
the
frameworks
and
libraries
and
applications
so
whether
you're
using
spring
or
micro
profile,
both
of
those
depend
upon
jakarta
ee.
A
It
differ,
differentiates
java
from
other
languages.
So
having
this
api
standard
api
toolkit
with
multiple
implementations,
this
is
very
different
from
what
you
see
in
other
in
other
languages
and
other
ecosystems.
You
don't
see
this
where
you
have
a
standard
way
of
implementing
jet.
You
know
web
services
and
then
multiple
implementations
of
that
giving
you
different
features
right.
A
So
if
you're
over
in
the
the
javascript
ecosystem,
you'll
have
you
know,
there's
different
frameworks
for
doing
that,
but
they're
not
implementing
a
standard
so
you're
either
using
this
framework
or
that
framework
right
with
with
in
the
jacardi.
You
have
a
standard
way
of
you
know
of
working
with
these
and
the
technologies
are
meant
to
work
together.
So,
for
example,
you
know
if
you're
writing
a
restful
web
service.
The
bean
validation
framework
works
with
it
right.
There's
tests
that
verify
that
they
work.
A
You
can
use
bean
validation
with
jax
rs
so
that
your
java
code,
when
the
web
service
hands
you
a
java
object,
that's
been
inflated
from
json.
It's
been
it's
determined
to
be
valid.
Other
ecosystems,
you're
kind
of
like
gluing
things
together
yourself,
so
it
might
not
glue
together
very
well.
There
might
be
holes
that
you're,
not
aware
of
so
it
is
it's.
You
can
use
the
different
pieces.
Those
pieces
of
jacari
can
be
used
independently.
A
However,
they
are
tested
together
and
they're
meant
to
work
together.
So
as
your
application
needs
evolve,
you
can
continue
to
build
upon
that
and
it's
guaranteed
to
you
know,
be
backwards.
Compatibility.
So
that
ties
into
the
business
so
admin,
so
it
enables
you
to
minimize
vendor
lock-in.
It
simplifies
your
hiring
process
because
you
have
known
skills
that
you're
hiring
for
because,
if
you
hire
somebody
and
for
some
of
the
other
languages,
you
know
the
different
toolkits
are
very
different.
You
know
an
objective-c
developer
and
a
swift
developer.
Those
are
two
different.
A
You
know
you
need
to
hire
somebody
that
writes
a
ios
application.
If
you
have
somebody
that's
in
front
of
you,
that's
a
swift
or
an
objective
c
developer.
Those
are
two
different
completely
different
technology
stacks,
so
it
provides
long-term
continuity
and
stability.
You
know
write
once
not
rewrite
every
year,
so
the
objective
is,
is
that
you
know
you
write
your
application
and
you.
B
A
Money
off
of
it
and
you
add
additional
features
to
it.
You're,
not
just
you
know,
getting
thrashed
by
the
ecosystem,
as
somebody
updates
something
a
library
and
is
used
widely
in
the
cloud,
and
you
know,
has
many
solutions
and-
and
I
think
that
that
jakarta
ee
with
you
know-
I
mean
the
cloud
vendors
right
now.
A
So
some
common,
jaccardi
misconceptions,
jakarta
ee
java
e
requires
you
to
use
jsp
servlets
jsf.
The
answer
to
that
is
no.
If
you're
writing
a
jakarta
application,
you
can
do
your
ui
using
angular
react.
There's
nothing
that
stops.
You
from
you
know,
there's
no
requirement
that
you
use
jsf
jsf,
you
know
came
out
of
you
know,
solves
a
particular
problem
and
came
out
during
you
know
a
specific
time
period.
The
standards
applications
that
were
written
with
it
20
years
ago,
or
you
know
15
plus
years
ago.
You
know
still
run
today
right.
A
A
However,
if
you're
starting
development
today
you
do
your
back
end
with
jax
rs
and
you
know,
react
from
that.
Jakarta
e,
app
jacardi
or
for
monolithic
applications.
No,
that's,
definitely
not
a
requirement.
Chakardi
applications
can
be,
you
know,
microservices.
They
can
be
job
desktop
applications.
You
can
miss
and
match
the
standards
to
implement
whatever
you
need
to
do
so.
If
you're
trying
to
process
json
data,
it's
better
to
use
an
implementation
from
jaccardi
because
it's
been
tested,
it's
been
examined
for
performance,
it's
got
regression
tests
on
it
and
it's
got.
A
You
know,
it'll
be
backwards
compatible.
So
a
year
from
now
it'll
still
work.
You
don't
have
to
worry
about
something.
Changing
I've
seen
developers
go
off
and
try
to
implement.
You
know
not
use
jacardi
technologies
and
try
to
implement
their
own
json.
You
know
serializers
and
deserializers
and
stuff
like
that,
and
that's
you
know
not
directly
relevant
to
what
they
were
actually
trying
to
trying
to
implement
jacardi.
He
is
stagnant.
That's
definitely
not
the
case.
It
is
moving
forward.
You
know,
yeah.
A
There
was
a
slow
year
with
the
transitions
with
oracle
to
the
eclipse
foundation,
but
that's
been
completed
and
that
that
was
a
major
hurdle
that
required.
You
know
heavy
investment
from
oracle
and
oracle's
legal
group
to
pull
off
and
so
many
other
technologies.
They
would
just
you
know
if
it
was
not
valuable
or
you
know
it
would
be
put
out
to
die,
and
that
was
not
the
case
with
cicardia.
Heavy
investment
was
made
to
get
it
donated
to
the
eclipse
foundation
to
push
it
forward
and
jacardi
e
is
all
or
nothing.
No,
that's.
A
Definitely
not
true.
I've
been
making
that
point
throughout
the
presentation
that
you
can
use
mismatches
technologies
from
jakarta
to
eat,
to
build,
with
whatever
type
of
application
you're
trying
to
construct
if
you're
looking
for
some
demo
applications
for
jakarta
ee
cargo
tracker,
which
just
actually
recently
had
a
release,
is
a
good
one
that
uses
many
of
the
jacardi
technologies
and
provides
a
roadmap
for
how
to
use
how
to
use
different
ones.
A
Built-In
integration
tests-
it's
basically
just
a
hello
world,
but
the
maven
file
is
all
set
up
so
that
you
can
clone
the
project
and
you're
off
and
running,
because
that's
gonna
be
a
bit
of
a
hurdle
and
so
ways
of
contributing
to
jakarta
e.
So
you
can
follow
the
cardi
technologies
that
interest
you.
A
A
B
A
B
Yeah
definitely-
and
at
this
point
we
don't
have
any
more
questions,
but
what
I'm
going
to
do
is
give
people
a
little
more
time
to
get
them
in.
There's
there's
been
a
lot
of
information
here
and
a
lot
to
to
cover.
So
if
you
have
questions,
please
feel
free
to
ask
them
in
the
chat
or
using
the
ask
a
question
tab.
B
But
at
this
point
I
will
just
give
some
quick
reminders
of
upcoming
news
in
the
jakarta
ee
community
and
then
feel
free
to
get
in
your
questions,
and
we
can
address
them
after
that.
So
the
next
jakarta
tech
talk
happens
on
june,
2nd
chris
walker
and
greg
wilkins
will
join
us
to
present
eclipse
jetty
for
servlet.
B
If
you're
interested
in
learning
more
about
eclipse
jetty,
you
can
register
using
the
link
I
just
posted
in
the
chat.
There
are
also
only
two
weeks
left
to
submit
a
response
for
the
jakarta
ee
developer
survey.
This
survey
helps
java
ecosystem
stakeholders,
better
understand
requirements,
priorities
and
perceptions
of
enterprise
java
communities.
If
you
fill
out
the
survey
using
the
link
in
the
chat
that
I'm
about
to
post,
you
can
sign
up
and
win
some
free,
jakarta,
ee
swag
as
well.
B
B
A
Now,
if
you're,
you
know
so
that
that's
for
getting
involved
for
pushing
it
forward
now,
for
actually
you
know
getting
your
day
job
done
you,
you,
probably
heavily,
invest
in
a
given
container
or
given
implementation,
because
you're
picking
it
for
the
features
that
it
provides.
You
the
the
additional
features,
so
it's
kind
of
yes,
I
mean.
I
know
I
focus
heavily
on
one
particular
or
actually
two
particular
implement
jacardi
implementations
on
my
job.