►
From YouTube: 2020-09-03 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
I've
been
all
right,
does
your?
Does
your
family
call,
you
cam,
or
is
it
all
just
cameron.
B
Short
story
is
I
go
by
my
middle
name
outside
of
work,
which
is
shane.
Oh
that's
interesting,
so
friends,
family
old
acquaintance.
B
B
What's
in
a
name,
yeah
yeah,
I
move
west
and
you
know
when
you
go
by
your
middle
name.
You're
always
correcting,
like
you
know
your
first
day
of
school.
Weird
like
that,
you
know
it's
like.
Oh,
I
I'm
that
guy.
So
I
stopped
correcting
when
I
moved
out
here
and
started
to
see
how
well
it
fit.
You
know.
That's
all
right.
A
B
A
Yeah,
so
this
is
cameron
cameron,
thomas.
He
is
one
of
our
android
agent
engineers.
B
Yeah
we're
we're
currently
interviewing
trying
to
get
some
more
help.
It's
we
have
one
ios
guy
and
one
android
guy
to
hold
down
the
fort.
It's
kind
of
always
been
that
way,
but
with
a
bigger
team,
we've
had
help.
C
How
many
is
the
number
of
users
android
ios
users,
public.
B
That's
a
good
question,
I
don't
really
know,
but
recently
we
were
doing
some
analysis
on
traffic
and
it
started
to
look
like
android
has
surpassed
ios,
which
had
always
we
just
always
assumed
we
had
more
ios
users
based
on
support,
tickets
and
features,
and
things
like
that,
and
so
it's
a
little
surprising
and
it's
increasing.
B
So
I
don't
know
what
that.
What's
that
saying,
maybe
there
are
just
more
android
development
going
on.
I
I
would
imagine.
C
Yeah,
that
is
interesting
trend
and
yeah.
Let's
let
me
pull
up
the
thank
you
for
adding
the.
D
C
Yeah,
let's
chat
about
android,
so
we
were
so
we're.
Looking
at
kind
of
what
libraries
we
should
instrument
sort
of
what
android
support
would
look
like
for
open
telemetry,
both
from
an
sdk
perspective
of
people
manually,
doing
custom
telemetry.
A
C
Well,
as
from
sort
of
an
auto
instrumentation
perspective,
I
understand
you
know
we
can't
run
a
java
agent
on
android,
but
so
or
you
could
compile
compile
time
byte
code,
possibly
yeah
and
or
provide
sort
of
wrapper
libraries
like
http
listener
that
then
tracks
that
they
can
android
developers
can
manually
add
to
their
app
yeah.
A
B
Deliver
so
the
most
important
aspects
of
the
android
agent
are
recording
network
requests.
I
mean
because
that's
what
all
apps
are
doing
at
some
point
and
crash
detection
and
reporting.
Those
are
the
number
two
but
inter
but
you're,
really
asking
more
about
instrumentation,
so
I'll
try
to
stay
more
on
focus
there.
B
The
other
thing
is:
we
tend
to
auto
instrument,
our
local
storage,
so
a
sqlite
database
shared
preferences,
things
like
that,
you
you
could
we
we
don't
instrument
that
currently,
then
the
other
things
are
sort
of
some
special
runtime
classes,
such
as
the
what
is
it
called
async
asynctask,
which
is
another
sort
of
convention
with
developers
that
we
and
customers
have
found
a
lot
of
value
in
and
it
rate
and
the
other
side
of
that
is,
you
know,
since
the
android
agent,
I've
been
working
on
it
for
over
five
years
and
it
predates
me
a
lot
of
things.
B
It
started
with
have
kind
of
been
gleaned
out
of
our
ability
to
to
fetch
the
data,
and
I'm
thinking
specifically
of
some
things
like
cpu
some
cpu
metric
data,
it's
kind
of
been
put
off
onto
the
backlog
now
like
we're
still
looking
at
ways
to
gather
more
runtime
information
like
that.
However,
customers
don't
seem
that
interested
in
that
kind
of
thing
there
are
other
other
means
of
getting
it.
We
still
report
things
like
disk
and
memory,
especially
when
we
have
a
crash.
B
That's
when
things
like
that
are
most
important,
so
I
guess
the
point
I
was
getting
to
is
android
is
like
upping
their
game
with
security
and
kind
of
tightening
down
some
of
the
data
that
we
have
access
to,
and
that's
that's
pretty
much
the
state
of
it
now
we're
looking
to
kind
of
revisit
the
entire
instrumentation
realm
just
to
make
sure
our
assumptions
are
still,
you
know
valid,
see
if
there's
things
we're
missing.
B
One
of
the
temptations
in
the
past
has
always
been
more
instrumentation
of,
say,
third
party
frameworks
and
that
kind
of
looks
good
on
paper.
But
you
know
all
third
party
frameworks
are
still
kind
of
composed
of
say
the
fundamental
network
request
io
stacks
things
like
that,
which
we've
already
covered,
so
the
data
is
there.
It
may
just
not
be
presented
in
an
optimal
way
for
a
third
party
framework.
C
B
No,
no,
no,
we
to
your
earlier
question.
How
do
we
do
it?
We
we
do
build
time
by
code
injection,
so
what
we're
doing
is
injecting
delegates
for
you
know
it's
not
even
that
many,
it's
probably
fewer
than
10
our
http
interfaces
that
we
have
to
delegate
to,
and
that
gives
us
pretty
much
everything
all
of
the
you
know
advanced.
B
B
C
The
call,
but
it's
it's
still
specific,
instrumentation
to
okay,
http.
C
Okay,
and
do
you
do
you
propagate
distributed
tracing
headers.
B
Yes
and
no,
the
mobile
agent
was
one
of
the
first
products
in
new
relic
to
integrate
distribution.
However,
it
was
in
a
pre,
1.0,
state
pre-release
and
for
whatever
reason,
it
was
decided
that
we
were
going
to
disable
it
and
it's
never
been
re-enabled
and
I
I
I
feel
that
it
will
probably
be
re-enabled
very
soon,
whether
it's
our
current
implementation
or
something
else.
We
may
rework
the
whole
thing
so
so
the
yes
part
is
yeah.
We
still
have
some
headers
in
there.
C
C
For
the
oh,
do
you
have
a
public
doc
sort
of
of
what
I
could
probably
just
google,
that
cool
yeah?
I
would
kind
of
curious,
specifically
what
other
instrumentation,
what
other
libraries
are
popular
enough
in
the
android
ecosystem
that
you
have
that
you
are
instrumenting.
It.
B
You
know
we
were
we
used
to
do
an
apache
stack
and
once
android
kind
of
shifted
away
from
that
to
okay,
http
demand
fell
way
off,
turned
to
be
like
very
edge
casey
customers
who
just
didn't
want
to
get
around
to
migrating
their
code,
so
that's
actually
been
deprecated.
I'm
trying
to
think
of
what
else
we
do.
C
And
what
what
layer,
where
do
you
is
that
is
the
network
layer,
is
that
a
library
provided
by
android.
B
Cool
okay,
I
should
I
should
back
that
one
off,
first
of
all,
okay
http,
is
had
and
has
been
for
a
couple
years.
The
default
networking
stack
it's
just
kind
of
obfuscated
as
http
url
connection,
so
the
implementation
is
okay,
http
now,
in
addition,
you
know
most
users
of
okcp
go
directly
to
their
jars,
and
so,
when
we
see
those
come
through,
we
do.
You
know
build
time
where
we're
going
a
sweep
all
the
classes.
B
Looking
at
the
signatures
as
they
come
through,
and
when
we
see
okay
http,
we
we
instrument
them
correctly
and
if
we
see
http
url
connections
come
through
we're
instrumenting.
Those
also
at
that
point
we're
not
going
to
dive
down
knowing
you
know
kind
of
contextually,
knowing
that
it's
android
we're
not
going
to
dive
down
and
and
say
doubly
instrument,
we're
just
going
to
take
the
top
level
interface.
C
Okay
and
users
and
android
users
typically
use
okay,
http,
yeah
or
http
url
connection
directly.
B
C
B
I
mean
the
frameworks,
you
know,
as
I
just
mentioned,
before
kind
of
wrap
that
stuff
they
might
have
a
certain
certain
patterns.
They
won't
want
to,
you
know,
create
as
part
of
their
interface,
but
you
know
they're
all
making
calls
to
default
stacks.
C
I
see
and
how
do
you,
how
do
you
do
http,
url.
C
C
Pulsates
cool:
oh,
how
does
the
crash
detection
and
reporting
is
that
part
of
is
that
exposed
by
the
android?
Like
does
android
have
a
java
like
you
can
yeah.
B
B
B
Right
we're
just
using
the
adk
directly
when,
when
an
app
starts,
they
start
the
agent
when
the
agent
starts.
One
of
the
things
we
look
at
is:
is
there
currently
a
handle
handler
sitting
there
and
sort
of
manage
a
handler
chain,
so
that
should
a
crash
and
then
handle
exception,
make
it
to
our
handler
we'll
gather
all
of
our
data
kind
of
persisted
as
needed
and
then
follow
it
down
the
chain
and
following
it
down
the
chain,
is
what
results
in
a
crash
for
android
and
you'll.
B
B
B
So
you
know
the
the
sort
of
line
I
was
thinking
is
custom
is
you
know,
you've
got
a
new
network
stack
or
something,
and
you
want
to
instrument
those
so
currently,
there's
no
way
of
doing
that.
That
would
be.
You
know.
We
have
discussed
it
quite
a
bit
in
the
past,
but
the
amount
of
work
involved
is
just
never
fit
into
priorities.
B
C
How
about
like
the
new
relic,
the
java
api
that
the
the
java
agent
supports,
where
you
can
call
you
know,
methods
on
that.
B
There's
yeah:
we
don't,
we
don't
use
that
agent
and
we
don't
follow
their
api.
Probably
would
have
a
good
idea.
I
mean.
C
C
There's
no
so
the
only
support
there
for
anything:
that's
not
auto
instrumented
like
okay,
http,
hcp,
url
connection,
etc.
That
is
the
trace
annotation.
C
C
B
C
C
Cool
yeah,
but
like
real,
like
like
end
user,
so
we're.
F
C
Yeah
struggling
with
do
we
just
sort
of
do
we
try
to
do
something
anticipating
like
that?
Do
we
just
wait
until
somebody
comes
along,
you
know
asking
for
it,
especially
a
vendor
who
wants
that
support.
B
B
Yeah
one
of
the
things
I
really
just
want
to
try
is
the
existing
java
sdk
in
an
android
app,
because
I
think
there's
a
good
chance
that
we
just
work
unmodified,
and
so
we
at
least
get
that
that
level
of
support
and
then
for
specific
android
things.
We,
like
you,
said
we'd,
have
to
wait
and
see
like
what's
valuable
to
people
really.
C
And
do
you
know
like
it
sounds
like
most
of
your
development
is
or
most
of
your
stuff
is
via
the
compile-time
byte
code
instrumentation?
F
C
Currently
and
api
we're
supporting
java
7,
but
we're
thinking
we're
looking
at
potentially
bumping
that
to
java
8
and
what
we
had
found.
One
of
the
things
that
was
holding
us
back
earlier
was
android
because
we
thought
that
android
needed
java
7.
B
Customers
using
older
configurations
for
their
apps
and
it's
not
as
uncommon
as
you
might
think,
that
people
just
kind
of
like
froze
their
code
in
2017,
and
they
don't
want
to
touch
it
again.
So
in
those
cases
like,
I
just
recently
ran
into
an
issue
like
that,
where
I
thought
it's
safe
to
kind
of
like
move
into
the
modern
world
and
big
customers
said
no.
We
can't
do
that,
so
I
had
to
like
roll
back
some
changes
specifically
to
make
java
8.
C
B
Yeah,
you
start
to
get
into
sort
of
tricky
configuration
when
you
try
to
do
that,
but
yeah
it's
possible
for
backwards
compatibility
of
of
sdk.
C
B
C
Yeah,
okay,
I
know
I've
been
asking
all
the
questions.
Anybody
anybody
have.
E
C
No,
no,
it
was
great
to
get
a
overview,
because
that's
kind
of
what
I
think
we're
lacking
is
just
general.
B
B
Yeah,
I
mean
you
know
when
you
think
android
just
think
java,
and
there
will
be
you
know.
I
mean
there
will
be
specific
things,
but
I
mean
java
kotlin,
that's
the
world
that
android
exists
in,
so
that's
why
I
think
the
existing
java,
open
instrumentation,
will
probably
work.
You
know
unless
it's
using
like
java
11
java
12
features
that
aren't
supportive,
so.
E
B
B
I
use
it,
but
not
in
java
stuff,
I
mean
not
an
android
stuff,
yeah
yeah.
So
that's
well,
I'm
not
sure
what
jdk
level
that
was
introduced,
and
that
would
be
something
great
for
a
road
map,
because
that's
where
code
styles-
and
you
know
async
paradigms
really
moving-
is
futures
more
support
for
executors.
B
That's
one
of
the
things
I've
always
had
on
the
back
burner
is
more
of
the
well.
I
guess
just
the
executor
packaging
to
trace
that
stuff
out
better.
C
I
think
that
one
thing
that
I
think
is
very
interesting
is
from
the
new
relics
is
that
your
support
is,
via
that
compile
time.
Byte
code
instrumentation,
as
opposed
to
like
a
a
manual
like
integrating
the
library
into
the
app.
B
Yeah
static
instrumentation,
we
would
have
no
customers.
I
think,
if
you
really
had
to
like
manually
seed
your
code
with
all
the
things
that
we're
just
automatically
doing,
and
that's
really
the
key
to
the
success,
but
because
android
security
is
so
great.
That's
why
we
can't
do
any
sort
of
like
like
the
equivalent
in
ios,
is
swizzling
where
at
app
startup
we
just
go
through
and
replace
the
vectors
for
all
those
methods.
The
you
know
the
framework
methods,
the
third-party
stuff
that
we
want
to
monitor.
B
C
B
C
Wonder
if
other
vendors
who
are
participating
in
open
telemetry,
I
mean,
if
that
is
the
typical
customer
experience
that
the
customers
are
expecting.
B
C
All
right
cool
any
other
questions
for
today,
while
for
sorry
that
I
already
lost
your
first
name
in
my
in
my.
C
B
C
Cool,
do
you
have
the
link
to
the
meeting
notes.
B
G
Yeah,
I
just
want
to
add
an
agenda
item
to
touch
upon
the
release.
Cadence
just
wondering
if
there's
well,
let
me
set
the
context:
we've
got
a
bunch
of
average
users
using
open
telemetry,
java,
instrumentation
and
so
from
the
usage
of
the
0.7.0
release
the
two
issues
that
seem
to
be
like
really
important,
really
that
they're
really
been
itching
for.
Are
these
two
issues
I
linked
up
in
the
agenda
item?
G
They
were
marked
as
p1.
They
were
fixed,
but
the
long
pole
is
waiting
the
customer
waiting
for
a
release
that
actually
has
the
fix.
So
I
see
the
gains
is
like
about
once
a
month
and
I'm
wondering
if
there's
a
faster
way
to
get
fixes
to
users
as
as
as
hotels,
gaining
popularity,
I'm
seeing
it
pop
up
in
a
bunch
of
different
forms,
bunch
of
different
different
areas.
My
friends
are
asking
about
it
right,
so
it's
getting.
G
So
people
are
asking
about
like
the
usage
and
stuff
like
that,
so
if
there's
a
release,
if
there's
a
regression
and
then
they
have
to
wait
for
another
release
in
order
to
come
out,
I
think
that
can
add
up
to
potentially
two
months
before
they
actually
get
fixed.
So
this
cadence
is
is
is
kind
of
long
for
users
to
wait.
G
So
I
I
I
don't
know
what
would
be
the
best
way
to
help?
Is
there
daily
snapshots
that
someone
can
depend
upon
for
fixes,
or
is
it
faster
to
have
a
quick
branch
in
a
patch
release
process
on
the
patch
version,
in
order
to
just
isolate,
like
the
smallest
pr
to
address
any
issues
based
on
the
previous
release,
I
have
strong
opinions
weekly
held
that
I
can
provide
some
suggestions
for
so
I
was
wondering
if
I
can
get
good
thoughts
on
that
from
the
community.
C
Yeah,
so
what
we
had
discussed
previously
on
this,
at
least,
is
that
prior,
certainly
after
ga,
we
would
much
more
aggressively
patch
regressions
like
that,
but,
prior
to
ga,
we
didn't
think
that
it
was
necessary.
C
G
Okay,
so
I
I
think
the
cadence
suitable
for
the
past,
as
things
were
still
solidifying,
but
like,
as
you
know,
the
spec
the
specifications
firming
up
on
the
trace
api,
so
the
quick
feedback
for
the
user
to
be
able
to
see
these
changes,
I
think,
is
we
need
to
create
some
type
of
ramp
or
gradual
slope
towards
faster
response
time
for
these
things,
so
that
way,
users
can
provide
the
feedback
earlier
before
the
ga
arrives,
that,
with
the
ga
can
can
arrive
at
like
hardened
quality
and
such
don't.
We
produce.
E
Snapshot
builds,
we
do
have
snapshot
builds,
so
we
build
every
night
snapshot.
Builds
you
always
can
depend
on
them.
The
only
problem
with
them
that
we
currently
publish
them
to
ossg
from
crepo,
which
has
a
limit
for
25
late
snapshots,
so
they
can
disappear
under
your
feet,
which
is
not
ideal
andrew.
I
I
wanted
to
ask:
what
do
you
think
we
is
the
better
way
either
to
provide
patch
releases
for
the
for,
like
the
previous
branch
or
the
previous
release,
with
cherry
pick
fixes
or
to
provide
like
dot
releases
every
week?
E
C
C
E
C
Problem
with
the
problem
with
our
depending
on
sdk
snapshots
is
right.
Now
our
open
telemetry
api
interop,
where
customers
can
write
custom
instrumentation,
and
we
pick
that
up
and
correlate
that
we're
only
targeting
our
instrumentation
only
targets.
The
latest
we're
not
maintaining
backward
compatibility.
E
E
C
So
just
background
for
other
folks,
the
the
way
that
we
instrument
the
open
telemetry
api,
so
that
we
interop
with
users
who
want
to
send
custom
telemetry
is
we
instrument
that
we
basically
hijack
the
sdk
there
and
put
our
own
implementation
of
the
sdk
and
pipe
everything
over
a
bridge
to
our
internal
sdk,
where
everything
gets
correlated
and
sent
out.
C
The
problem
is
once
we
hit
ga
our
plan
is
to
support
multiple
versions
of
the
api,
the
open,
telemetry
sdk
via
different
instrumentation
that
targets
those
different
versions
which
could
be
version
incompatible,
but
until
one
zero
we've
had
made
the
decision
not
to
support.
You
know:
zero,
three,
zero,
four,
zero,
five,
zero
six
and
only
support
the
latest.
C
E
F
And
by
the
way,
and
by
the
way,
is
there
something
we
can
do
to
help
with
that?
I
don't
know
if
I
remember
nikita
you're
mentioning
that
you
wanted
to
simplify
the
release
process
compared
to
the
java
one
or
I
don't
know
if
you
did
that,
but
if
there's
something
that
could
be
done
from
our
site,
we
can
help.
C
One
good
thing:
now:
the
releases
used
to
take
longer
because
we
used
to
have
to
do
manual
end-to-end
testing,
but
we
have
nikita
added
end-to-end
tests
with
the
export
like
real
exporters
recently.
So
that
gives
us
you
know
that,
so
we
don't
need.
I
think
we
can
bypass
that
step
now.
C
So
maybe
I
mean
we
can
create
a
branch
and
then
if
people
can
submit
prs
to
that
branch
with
the
cherry
picked
commits
and
then,
if
you
can
help
out
with
the
release
notes
that
would
probably
be
appreciated.
Also.
C
C
Yeah,
so
we
had
originally,
we
had
not
been,
depending
on
the
snapshot
and
just
sinking
to
the
latest
official
release
and
then,
as
we've
been
building,
as
we've
been
doing
more
things
that
sort
of
affect
both
on
like
features
that
we
need
in
the
agent
that
we
need
to
develop
in
the
sdk
first
and
then
pull
over.
C
That
was
we
decided
to
switch
and
use
snapshots
so
that
that
development
process
would
be
a
lot
smoother
and
faster
instead
of
develop
the
feature
in
the
sdk
wait
a
month
for
the
release
now
pull
it
in
to
the
agent
so
that
that
was
really.
The
only
reason
was
just
to
increase
the
sort
of
velocity
of
features
that
span
both
projects.
C
That's
a
good
possibility.
I
know
we
had
just
agreed
to
do
this
up
to
ga
and
then
reevaluate
for
post
ga,
because
yeah
you're
right
there's
definitely
downsides.
C
C
Actually,
even
even
if
we
do
depend
on
the
snapshot
post,
ga
our
we're
going
to
maintain
instrumentation.
That
still
always
applies
to
all
of
the
open,
telemetry
api
versions.
C
All
the
g8
open,
telemetry
api
versions,
so
you'll
always
be
able
to
take
the
latest
java
agent
and
use
any
any
g8
hotel
api
version.
So
we
wouldn't
have
that
particular
problem,
but
we
would
internally
still
be
depending
on
snapshot,
which
isn't
as
bad.
G
So
it
sounds
like
that
there
is.
It
sounds
like
having
a
patch
release
off
of
a
branch
for
any
issues
that
may
pop
up
after
a
release
is
the
way
to
go,
and
at
least.
G
Okay,
and
so
the
upcoming
0.8.0
release,
is
that
one
fourth
coming
as
these
two
outstanding,
these
two
fixes
that's
already
gone
into
master
branches,
still
like
hotly
desired.
C
And
I
think
zero
eight
zero
should
go
out
early
next
week.
I
don't
know
what
do
you
think
nikita.
E
G
Okay,
okay
and
then
the
patch
process,
with
the
branch
can
start
after
that.
If,
if
there
is
a
high
priority
bug
that
comes
in
on
the
0.8.0
voice,.
C
Expectations
tyler,
you
added
an
item,
tell
us
about
it.
H
So
I
know
we've
talked
about
this
in
the
past
a
little
bit
kind
of
in
terms
of
allowing
users
to
do
custom
instrumentation,
and
I
was
just
kind
of
curious.
Have
we
fixed
that?
What's
the
state
on
that?
H
Do
we
allow
the
agent
to
load
instrumentation
from
a
separate
class
loader.
C
No,
so
so
far,
what
were
probably
what
we're
thinking
to
target
for
ga,
at
least
is
we've
split
out
the
instrumentation
api
as
a
separate
artifact,
so
that
people
can
use
that
to
build
custom
instrumentation,
but
we're
not
at
least
prior
to
ga.
C
C
You
know
whatever
they
can
cherry
pick
whatever
instrumentation
they
want,
including
their
own
custom,
instrumentation.
H
H
That
they
want
to
own,
for
example,
their
own
like
open,
telemetry
implementation.
They
don't
want
they
want,
they
want,
let's
say,
for
example,
a
user
wants
to
have
a
java
agent.
That
applies
just
automatic
instrumentation
using
the
existing
class
loader.
H
So
it
doesn't
have
all
of
the
protections
that
you
know
our
current
automatic
instrumentation
has
do.
We
have
any
strategies
on
like
how
that
might
work
right
now.
The
best
thing
I
can
suggest
use
an
off-the-shelf
aop
library,
but
I
was
just
trying
to
think.
Is
there
something
better
that
we
can
provide.
C
H
Okay
so
say
I
have
an
application
that
I've,
mostly
instrumented
with
manual
instrumentation,
for
example,
and
there's
a
part
of
my
code
where
I
want
to
apply
automatic
instrumentation
for
just
a
small
subset.
Oh.
H
So
one
one
use
case
for
this
might
be:
I
am
very
sensitive
to
startup
over
overhead,
so,
for
example
like
a
lambda,
and
so
I
manually
instrument
stuff
for
the
most
part,
but
maybe
there's
a
part
of
my
lambda
code
that
I
want
to
automatic
instrument
and
that's
why
I
would
say:
okay,
maybe
doing
compile
time
instrumentation
for
this
specific
case
would
be
useful
and
having
tooling.
That
makes
that
a
little
easier.
H
C
H
Something
I
thought
of
that
might
be
interesting
to
bring
up
of
like.
H
C
I
see
where
they
can
put
their
like
aspect,
j
aspect
on
their
class
path,
even
and
we
would.
H
Pick
that
up,
I
say,
say
I
want
to
have
something
that
does
an
inject
and
extract
to
actually
propagate
the
trace,
instead
of
just
annotating
a
simple
method.
H
So
more
concretely,
I
don't
know
if
anyone
has
any
experience
with.
I
think
it's
axway.
H
Is
a
a
crazy
java
framework
that
we
have
a
customer
that
wants
us
to
instrument,
but
it's
a
it's:
a
commercial
product,
there's
nothing
published
on
maven
and
like
we.
Don't
really
think
that
it's
easy
to
it's
supportable
from
a
commercial
standpoint,
and
so
I
was
just
trying
to
think
like
okay.
Is
this
something
that
we
could
maybe
provide
tooling
for
them
to
to
use.
C
H
Well,
the
customer
could
in
theory
write
their
own
instrumentation
for
it,
but
the
the
tooling
doesn't
really
make
like.
So
it's
it's
all
closed
source,
and
so
there's
not
a
lot
to
work
with
on
it
to
compile
against.
H
So
in
theory
it's
possible
but
yeah,
I
don't
know
anyway.
So
that's
just
kind
of
something
that's
been
on
my
mind.
A
little
bit
is:
can
we
supply
tooling
to
make
that
a
little
easier?
I
I
don't
know,
I'm
not
sure
if
it's
worth
the
effort
right
now,
obviously
not
free
ga,
but
just
something
I
wanted
to
start
the
discussion
about.
C
Cool
yeah,
I
think
so
the
there's
a
lot
of
interesting,
like
kind
of
dynamic
stuff
of
being
able
to
use
the
java
agents
and
dynamically
pull
in,
like
you
said
that
that
kind
of
instrumentation
and
yeah
it
is,
it
does
get
complicated
quickly,
which
is,
I
think,
where
we
landed
with
for
ga
on.
C
You
know
these
custom
distributions,
where
you
essentially
have
to
build
your
own
java
agent
based
on
the
open,
telemetry
java
agent
in
order
to
pull
in
these
you
know,
custom
in
order
to
custom,
get
custom
behavior,
but
yeah
feel
free
to
open
an
issue
to
kind
of
track.
The
idea
and
yeah
there's
we'll.
C
Come
back
to
all
of
these
there's
a
few,
we
should
probably
group
them
around
kind
of
dynamic,
instrumentation
loading.
H
C
Cool
anybody,
any
other
topics.
Anyone
wants
to
discuss.
A
Only
that
I'm
gonna
merge
that
getting
rid
of
the
spanidy
trace
id
rappers
after
this
meeting.
So
it's
gonna,
be
I
don't
know
if
I'm
sure
it
will
make
the
agent
not
work,
but
it's
it's.
It's.
A
A
H
So
john
on
that
topic,
do
you
remember
so
my
discussion
about
having
a
generic
consumer
did
that
make
sense?
Oh.
A
We
can
talk
about
that
also,
but
I
have
a
whole
bunch
of
comments
for
you
on
that.
I
did
a
bunch
of
experimentation
with
examples
of
things
that
could
work.
So
the
only
thing
I
wasn't
sure
about
is
what
you
were
asking
for
around
the
generics,
because
generic
java
generics
from
a
consumption
perspective
for
that
when
there's
variatic
types
on
the
to
consumer
yeah.
A
A
I
could
actually
I
could
push
up
to
the
branch
out
there.
Maybe
I
did
anyway.
I
can
push
up
my
ideas.
You
can
at
least
take
a
look
at
it
since
that's
just
a
draft.
I
mean
that
thing's
never
going
to
be
merged
anyway.
That's
just
me
messing
around
so
I'll
go
ahead
and
do
that
and
opinion
on
it.
C
C
Like
now
now
you
have
a
data
uri
handler
kind
of
abstraction
that
you
can
pass
and
lazy
kind
of
yeah.
H
So
so
that's
actually
something
that
I'm
probably
going
to
I'm
working
on
on
our
code
base
of
like
introducing
this
lazy
attributes
kind
of
concept
in
our
code
base,
and
I
that
that
just
kind
of
I
mean
spawned
basically
from
our
discussion
previously
of
like
okay
right
now
in
in
our
code
base.
I
don't
know
if
you
guys
have
it,
but
there's
this
rules,
processing
that
happens
after
yeah
okay.
H
So
we
have
this
set
of
rules
that
are
applied
to
traces
after
the
completion
that
do
things
based
off
of
the
the
tags
and.
H
In
some
effects
it
does
have
this
lazy,
it's
kind
of
a
messy
way
of
doing
the
lazy
processing.
H
H
A
Cool,
I
have
one
more
one
more
thing
analog
put
in
a
pr
to
java
repo
last
night
or
this
morning.
I
guess
how
you
count
it
to
remove
the
the
module
that
specifies
the
exporter
configs,
like
the
sbi
for
exporter
configs,
and
I
didn't
know
that
was
going
to
be
happening
and
it
did
something
analogous
have
been
put
into
the
instrumentation
repo.
A
C
Yeah,
so
that
is
now
in
the
agent
tooling
artifact,
which
we
published
to
to
jfrog
to
bintray.
So
we're
not
currently
publishing
all
the
way
to
maven
central,
but
there
are
stable
releases
on
bintray,
and
so
you
can
use
those
to
build.
C
We
should,
I
know
we
added
that
dock
to
the
spring,
the
spring
starter
documentation
since
our
spring
starters.
The
same
have
the
same
issue
but
yeah.
We
should
add
that
for
the
external
exporters,
also
with
the
external
exporters-
I
mean-
I
guess
we
can
we
were.
We
can
keep
that
current
behavior,
where
you
can
dynamically
link
a
external
exporter,
but
in
general
for
for
ga,
with
customizations,
all
the
other
customizations
were
are
requiring
building
a
custom
distribution
of
the
java
agent.
C
A
Okay,
it's
good
to
know,
I
think
it
makes
it
a
little
tricky
for
vendors
like
who
don't
want
to
necessarily
distribute
a
whole
distribution
to
provide
a
custom
exporter.
That
would
be
my
feedback.
A
Yeah
I
mean
I
think
for
for
things
like
spam
processors
and
samplers,
and
all
that
kind
of
stuff.
I
think
it
totally
makes
sense.
Exporter
seems
like,
like
it's
kind
of
the
like
super
low
super
low
barrier
entry.
I
just
want
to
use.
What's
off
the
shelf,
I
love
your
instrumentation.
I
don't
want
to
do
anything
fancy
you
just
want
to
get
the
data
where
I
want
to
get
it.
A
C
C
Yeah
all
right:
well,
we
passed
our
five
minute
marker,
so
unless
anybody
has
any
last
burning
thoughts
till
next
week,.