►
From YouTube: 2019-09-27 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).
B
A
C
True,
so
maybe
we
could
do
that
and
the
span
adapter,
even
if
nobody's,
calling
and
span
adapter.
Yet
that's
a
good
idea,
maybe
yeah.
That's
a
good
idea.
So.
A
A
A
Do
you
want
to
sit
well,
let
me
get
that
so.
Yes,
let
me
get
that
branch
happy
again
with
the
rework
and
the
repackaging.
I
think
it'll.
Take
me
another
I'm,
hoping
20
minutes
and
then
I'll
push
that
to
something
that
means
mean
something
and
then
maybe
you
can
grab
the
conversion
know
that
we
have
maintance
Bob,
so
yeah.
A
A
A
D
C
E
A
Yeah,
so
we
we
were
Jason
before
everyone
else
showed
up
with
Jason
and
I
were
just
kind
of
strategize.
The
next
step,
so
I
think
we're
gonna,
go
and
put
up
in
a
follow
up
PR
that
will
have
some
tweaks
to
the
readable
span
and
an
adapter
that
turns
readable
spans
into
span
data
as
the
next
step,
and
then
the
third
step
will
be
to
actually
wire
that
up
into
the
exporter
and
the
processor
pipeline.
Okay,.
E
E
This
is
something
oh.
This
is
something
that
I
want
to
discuss
with
everyone.
I
was
spending
time
on
this
D
I.
Think
and
the
idea
is:
should
we
not
provide
a
manifest
file
in
the
in
the
SDK
and
not
provide
the
provider
in
the
SDK
and
then
every
exporter
or
every?
We
will
have
different
artifacts.
That
will
provide
the
the
initialisation
and
everything
that's
an
option
or
the
other
option
is,
we
add
setters
for
all
the
properties
in
the
SDK,
and
we
give
the
SDK
to
to
be
able
to
initialize
itself.
D
A
Yeah
yeah,
so
this
one
yeah
this
one
in
particular,
was
so
right
now.
The
way
that
the
SDK
can
be
configured
is
essentially
only
the
service
provider
SPI
via
system
properties,
mm-hmm,
and
that
feels
very
restricted
to
me
and
I'd
love
to
have
a
builder
for
the
SDK
and
then
have
a
like
a
shim
or
an
implementation
or
a
helper
or
something
that
would
do
the
SPI
work
based
on
system
properties.
Just
because
I
know
that,
like,
for
example,
all
the
services
we
have
it
here
at
New,
Relic
wouldn't
be
using.
A
So
we
would
so.
The
engineers
would
probably
just
create
a
created
in
a
set
up
for
the
SDK
in
the
actual
application.
It
was
probably
based
on
some
custom
environment
variables
from
our
internal
build
and
deploy
system,
but
a
lot
of
and
the
host
names
and
things
like
that
which
I
want
to
put
on
to
the
resource,
would
have
to
be
just
come.
Programmatically
from
I,
not
I,
not
address,
get
localhost
all
right,
but
but
would.
A
C
C
I,
don't
know,
does
it
have
implications
around
containers?
Sorry
I
mean
like
servlet
containers.
A
A
E
A
I
agree:
I,
agree
with
that,
but
I
wish
there
were
some.
There
were
a
middle
ground
where
he
could
have
like
a
application,
local
that
wasn't
shared
across
everything,
but
but
maybe
that
maybe
maybe
the
right
solution
is
to
not
have
we
like.
We
don't
provide
a
global
tracer,
but
let
people
build
those
Singleton's
themselves
as
they
need.
E
But
but
the
problem
is
then:
every
third
party
library
will
need
to
accept
this
because
yeah
yeah
you're
right
there
is.
There
is
no.
We
will
force
every
third
party
library
to
have
an
API
to
set
this
and
expose
this
in
their
public
API,
which
they
may
not
feel
comfortable.
Exposing
somebody's
a
mistake,
no.
A
E
Mean
we
still
have
I
mean
we
have
this
global
by
default,
but
people
can
still
manually
patch
it.
So
that's,
there
is
no
question,
I
mean
every
a
bunch
of
people
were
asking
me,
but
you
have
an
instance.
You
can
pass
it
if
you
want,
there
is
no
necessary
requirement
to
use
the
global.
If
you
don't
want.
A
A
E
E
Okay,
I
did
generator,
is
fine,
okay,
I
think
we
should.
We
should
address
Kevin
comments,
but
I'm,
focusing
more
on
finishing
the
api's
that
we
have
API
and
SDK
and
all
the
API
level
public
things.
So
then,
more
than
fixing
all
this
manner,
but
I
will
need
you
to
take
a
look
probably
next
week
on
this
Carlos
welcome.
E
E
E
We
we
still
have
to
offer
more
custom,
custom,
setters
and
custom
builders
for
the
traces
SDK,
because
people
are
asking
for
setting
trace
ID
generator
because
they
want
to
use
it
with
AWS
or
resources
or
stuff
like
that
that
we
we
mentioned
that
will
allow
people
to
do
it,
but
we
do
not
really
have
an
API
for
that.
But
that's
mostly
on
the
SDK
side
and
my
priority
for
this
week
is
the
the
public.
Api
I
saw
your
CL
about
your.
E
One
thing
that
I
want
to
discuss
with
everyone
is
this
memory
issue
that
I
have
in
mind.
So
the
issue
is
the
following:
we
allow
people
to
add
lazy
events,
lazy
attributes,
but
lazy
means
the
values
are
lazily
formatted,
which
means
the
object
that
the
formatter
object
may
hold
a
lot
of
memory.
Okay,
it
means
that,
for
example,
I
have
a
five
megabytes
object
and
I
just
wrap
it
in
the
formatter
and
then
later
I
will
look
into
the
object
and
keep
the
tracing
system.
E
The
informations
from
this
object,
so
I
hold
an
extra
reference
to
the
initial
object
for
as
long
as
the
span
exists
because,
whatever
I'm
not
I,
don't
want
to
pay
the
cost
on
critical
path
to
to
forego
to
do
the
formatting
and
everything
in
our
current
implementation,
we
do
convert
everything
into
proto,
which
means
at
that
moment
we
remove
all
the
we
remove,
all
the
reference
to
the
objects
that
use
our
hat.
So
so
because
that's
a
completely
different
object.
E
E
E
E
With
lazy
formatting
so-
and
there
is
an
another
question
that
I
have
that's-
that's
one
possibility.
The
other
question
that
I
have
is
in
our
current
public
API
for
supporting
lazy
events.
We
do
have
event
as
an
interface.
Let
me
show
you
so
we
do
have
event
as
an
interface,
which
means
people
can
override
this
interface
and
override
the
get
name
and
get
attributes
part
of
it
makes
sense.
So
they
can,
they
can
do
any
kind
of
crazy
lazy
configuration
of
every
property,
but
I
feel
like
in
this
way.
They
have
to
write
true
methods.
E
Another
option
would
be
to
go
with
other
what
other
languages
do
and
have
this
as
a
concrete
class
and
have
a
event
formatter
and
instead
of
our
API
on
the
span,
accepting
an
event
so
currently
here
people,
if
the
one
will
have
an
anonymous
class
or
a
lambda,
do
they
will
have
to
write
a
lot
of
code
here
because
they
have
to
override
two
methods:
correct.
They
actually
cannot
do
a
lambda
here.
They
they
have
to
override
three
two
methods.
E
A
E
A
E
D
E
I'm
happy
I
mean
Taylor.
To
be
honest,
we
promise
that
until
generally,
we
can
break
the
API
as
well
much
as
we
want
so
I
I
would
not
yes.
If
this
would
have
been
a
stable
release.
I
would
agree
with
you.
That's
the
right
strategy,
but
because,
because
we
are,
we
have
until
January
to
make
breaking
changes.
I,
don't
care
or
do
you
think
do
you
feel?
Is
the
right
mindset
or
I
mean.
D
E
Intent
is
the
following:
usually
the
name
will
be
the
name.
You
will
not
have
troubles
to
to
to
know
it,
but
the
problem
is
a
lot
of
the
values
inside
the
attributes
may
be
things
that
we
don't
know
you
you
have
to
like
use
some
print,
apps
and
stuff
like
that,
and
you
you
try
to
avoid
doing
that
on
your
serving,
and
then
you
put
it,
you
put
a
formatter
and
then
later
when
we
need
only
when
we
need
it.
E
D
E
D
E
D
B
E
E
Http
and
for
other
things
is
very
common
and
what
you
will
say
will
save
couple
of
logs
because
I
mean
you're
not
gonna
have
contention
on
that
loads
because,
usually
you
just
created
the
span
and
you
talk.
You
will
call
set
attributes
couple
of
time
so
that
method
isn't
gonna,
probably
be
synchronized
at
one
point,
because
you
cannot
implement
it
log
free
completely.
E
B
E
B
E
B
B
E
Yeah,
a
lot
of
the
contention
part
like
the
yesterday
contention,
I
spend
yesterday
or
an
hour
and
a
half
with
couple
of
people
from
Microsoft.
A
lot
of
contentions
were
about
the
fact
that
for
for
distributions
or
for
yeah
what
people
calling
in
general
distributions,
we
do
not
let
people
select
any
aggregation
so
in
the
public
API
people
will
just
tell
us
that
hey
this
will
be
a
distribution.
E
I
will
give
you
samples
all
the
samples
for
these
distributions
of
values,
but
I'm
not
telling
you
what
you're
gonna
build
a
histogram
or
a
summary,
or
anything
like
that.
This
was
very
contentious,
because
people
had
trouble
understanding.
Why
do
we
not
want
to
allow
the
developer
that
instruments
the
code
to
to
define
aggregation.
D
I
think
so
so
so
like,
for
example,
is
it
is
the
data
that
they're
collecting,
because
I
guess
so,
for
example,
our
if
somebody
is
using
something
like
drop
Wizard
metrics
that
already
has
some
level
of
distribution.
Yes,
so
in
to
report
that
or
export
that
to
our
API.
That
won't
be
possible
with
the
current
design,
correct.
E
So
one
thing
that
I
was
keep
telling
people.
The
other
contention
point
was
like
I'm,
not
expecting
you
to
be
able
to
export
to
our
ecosystem
by
our
API.
The
API
is
for
directly
recording
it
your
code,
but
if
you
are
trying
to
read
report
something
that
other
system
aggregates
and
does
for
you,
you
should
use
directly
the
exporter
pattern.
Not
not
our
public
API.
E
E
That's
that's
that's
my
that's
my
problem,
and
that
was
one
of
the
connection
point,
the
other
one
with
this
distribution
thing,
so,
yes,
drop,
wizard
or
micrometer
on
you.
Allow
you
to
set
up
Bacchus
form
histogram,
even
saying
this
is
a
histogram.
This
is
a
summary,
the
summary
being
the
one
with
calculated
directly
the
percentiles.
So
all
of
these
things
are
allowed
in
in
all
the
other
API
premier,
just
as
well,
and
everything
and
I
said
no.
E
Let's
and
the
idea
is
we
the
the
for
example,
the
GRDC
developer
that
instruments
GRDC
with
us
they
will
not
have.
They
will
not
know
if,
if
the
system
that
people
will
use
our
data
support
summaries
or
are
gonna
support,
histograms,
because
not
not
all
the
system
support
both
and
and
also
what
are
the
right
packets
for
the
histograms
and
so
on.
E
So
we
said
at
the
API
level
the
person
who
is
giving
us
the
data
should
not
decide
what
kind
of
aggregation
we
will
do
with
that
data
and
then
and
then
the
SDK
level,
the
person
who
runs
the
application.
We
will
let
them
configure
for
every
measure
that
was
recorded
with
us,
whatever
they
want
to
do
with
it.
They
wanna
build
summaries.
Tell
us,
for
you,
can
tell
us
for
a
global
for
all
the
measurements
will
produce
this
summary
or
you
can
tell
us
for
individual
ones
same
for
histograms.
Sorry
for
the
empathy.
A
Yeah,
this
is
actually
interesting.
Having
just
worked
through
writing
exporters
for
micrometer
and
drop
wizard
and
writing
apps
that
use
them
to
exercise
them.
The
my
I
think
my
my
only
question
would
be
the
discoverability
of
the
instrumentation,
so
I.
Imagine
that
there's
gonna
be
some
sort
of
like
a
sample
interface
that
you
could
add
stuff
to
like
hey
we're
here's
this
thing,
that's
sampled,
you
can
add
samples
to
it
right
and
then,
on
the
back
end,
the
application
developer
decides
I,
wanted
this
sample.
A
This
sample
thing
to
be
represented
as
a
distribution,
and
this
sample
thing
to
be
a
summary
and
the
sample
thing.
It's
a
grant
or
something
like
that.
But
the
discoverability
is
what
I'm
not
sure
like
how
are
they
gonna
know.
How's,
the
application
developer
know
what
the
libraries
are
using.
Isis
are
actually
getting
what
sort
of
sample
things
are
being
export,
but
but.
E
Before
before
you
had
another
problem
correct
before
you
had
the
problem
that
if
somebody
instruments
their
app
with
a
thousand
Prometheus
metrics,
you
know
you
have
zero
way
to
control
that
there
will
not
be
exported,
but
yeah
yeah
absolutely
know
for
sure.
So
that
was
the
opposite
problem.
I
think
the
way
how
we
want
to
do
it
on
the
sdk
we
will
we'll
have
an
api
to
say.
Give
me
show
me
all
the
the
components
and
every
component,
all
the
gauges,
all
the
counters,
all
the
distributions
metrics.
E
E
Then,
and
then
for
every
one
we
can
go
and
say:
hey,
but
we'll
give
you
a
readable,
whatever
we'll
give
you
another
API
directly
to
the
metric
or
even
the
metric,
but
we'll
give
you
more
things
like
enable
this
metric
or
disable
this
metric
and
set
this
aggregation
remove
this
equation.
Whatever
will
you
give
you
a
lot
of
like
control.
A
E
All
the
control
with
our
stuff,
we
will
have
even
adding
more
from
the
context
we
do
have
a
more
powerful
than
micrometer
they
cool
cool,
but
the
problem
is
user,
accept
the
difference
with
micrometer,
and
we
can
do
this
as
well
so
and
I'm.
Now
not
sure
if
this
is
the
right
thing,
but
should
we
just
have
a
an
API
that
sells
enable
default
aggregations
for
all
the
metrics
in
your
in
my
app.
This
is
mostly
for
lazy.
People
probably
should
have
something
like
that.
Yeah.
A
D
E
To
the
exporters,
I
think
I
think,
based
on
a
long
conversation
and
a
lot
of
people
blaming
me
to
use
Pro
Tools
we're
gonna
use
modules.
Unfortunately,
because
everyone
complained
that
we
bring
to
my
too
many
dependencies
into
the
into
the
SDK.
So
we
should
limit
that
so
we'll
have
equivalent
definitions.
The
way
how
the
the
guys
Karl,
John
and
Jason
are
doing
for
the
for
the
span
date
I
will
do
a
matrix
theta.
The
format
is
very
close
to
what
Prometheus
has
or
what.
D
E
D
Yeah
daily
dog
generally
has
stats
t
kind
of
API.
I
am
honestly
pretty
ignorant
to
it.
I'm,
not
an
expert
on
our
metrics
side
of
things,
so
I
can't
really
give
good
feedback
there.
I
do
know
that
we
recently
released
a
new
style
of
a
different
style
of
like
histogram,
a
data
representation
of
that
histogram.
That
might
be
interested
for
consideration.
Can
you
show
me
yeah
I'll,
send
you
the
link,
but
supposedly
it
has
a
better,
a
better
fitting
for
the.
D
E
I
mean
I'm,
not
I'm,
a
big
supporter
of
this,
and
also
we
can
support
multiple
types
now
that
we
do
not
have
to
offer
to
enforce
all
the
instrumentation
to
decide
of
the
format
and
everything.
This
is
a
good
advantage
that
we
can
add
any
type
we
want
later,
and
that
just
say
just
tell
the
application
owner
hey
by
the
way
we
have
a
new
type
for
histogram.
You
may
want
to
use
this
one
for
your
histograms
without
having
to
change
the
code
in
trpc2
record.
The
new
histogram.
A
D
B
E
B
C
A
D
E
E
D
D
E
B
E
B
E
It's
10
level
because
we
still
mean
something
into
the
specification.
So
one
thing
that
we
need
to
do
is
we
have
to
implement
the
name.
Tracer
RFC,
which
you
got
merged
and
the
most
likely
is
going
to
be
approved.
The
specs
were
written
for
that
yep
and
there
are
a
bunch
of
other
things
that
you
need
to
implement.
But
yes,
okay,.
B
D
E
That
that's
my
that's
my
thing
as
well.
I
also
consider,
by
the
way,
currently,
we
should
probably
have
called
everything:
every
snapshot
as
alpha
b
0
1,
the
the
based
on
the
document
that
sergei
published
on
specs,
I
think
or
on
the
community
I,
don't
remember
where
he
calls
the
the
version
on
10
11,
alpha
D,
0
2
that
we
are
aiming
for.
So
maybe
maybe
we
prefix
all
our
snapshot
with
alpha
v,
0
1
right
now
and
then
on
11
10,
11,
we'll
publish
it
with
alpha
B
0,
2,
okay,
yes,
that
should
be.
E
B
C
E
D
A
E
D
So
I'm
I
think
more
intended
a
a
resource
right
now.
My
my
allocation
is
still
pretty
heavily.
You
know,
fixing
bugs
and
making
customers
happy.
Most
of
my
time
with
open.
Telemetry
is
still
you
know
just
taking
out
of
my
day,
so
III
don't
think
I'll
have
a
lot
of
time
to
actually
commit
to
it.
Although
I
guess,
indirectly,
a
little
bit
I
I
did
meet
with
Trask
yesterday
to
kind
of
discuss
ideas
that
I
had
for
for
a
going
forward,
but
yeah
the
amount
of
coding
that
I'll
actually
get
to
do
is
probably
minimal.