►
Description
Steve Millidge speaks at JakartaOne Livestream 2020
Abstract
This session will cover the Eclipse GlassFish project and cover in some detail the role of Eclipse GlassFish in relation to the Jakarta EE project. How it brings together all the various EE4J projects to create an application server. I will also cover the specification process and the need for a compatible implementaiton that covers all the optional specifications which makes GlassFish somewhat special in Jakarta EE 9. I will then go into the breaking changes inherent in Jakarta EE 9 compared to Jakarta EE 8. I will describe how the team approached taking something as complex as an application implementing the specifications and migrated it to the new namespace. The point will be that it wasn’t as bad as expected. I will then look at migrating a simple Jakarta EE 8 application over to the new namespace and deploying onto Eclipse Glassfish 6.0.0 stressing the point that migration for applications is pretty simple.
Get Social!
Website: jakarta.ee
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
Okay,
so
they
said
I'm
steve
miller
from
payara
I'll
be
doing
presentation
on
glass,
fish,
six,
jakarta,
e9
implementation,
so
I'm
the
founder
of
payara
payor,
obviously
is
an
application.
Server,
open
source
application,
server
company,
I'm
also
a
member
of
the
pmc
for
the
ee4j
project.
The
4j
project
is
the
main
project
that
does
the
implementation
projects
and
the
api.
So
that's
the
open
source
side
and
also
co-lead
of
jakarta
9
release.
B
That's
with
kevin
from
kevin
sutter
from
ibm,
I'm
mainly
focusing
in
that
on
getting
glass
fish
out
there
as
the
compatible
implementation
for
the
jakarta
nine
release.
So
I'm
co-lead
on
glass,
fish
and
I'm
a
steering
committee
member,
I'm
also
was
heading
up.
Getting
jakarta,
concurrency
out
and
jakarta.
Connect
is
out
and
in
generally
I'm
a
committer
on
a
lot
of
the
projects.
So
I've
been
heavily
involved
on
the
jakarta
nine
release.
B
B
Some
of
that
in
that
as
well
I'll,
then
go
into
a
little
bit
about
how
we
built
glass
fish
six,
you
know
with
the
name,
space
change,
it'll,
basically
sort
of
discuss
our
approach,
how
we,
how
we
went
for
it
and
what
the
problems
we
we
encountered,
because
obviously
glassfish
is
a
very,
very
big
application
that
was
obviously
in
the
javax
namespace.
So
we'll
be
basically
looking
at
how
we
approach
that
and
then
I'll
have
a
little
bit
about
how
to
change
your
code.
B
I
know
there's
other
presentations
about
how
you
can
migrate
applications
into
the
new
namespace
I'll.
Do
a
quick
demo
of
doing
that
on
glassfish
six
and
then
I've
got
a
little
bit
about
what's
next
for
glass,
fish
with
trigatu
9.1
and
10,
and
some
ideas
around
that:
okay,
so
so
jakarta.
So
first
I'm
going
to
cover.
What's
in
jakarta,
9.,
it's
probably
been
covered
by
a
lot
of
other
people,
but
it's
good
to
recap:
from
a
glass
fish
perspective,.
B
So
just
go
backwards,
a
little
bit.
What
was
in
jakarta
eight?
Obviously,
a
lot
of
the
road
to
jakarta.
Nine
was
actually
first
getting
glass
fish
through.
First,
we
had
to
get
compatibility
with
java
e8
with
an
eclipse,
so
we
built
a
version
of
glassfish
5
flash
5.1
that
had
full
compatibility
with
java
ee-8
and
passed
the
java
ee-8
tck's
platform
specification
using
the
oracle
tcks.
B
The
next
step
for
the
evolution
of
moving
java
ee
through
to
the
clips
foundation
was
to
actually
release
jakarta,
e8,
so
jakarta
e8
was
designed
to
be
basically
binary
compatible
with
java
e8,
so
it
was
fully
compatible
with
e8
the
difference.
Being,
though,
that
the
specification
documents,
the
tcks
the
process,
the
implementations
etc
were
all
based
from
the
eclipse
foundation
and
were
all
open
specifications
under
open
source
licenses.
B
B
So
this
basically
gave
us
a
full,
transparent
version
of
glassfish
transparent
as
an
open
source.
There
are
also
a
lot
of
other
implementations
that
came
along
with
jakarta.
Ee8
we've
got,
you
know
a
big
set
now,
so
obviously
eclipse
glassfish
is
the
one.
I've
been
heavily
involved
in
and
also
piara
server,
five
as
well
so
having
car
g8
as
an
open
source
standard,
also
enabled
the
payora
team
who
to
basically
release
payara
as
a
compatible
implementation.
B
B
We
then
spent
a
lot
of
time
so
releasing
java
ee
8
as
jakarta
ee8,
which
again,
as
I
said,
is
about
moving
java
ee
into
open
source
specifications,
open
source
apis,
open
source
licensing
and
open
source
process.
Again
we
looked
at
releasing
a
different
version
of
eclipse
glassfish,
but
essentially
we
didn't
need
to
so
eclipse.
Classification
5.1
is
both
java,
ee8
and
jakarta,
ee8,
compatible
or
compliant,
and
therefore
that
sort
of
shows
that
they
are
binary
compatible,
binary,
binary
equivalents
between
jakarta,
ee
and
java
ee.
B
B
Namespace,
so
what
we
did,
I
was
part
of
the
team
putting
together
the
sort
of
release
plan
and
the
release
plan
was
really
focused
around
just
the
name:
space
change,
really.
That
was
just
to
make
sure
that
we
could
target
tooling
vendors
and
applications
wouldn't
have
to
be
too
worried
about
changes
in
behavior
and
changes
in
specifications
between
ee8
and
e9.
B
So
basically,
e9
is
the
same
as
e8,
but
it's
in
the
jakarta
namespace
there's
some
other
things
that
we
wanted
to
do.
We
wanted
to
remove
unwanted
or
deprecated
specifications,
so
really
take
out
things
that
were
old,
not
really
used
anymore
or
used
rarely
or
unsupported
by
many
of
the
applications
servers
really,
that
was
to
lower
the
barrier
of
entry.
We
want
more
implementations
to
be
able
to
be
certified
as
compatible.
B
B
The
secondary
goal
for
jakarta
nine
was
to
to
set
a
platform
for
innovation.
We
wanted
e9
to
be
the
same
as
eight,
but
in
the
new
name
space,
because
it's
a
big
breaking
change,
but
at
that
point
now
we're
done
then
e9
becomes
that
platform
to
move
forward
for
innovation,
and
that
means
looking
forward
to
ee10
and
again
having
just
the
namespace
change
and
removal
of
some
old
things
means
that
it
should
be
easy
to
migrate,
an
application
from
one
version
to
the
next
from
e8
to
ee9.
B
B
B
So,
where
does
glassfish
sit
in
sit
within
the
jakarta
ee,
because
previously,
in
java
ee
class
fish
was
what
was
called
the
reference
implementation
and
reference
implementations?
Don't
exist
in
jakarta
ee,
so
the
big
difference
really
that,
as
I
said
for
jakarta
ee,
it's
a
set
of
open
specifications.
B
As
it's
shown
on
here,
java
ee
had
one
normative
reference
implementation
and
what
that
meant
was
that
if
you,
if
there
was
sort
of
ambiguity
in
the
specification
about
what
behavior
was
correct,
then
glass
fish
was
a
normative
implementation.
You
would
check
it
in
glass,
fish
and
whatever
glass
fish
did
was
correct.
That's
gone
with
jakarta
ee,
so
there's
no
special
implementation
in
jakarta
ae,
so
glassfish
is
not
special
as
it
was
in
java
e.
It's
one.
B
B
Basically,
when
you
create
a
specification
project
within
the
eclipse
foundation,
that
project
has
to
create
these
orange
deliverables.
Well,
it
has
to
have
all
these
things
available
to
actually
be
signed
off
and
voted
and
balloted.
So
we
need
a
document.
We
need
an
api
jar,
we
need
a
tck
and
we
need
a
compatible
implementation
that
passes
the
tck
and
implements
all
the
open
source
components.
B
B
You
need
to
have
an
implementation
that
implements
all
those
optional
pieces
and
for
jakarta
ee9
that
implementation
is
class
56,
so
glass
fish
is
in
that
sort
of
strange
position
at
the
moment
in
that
it's
the
only
implementation,
except
maybe
piara,
that
implements
all
the
optional
pieces
and
it's
the
only
implementation
that
basically
can
be
used
at
this
point
in
time
to
release
the
spec
to
release
the
platform.
So
we
have
a
bit
of
a
chicken
and
egg
situation
to
release
the
platform
spec.
B
So
a
lot
of
my
work
really
has
been
about
ensuring
that
glass
56
is
ready
at
the
same
time
as
this
chicago
nine
release,
and
the
reason
that
we're
heavily
involved
is
obviously
payara
is
a
basically
fought
from
glassfish
a
few
years
back.
But
that
does
mean
we
know
a
lot
about
the
co-base
and
therefore
we
can
spend
a
lot
of
time,
converting
it
and
moving
it
over
into
the
casting
name.
Space
using
the
basic
gyan
pyora
knowledge,
so
the
pyritine
has
been
pretty
heavily
involved
in
pushing
out
the
glass
classifier
6.0.
B
B
It's
also
used
to
ballot
things
like
ejb,
jakarta
carter,
concurrency,
jakarta,
connectors,
they're,
all
implemented
in
glassfish,
jakarta
security.
Many
of
these
specifications
use
glassfish
as
the
initial
compatible
implementation,
so
they
can
get
proof,
as
I
said
from
the
previous
slide,
that
they
tck
they've
created,
can
be
tested
and
can
be
run
in
a
real
implementation.
B
B
B
B
The
project
isn't
just
the
core
server,
so
there
are
other
projects
that
we
depend
upon
within
e4j
and
externally,
for
example,
on
the
bottom
half
of
the
of
the
picture,
there's
a
whole
bunch
of
projects
that
aren't
really
jakarta
ee,
that
glass
fish
depends
on
something
called
show,
which
is
the
clustering
implementation,
which
is
dependency
injection.
We
still
got
dependencies
on
the
corba
orb,
which
was
also
the
e4j
project,
separate
to
glassfish.
B
We
have
grizzly
for
networking
and
then
woodstock
and
jsf
templating,
which
are
part
of
the
administration
console,
and
then
we
have
in
yellow
all
the
apis
that
we
depend
upon.
These
are
obviously
the
actual
jakarta
apis,
so
that's
not
all
of
them
and
then
given
the
apis.
We
also
then
have
implementations
of
each
one
of
these
apis.
B
B
It
actually
took
quite
a
long
time
not
because
of
the
technical
complexity
involved,
but
because
of
the
dependencies
involved.
So
if
you
can
imagine,
the
approach
we
took
first
was
to
basically
change
our
dependency
to
a
jakarta
dependency.
For
example,
if
we
depended
on
jakarta
rest,
then
we
just
updated
our
dependency
in
our
pom.
Looked
at
everything
that
didn't
compile
and
then
changed
the
namespace
for
that.
But
we
also
had
to
wait
for
jakarta
to
rest
to
actually
produce
a
new
api
release
candidate
that
we
could
depend
on.
B
And
to
get
to
a
final
release
so
today
we're
actually
release
candidate
2,
which
is
a
full,
fully
compatible
implementation.
It
passes
the
tck
but
to
get
to
final,
which
hopefully
we'll
do
in
the
next
week,
or
so.
We
need
every
single
one
of
these
other
components
that
we
depend
upon,
which
aren't
part
of
our
project
to
also
release
final
candidates.
B
So,
as
I
said,
glassfish
itself
was
a.
It
was
really
big,
jakarta
application,
so
almost
all
of
it
would
depends
on
the
javax
namespace.
So
we
approached
it.
We
didn't
do
a
search
and
replace,
as
that
can
be
a
bit
brutal.
So
and
you
can
there's
some
subtleties
in
the
name.
Space
changes,
for
example,
jakarta
transaction,
some
of
the
apis
are
instilled
in
the
jdk
and
it's
still
in
the
javex.
B
B
B
Then
we
had
a
lot
of
problems
with
osgi,
so
we
had
to
fix
a
lot
of
osgi
errors.
Glassfish
server
is
built
on
top
of
an
osgi
platform
and
we
had
some
osg
version
numbers
and
issues
with
names
and
things,
so
we
had
to
fix
those
as
well
once
we
got.
The
first
step
was
to
actually
get
the
thing
to
compile
once
it
compiled.
B
We
had
to
get
it
to
run
and
that's
when
we
hit
start
hitting
osgi
errors
and
again
a
lot
of
that
was
to
then
work
collaboratively
with
the
api
and
implementation
teams
to
fix
those
errors.
On
upstream
from
us,
and
one
of
the
major
things
about
working,
the
eclipse
foundation
that
I
found
was
actually
the
level
of
collaboration
was
incredibly
high
across
multiple
vendors,
multiple
community
members
to
actually
fix
and
drive
changes
like
this
through
the
project.
B
The
next
step,
then,
is
to
pass
the
tcks,
so
the
first
is
a
whole
bunch
of
standalone
tcks,
like
cgi,
for
instance,
that
you
need
to
pass
as
a
compatible
implementation
again
those
passed
pretty
quickly
because,
in
general,
the
api
influencer,
the
implementations
of
those
apis
like
weld
etc
would
have
had
to
pass
those
standalone
tcks
to
work.
And
then
you
have
to
pass
the
platform
tck
and
the
platform.
B
Tck
is
a
little
bit
more
complicated
because
that's
sort
of
testing
interaction
between
different
specifications
and
you
need
basically
to
run
it
see
what
happens
see
if
you
pass
look
at
any
failures
and
start
basically
working
out
where
the
failure
occurs.
Does
it
occur
in
our
classfish
code
base,
or
does
it
occur
in
an
upstream
component
that
we're
pulling
in
so
that
I
mean
that's
how
we
approached
it.
Glassfish
is
probably
one
of
the
biggest
applications
that
would
have
to
migrate
to
the
new
namespace
it.
B
I
actually
thought
it
was
from
a
technical
perspective,
quite
easy
to
do.
From
a
time
perspective.
It
took
a
long
time
because
we
were
obviously
tracking
apis
as
they
appeared
and
implementations
as
they
appeared.
If
you're
migrating
your
own
application
after
today,
then
obviously
all
those
apis
are
in
maven,
central
and
there's
no,
you
don't
have
to
wait
for
them
to
turn
up.
B
B
B
B
I
don't
know
why
it's
taking
so
long
is
that,
like
this,
application
will
actually
deploy,
but
it
won't
be
deployed
correctly,
and
the
reason
for
that
is
basically
glassfish
no
longer
knows
anything
about
the
javax
namespace,
so
I
can
actually
take
that
wire
file
in
the
old
namespace
and
deploy
it
okay.
It
deploys
without
any
problems,
and
the
reason
is
is,
as
I
said,
glassfish
doesn't
know
anything
about
the
javax
namespace
anymore.
B
So
if
I
actually
click
on
it
I'll
try
to
make
this
bit
bigger,
it
hasn't
detected
any
of
the
rest
components
any
of
the
servlets
or
any
of
the
pieces
that
were
actually
deployed
that
you've
got
as
as
as
jakarta
a
javex
components.
For
example,
it
doesn't
see
that
there's
a
hello
world
servlet
there
and
see
the
reason
is,
it
knows
nothing
about
the
javax
namespace,
so
that
class
now
is
literally
just
like
any
other
class,
so
it
doesn't
detect
it
as
a
server.
It
doesn't
detect
the
web
server
annotation.
B
B
Simple,
as
that,
you
could
obviously
do
it.
Cotton
paste
search
and
replace,
but
there
are
some
subtleties,
especially
around
transaction
api.
So
if
I
save
that
it
should
compile
now,
we
literally
did
that
through
the
whole
glassfish
codebase
not
totally
manually,
but
not
with
a
straight
search
and
replace.
B
B
B
B
B
B
B
So
so
that
is
a
very,
very
simple
demo
of
migrating,
an
application
it
doesn't.
Let's
say
it
doesn't
take
that
long
depending
on
your
code.
Obviously,
you
can
have
a
lot
of
name
space
changes,
but
nothing
as
big
as
and
glassfish
had
when
we
changed
all
that
code
base,
and
it
should
only
take
as
long
as
it
takes
to
replace
those
imports.
B
B
rc2
is
the
one
that
is
the
compatible
implementation
used
to
release
jakarta
e9.
It
passes
all
the
tcks,
all
the
standalone
tcks
as
well,
and
the
platform
cts
and
that's
available
for
download
on
the
eclipse
website.
The
only
difference
between
glass
roof,
six
final
and
the
rc2
is
that
we're
still
waiting
for
a
couple
of
implementations
to
push
their
final
versions
out
into
maven,
central
and
that'll
happen
in
the
next
week,
or
two
we're
still
waiting
for
cdr
weld
and
hibernate
beam,
validation
and
jbatch.
B
B
B
B
Basically,
jakarta
310
is
where
we're
looking
at
we've
done
all
the
work
to
migrate.
From
java
ee
to
jakarta
ee,
you
know,
jakarta,
nine
will
be
in
the
new
name
space
it's
equivalent
to
psychiatry,
eight,
which
is
equivalent
to
java
e8,
just
in
the
new
namespace.
Now
we're
starting
to
get
look
at
how
we
can
improve
and
drive
forward
ee10
see.
These
are
some
of
the
things
that
that
have
come
out
recently
about
go
from
surveys
about
what
people
would
want
from
jakarta,
e10
and
from
a
glass
fish
perspective.
B
I
imagine
we're
still
likely
to
be
required
to
push
out
to
carter
e10
so
that
we
are
the
first
compatible
implementation.
That
may
not
happen.
Another
implementation
may
need
to
come
along
and
that's
perfectly
fine
it
just
we
need
to
you
need
to
have
all
optional
pieces,
as
I
said
earlier.
So
I
imagine,
unless
we
so
in
a
lot
of
optional
components
out,
attend
that
seven
or
something
will
need
to
be
the
compatible
implementation.
B
So,
there's
a
lot
of
opportunity
now
to
jump
in
get
involved
and
actually
drive
forward
what
you
know
all
the
things
that
we
wanted
to
improve
as
we
move
jakarta
forward.
So
these
these
are
things
that
have
been
on
the
wish
list.
These
things
have,
you
know,
been
the
priority
month
and
we'll
be
you
know,
assisting
to
build
within
grassfish
seven.
B
B
B
You
know
do
that
integration
work,
as
I
showed
in
the
slide
where
we
depend
on
all
these
apis
and
all
these
implementation
projects.
Our
job
really
is
like
a
integration
hub
to
make
sure
that
all
those
things
can
work
together
and
get
the
releases
out
before
you
know.
At
the
same
time,
as
the
platform
specification
is.
B
A
B
Yeah,
so
that's
one
of
the
that's
one
of
the
problems
that's
going
to
arise
and
we
had
that
in
glass
fish.
So,
for
example,
we
had
to
cut
out
something
called
fighter
fish
which
was
an
osgi
component
of
glass,
fish
that
deployed
osgi
bundles
and
that
obviously
still
depended
on
javax
servlet.
So
we
had
to
cut
fighter
fish
out
until
osg
moves
when
it
comes
to
glass
fish,
that's
going
to
be
a
problem
when
it
comes
to
other.
B
B
Yeah
I
mean
for
for
us
as
a
player
and
pr
I've
got
actually
a
slide
in
the
keynote,
so
we're
detecting
or
we're
going
to
detect,
jakarta
namespace
applications
and
run
them
through
the
transformer
as
part
of
the
deployment
step
and
then
actually
deploy
those.
So
they
will.
Basically,
the
transformer
project
is
on
the
fly:
transforming
com
pieces
into
the
new
namespace.
B
B
Yeah,
so
j
cash
is
not
in
dry
control,
because
j
cash
is
still
in
the
jcp.
As
far
as
I'm
aware,
I
would
be
supportive
of
it
being
moved
but
and
incorporated
into
ee9,
but
not
e9
into
a
later
ee
release.
How
is
actually
a
lot
of
work
to
do
on
that,
because
it's
an
se
specification,
so
it
doesn't
cover
a
lot
of
the
sort
of
ee
models
and
things
like
that
or
we
create
a
new
one.
B
B
B
B
B
Yeah
I
mean
we,
we
were
playing
with
our
because
the
tech
preview
is
not
obviously
e9
compatible
and
we
had
a
fully
qualified
name
in
one
of
the
servlets,
so
in
web.xml,
which
which
we
should
be
transforming.
But
we
hadn't
got
that
for
yet,
but
yeah
they've
got
to
be
watch
those
strings,
really
those
opaque
strings
and
service
definitions
or
in
web.xmls
those
things,
especially
things
like
for
jsf,
where
people
have
got
jsf
servlet
filters
and
things
like
that,
where
they
put
in
directly.