►
From YouTube: 2019-10-18 Java SIG
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
Was
it
New
Relic
service
thing
it
was,
but
it
was
specifically
for
our
java
group.
Well
what'd,
you
guys.
Do
we
went
to
a
local
charity
and
built
furniture
thanks
yeah,
so
it's
the
community
warehouse
not
sure
how
familiar
you
are.
The
Portland
Authority
that
helps
people
that
just
received
housing
assistance
to
get
furniture,
cool.
A
What
Saipan
yeah
versus
I
can
well
when
I
was
in
Saipan
last
year,
typhoon
came
in
wiped
out
the
island,
and
so
the
place
I
was
staying.
Did
we
have
a
full
roof?
So
it
was
time
for
us
to
go.
I
see.
B
D
C
A
E
D
E
C
D
F
B
E
F
E
D
D
E
C
D
A
D
B
On
a
related
note,
Austin
and
I
are
adding
some
code
to
the
website
on
the
project
Status
page
to
pull
the
latest
release
from
each
sig,
so
that
there's
just
a
handy
reference.
People
looking
on
the
website
when
you're
all
are
ready.
She
wouldn't
mind
making
a
github
release.
I
know
that's
probably
an
extra
step
for
Java,
since
you
guys
don't
actually
use
them,
but
it
would
be
a
helpful
way
to
tract
things
on
the
website
automatically
by
the
way
is.
D
It
anywhere
documented
how
to
do
this,
because
I
mean
personally
I
would
prefer
to
do
a
branch
release
and
then
tagged
the
branch
release,
just
as
a
normal
thing
to
do
to
do
for
four
versions,
but
sometimes
I
saw,
for
example,
a
lot
of
Gore
code
that
they
just
tagged
on
the
master.
What
what
exactly
is
the
process
that
we
want
to
follow?
Is
that
something
that
we
should
document
somewhere?
That.
D
C
D
D
D
A
I
mean
we
don't
have
to
have
a
long-lived
branches,
for
each
of
the
releases
is
what
I'm
trying
to
say.
We
see
the
branch
can
be
temporary
just
for
the
purpose
of
doing
the
patch
release.
I
do
like
having
the
the
tag
actually
on
the
master
commit
because
then,
when
you're
looking
at
the
history,
you
can
see
exactly
where
the
the
release
tags
are
at
I.
D
A
A
D
I
can
help
with
that.
So
so
there
are
multiple
reasons
why
you
want
to
have
it,
but
conceptually
what
it
does
is
the
following
inside
an
application.
You
have
a
bunch
of
libraries,
so
you
want
for
every
library
or
for
every
component
inside
your
application
to
have
a
different
name
that
describes
that
component.
So
imagine,
for
example,
you
are
using
TI
PC.
D
Where
then
allows
you
inside
to
have
similar
names
in
different
components,
and
one
of
the
clear
example
will
be
somebody
calling
the
metric
latency
and
without
having
without
having
this
name.
Tracer
is
gonna,
be
a
conflict
with
other
metric
name.
Latency
doesn't
make
sense,
but
that
does
make
sense.
A
So
the
way
that
I
think
light
step
in
indeed
a
dog
has
kind
of
remedied
that,
on
the
open
tracing
side
was
traditionally
just
like
setting
the
service
name
on
the
spam
on
creation
component.
Maybe
that
doesn't
work
as
well
for,
like
the
the
metric
situation,
so
I
I
do
see
how
the
the
current
design
would
be
beneficial
in
that
regard.
So.
D
Name,
meter,
okay,
yeah,
so
the
other
advantages
are
things
like
you
can
push
some
implementation
because
of
the
name
tracer
and
not
having
it
as
an
attribute
can
push
different
configs
to
two
different
components:
things
like
can
disable
all
the
spans
I
can
disable
G
RPC
to
clean
your
spans.
Even
though
you
have
the
plug-in,
for
example,
you
can
disable
only
that
specific
part
of
the
growth
does
it
make
sense
and
yeah.
This
is
something
that
dynaTrace
wanted
very
badly
for
whatever
reasons
I
think.
B
A
A
D
B
We
have
like
sort
of
high
reaching
goal
in
the
0.3
version
of
the
spec
to
see
if
we
can
fully
separate
out
contacts,
propagation
and
baggage
into
their
own
separate
subsystems
for
baggage.
It's
just
because
propagating
user
data
and
propagating
observability
data
it
gets
confusing
if
you're
doing
it
kind
of
mushed.
Together.
People
have
always
been
uncomfortable
with
that,
and
if
we
can
separate
out
context
propagation
fully
from
tracing,
then
it
makes
it
reusable
between
both
observability
and
baggage
and
then
potentially
other
systems,
and
so
this
has
been
I.
B
B
However,
I
think
just
from
writing
the
spec
in
English
I
can
tell
that
as
soon
as
we
start
working
on
implementations,
a
whole
bunch
of
education
and
concerns
are
going
to
pop
up
with
a
change
like
this,
in
particular,
named
tracers
I
think
are
gonna.
Make
this
a
little
more
complicated
and
right
now
context.
Switching
and
context
management
is
tied
pretty
tightly
to
span
management,
so
I
see
those
as
two
areas
where
I
really
prefer
to
see
us
actually
trying
to.
B
Like
spike
code
and
wrap
our
heads
around
some
of
this
stuff,
because
otherwise
I'm
afraid
we're
gonna
merge
something
into
the
spec
and
then
be
like
wait.
What
does
this
mean
so
I'm
trying
to
get
sort
of
a
working
group
cross
language
working
group
together
to
kind
of
hash?
Some
of
these
issues
out
I
think
it
would
be
great
to
get
someone
from
Java
involved,
because
I
think
you
know,
Java
makes
everything
complicated
and
I
expect.
D
B
So
what
I'm
looking
for
is
like
someone
to
try
to
prototype
this.
You
know
enough
that
we
actually
can
sort
of
sort
out
where
the
problem
areas
are
gonna,
be,
and
so
that
when
we
actually
merge
this
spec
in
it
sort
of
addresses
all
of
this
stuff.
This
is
partially
some
feedback
from
named.
Tracers
came
from
this,
where
that
got
merged
into
the
spec,
and
now
people
are
trying
to
implement
it
and
there's
like
a
bunch
of
questions
are
coming
up
and
I'm
concerned.
I.
E
B
D
B
B
I
would
like
to
abort
before
we
like
put
it
into
the
spec,
but
I
would
prefer
us
to
actually
pull
off
this
like
high
reaching
goal.
I
think
you
know
it
would
really
benefit
the
ecosystem.
If
we
could
separate
these
things
out,
so
I
created
a
get
a
room,
they
seem
to
work
for
the
metrics
discussion.
So
this
is
it
a
room
to
kind
of
discuss
this
and
yeah
I'm
just
going
around
asking
people
they're
interested
to
try
their
hand
at
it.
D
B
B
Yes,
so
I'm
going
around
just
trying
to
wave
my
hands
at
all
the
different
SIG's
so
that
people
are
aware
that
this
is
coming
cool,
so
yeah,
it
asked
people,
you
know,
have
a
read
of
that:
spec
proposal,
it's
a
very
high
level
proposal
and
then,
if
you're
interested
in
working
on
it,
you
know
join
the
room
and
we've
got
people
from
Python
and
nodejs
and
stuff
in
there.
Right
now
do.
B
That's
exactly
it
if
we
can
pull
this
off,
it
makes
it
a
lot
easier,
potentially
to
share
some
kind
of
context,
object
with
G,
RPC
and
other
projects
and
maybe
even
pull
it
out
of
open
telemetry
as
this
sort
of
shared
lower
layer
right,
that's
a
thing!
That's
come
up
where
we're
like
you,
we
don't
want
to
use
G
our
pcs
context.
That's
weird
I
can
imagine
other
people
kind
of
saying
the
same
thing
like.
Why
am
I
like
piggybacking,
my
security
concerns
or
network
switching
propagation
stuff.
On
top
of
this
observability
system,.
B
D
B
Think
the
issue
is
if
we
can
get
this
fully
separated,
at
least
in
our
own
code
base,
it'll
be
easier
to
just
have
conversation
with
G,
RPC
and
other
people
about
maybe
a
neutral
place
to
put
that
stuff
right.
They
didn't
want
to
move
it
into
open,
telemetry
and
I
feel
like
we
don't
have
our
story
straight
enough
that
we
wanted
to
encourage
them
to
make
some
big
change
on
their
end.
So
I
prefer
us
to
have
some
cleanly
architected
thing
before
we
tried
it
like
convinced.
D
A
A
D
We
cannot
abstract
everything
out
unless
we
do
our
own
abstraction
mm-hmm.
So
so
we
still
need
an
abstraction,
because
from
the
API
standpoint
you
did
you
still
need,
for
example,
if
you
are
implementing,
let's
say
executors
or
something
like
that,
we
need
to
wrap
the
entire
context
with
all
the
items
there.
So
you
need
to
have
a
notion
of
context
that
includes
multiple
key
values
and
if
that's
not
G
RPC,
then
we
need
to
come
up
with
our
own
okay.
A
D
D
A
D
Two
motivations,
if
you,
if
we
do
have
a
time
step,
object
that
we
had.
We
need
to
provide
a
lot
of
helpers
like
from
nanos
from
Millie's
and
a
bunch
of
other
things
in
order
to
make
it
correct,
and
we
already
saw
some
bad
usages
by
doing
divisions
and
stuff
I
think
we
should
use
holder
I
mean.
Essentially,
we
have
to
copy
the
whole
Java
instance.
If
we
want
to
be
if
we
want
to
have
our
own
time
step,
that's
good
to
do
the
correct
math
of
not
overflowing,
and
so
on.
A
D
A
A
A
D
A
higher
requirement
from
Google-
and
this
comes
from
the
fact
that
we
want
to
be
directly
into
GRDC
like
by
having
them
because
we
use
internally
T
RPC
and
we
want
to
not
have
user
to
install
plug-ins
for
anything
and
because
of
that
G
RPC
has
a
requirement
to
be
Java
7.
So
that's
why
we
are
Java
Sam.