►
From YouTube: 2022 06 17 Platform SIG
Description
Platform SIG meeting with topics including:
* Action items
* Java 11
* Java 17
A
A
No
okay,
so
open
action
items,
this
plug-in
installation
manager,
docs
action
item
continues
as
an
open
item,
because
I
just
don't
have
time
right
now
to
approach
it.
It's
that
we
want
to
document
the
plugin
installation
manager
a
particular
way
and
it
makes
sense,
but
it
means
extracting
that
and
putting
it
into
the
plug-in
repository
or
plug-in
the
github
repository,
so
that
I
I
don't
expect
any
change
even
over
the
next
month.
Given
the
amount
of
work,
that's
I've
got
other
places.
A
A
A
Basel
anything
you
want
to
report.
In
terms
of
the
blog
post,
I
saw
a
really
cool
graph
that
I
am
now
charmed
and
fascinated
by
yeah.
B
I've
been
kind
of
researching
the
adoption
rate
of
various
previous
java
upgrades
that
the
jenkins
project
has
done,
but
so
far
the
only
thing
I've
really
learned
is
that
what
we're
doing
with
java
11
is
on
par
with
what
we've
done
previously.
B
You
know,
that's:
we've
always
required
a
new
version
of
java,
while
people
were
still
using
the
old
one,
but
we
were,
but
we
always
did
so
when
usage
was
declining,
the
old
version
rather
than
increasing
and
we're
doing
the
same
thing
with
java
11.
so
so
far
everything
I've
learned
is
that
we're
kind
of
on
par
with
previous,
with
past
precedent.
A
Which
is
good,
that's
excellent!
Well,
it's
really
cool
that
you
found
data
to
support
that.
That's
great!
Thank
you!
So,
looking
forward
to
that,
and
then
we
will,
in
september,
switch
the
long-term
support
release
to
require
java
11
as
well
how's
your
how's,
your
sense
in
terms
of
the
tooling
basel.
Are
we
okay
on
the
tooling,
where
it'll
be
relatively
straightforward,
to
make
the
transition
after
june
22
to
be
ready
for
june
28th,
yeah.
B
A
B
Sure,
as
part
of
this
blog
post,
that
I'm
writing,
I'm
also
going
to
announce
that
java
17
is
going
from
preview
into
general
availability.
And
you
know
right
now.
There
are
very
few
people
using
java
17.
I
think
mostly
because
it
prints
a
very
scary
warning.
If
you
try
to
do
that
and
requires
a
special
flag
to
enable
java
17
support
we're
taking
that
flag
away
in
the
upcoming
lts
release
next
week.
So
you
don't
need
to
do
anything
special
to
run
on
java
17.
B
and
hopefully
that
will
encourage
a
lot
more
people
to,
in
addition
to
writing
in
the
blog
post
that
it's
no
longer
in
preview
mode
that
we
generally
recommend
it.
Hopefully
that
will
motivate
people
to
start
running
with
java
17
if
they
are
so
so
motivated
to
rather
than
let's
say
java
11.,
and
my
sense
is
that
java
17
is
overall,
a
better
release
than
java
11.
B
Given
that
I
think
I
found
at
least
two
or
three
bugs,
if
not
more,
that
have
been
fixed
in
17
that
I've
had
to
backboard
to
java
11..
So
if
I
were
a
user
I
would
be.
B
I
would
be
choosing
java
17
myself,
given
that
it
seems
like
a
more
stable
release
to
me,
so
hopefully,
with
our
official
blessing
and
recommendation
and
with
the
removal
of
that
special
flag,
that
more
people
will
start
using
java
17.,
and
there
is
a
small
risk
that
there
are
issues
we
haven't
discovered
with
java
17.
Yet
we
have
run
the
plug-in
compatibility
tester
on
all
of
the
top,
basically
the
top
100
plug-ins,
more
or
less,
but
but
there's
still
many
more
plugins
than
that
that
have
not
yet
been
tested.
B
So
there
is
a
risk
that
your
favorite
plug-in
might
not
work
with
java,
17
and
typically
that's
because
it
would
be
the
issues
that
we've
seen
in
the
past
that
we've
fixed
already
have
been
related
to
plugins,
using
xstream
to
serialize
certain
types
of
built-in
concurrent
java
types.
B
So
things
like
like
concurrent
hash
map-
or
I
think
that's
a
big
one-
that
we've
seen
where,
if
you're,
if
there's
a
plug-in,
that's
trying
to
serialize
those
with
xstream
that
doesn't
work
out
of
the
box
in
java
17
and
it
generally
indicates
a
either
a
bug
or
maybe
a
design
flaw
in
the
original
code,
because
these
concurrency
safe
types,
it's
probably
not
what
you
intended
to
serialize
to
an
xml
file
right
most
of
the
time
when
you're
using
these,
these
data
structures,
you're
trying
to
synchronize
usage
of
some
object
in
memory
at
runtime
and
what's
important,
is
not
that
you
write
out
all
of
these
concurrency
data
structures
to
disk
rather,
what's
important
is
that
you
know
these
two
current
threads
aren't
going
to
race
with
each
other
and
to
access
the
same
memory
at
one
time.
B
So
when
we've
seen
these
problems
in
the
past,
what
we've
done
to
fix
them-
and
I
fixed
a
few
pipeline
plug-ins
this
way-
was
just
to
convert
the
field
from
a
concurrent
data
structure,
to
a
regular
data
structure
and
to
find
find
some
other
way
of
doing
the
concurrency.
That
doesn't
involve
serializing
that
to
disk,
so
you
know
changing
the
changing
the
concurrent
hash
map
to
a
regular
hash
map
and
then
finding
some
other
way
of
doing
the
locking
so
that
you
don't
need
a
concurrent
hatch
map.
B
B
You
know
rather
than
very
common
scenarios,
so
I
wouldn't
anticipate
a
huge
number
of
java
17
specific
problems,
but
there
is,
there
is
always
a
risk
of
that,
so
I
think
those
will
naturally
be
discovered,
as
we
as
people
start
to
to
use
java,
17
and
especially
as
plug-in
maintainers
start
to
run
their
test
suites
with
java
17,
assuming
that
they
have
a
test
suite.
But
it's
one
of
those
things.
That's
that's
very
difficult
to
scan
for.
B
Unfortunately,
since
you
know,
there's
there's,
there's
no
re,
there's
no
easy
way
to
determine
without
tons
of
false
positives,
there's
no
easy
way
to
scan
through
the
plug-in.
Looking
for
serializable
types
that
have
these
concurrency
classes
in
them
and.
B
Find
them
there's
no
guarantee
that
that
would
be
serialized
with
xtreme
in
the
first
place,
rather
than,
for
example,
through
remoting,
where
it's
fine
to
do
that.
So
it's
yeah!
It's
it's
going
to
be
one
of
the
I
mean.
Maybe
if
it
becomes
a
very
big
problem,
we
could
spend
some
effort
and
try
to
scan
and
sift
through
the
the
very
many
false
positives,
but
that
effort
doesn't
seem
like
it's
justified
at
the
current
point.
In
time
I
mean
I
would
be
willing
to
reconsider
that
if,
if
more
data.
A
Comes
to
light,
so
we
really
don't
have
any
today
where
there
aren't
any
big
terrible
known
issues
for
java
17.
It's
rather,
I
think
what
you
just
described
are
things
that
are
possible
risks
and
possible
risks
with
a
code
base.
That's
as
rich
and
diverse
as
jenkins
is
some
place.
It's
got
to
be.
Have
those
those
things
right
if
most,
every
problem
has
existed
somewhere
in
the
code
base,
so.
B
Yeah
yeah
great
yeah,
I
mean
right
now.
I
don't
know
if
any
of
any
specific
issues
that
are
still
affecting
users-
and
there
is
we
do
know
about-
we
do
know
about
a
bug
in
a
groovy
views
that
specifically
groovy
jelly
views
that
could
affect
plug-ins
that
are
using
you
know
using
certain
types
I
think
I
mentioned
this
bug
in
the
past
as
being
a
fun
programming,
languages
bug,
but
there's
only
one
known
manifestation
of
that
by
being
worked
around
it
in
that
case,
so
there
may
be
others.
B
That's
that's
probably
that's
that's
another
potential
issue
that
again
should
be
very
rare
and
again
we
could
reconsider
addressing
the
root
cause
of
that
if
it
becomes
something,
that's
more
common
right
now
we
don't
know
of
any
other
cases
of
that.
Besides
the
the
one
that
we
worked
around
and
the
work
around
is
also
very
easy
for
that
one.
B
So
those
are
the
two.
Basically,
those
are
the
only
two
categories
of
possible
issues
that
we
know
about.
We
don't
end
up,
and
I
don't
know
if
any
concrete
manifestations
of
either
of
those
issues
in
any
plug-in
today,
any
any
concrete
manifestations
of
those
issues
that
we
have
discovered
already
have
either
been
worked
around
or
fixed
in
the
in
every
case.
B
So
the
only
thing
that
remains
are
these
general
issues
and
for
the
for
the
jelly
issue.
There
is
a
general
solution
to
that
which,
which
no
one
has
implemented
yet
and
for
the
extreme
issue.
I
don't
believe
that
there's
a
general
issue.
I
think
that
requires
case-by-case
fixes.