0:00:00.000,0:00:08.340
it have David tonight David actually

0:00:04.140,0:00:10.889
came to Singapore one year ago he was

0:00:08.340,0:00:13.769
actually visiting and speaking for a

0:00:10.889,0:00:17.250
conference I think it was for Rocco

0:00:13.769,0:00:19.560
waltz if I'm correct yep and yeah and

0:00:17.250,0:00:20.130
yeah it was pretty awesome it was really

0:00:19.560,0:00:21.960
good

0:00:20.130,0:00:26.010
meet up with him and we thought to

0:00:21.960,0:00:28.230
invite him again and so today like will

0:00:26.010,0:00:32.219
be more talking about coffee features of

0:00:28.230,0:00:33.989
Java like what to expect in the future

0:00:32.219,0:00:36.510
and what's be having the newest versions

0:00:33.989,0:00:38.760
of Java so we're very happy to have

0:00:36.510,0:00:40.950
David's eventually today and hope to

0:00:38.760,0:00:44.250
have him in person again in the future

0:00:40.950,0:00:46.289
thank you David thank you well in yeah

0:00:44.250,0:00:49.469
in fact I was supposed to come back I

0:00:46.289,0:00:54.000
think in June but yeah anyway thanks for

0:00:49.469,0:00:55.680
having me so despite I'm sorry despite

0:00:54.000,0:00:57.270
the hard situation I'm very happy to be

0:00:55.680,0:01:00.930
able to give these remote presentations

0:00:57.270,0:01:04.470
so the title of the session is Java in

0:01:00.930,0:01:06.689
the 40 version the thing is that more

0:01:04.470,0:01:08.430
and more I realized that given we have

0:01:06.689,0:01:11.760
accelerated the currents of the Java

0:01:08.430,0:01:15.390
release people are are somehow confused

0:01:11.760,0:01:18.060
about what's in Java so today what I

0:01:15.390,0:01:21.600
want to share with you is basically what

0:01:18.060,0:01:25.229
features will be added in 2020 in the

0:01:21.600,0:01:28.650
Java platform why why 40 well I'm

0:01:25.229,0:01:32.909
french-speaking and I always confuse 40

0:01:28.650,0:01:35.280
and 14 so given that we have just really

0:01:32.909,0:01:37.470
in a version 14 of Java this is really

0:01:35.280,0:01:39.750
what I'm going to talk today having said

0:01:37.470,0:01:42.720
that I will also discuss about Java 15

0:01:39.750,0:01:47.100
which is which will come later this year

0:01:42.720,0:01:50.430
in 2020 so this is a standard server

0:01:47.100,0:01:52.110
what is this camera from Oracle don't

0:01:50.430,0:01:53.490
make any process decision based on what

0:01:52.110,0:01:56.880
I will say today having said that

0:01:53.490,0:01:58.170
everything is open source so we're good

0:01:56.880,0:01:59.610
on that side the only thing that you

0:01:58.170,0:02:02.579
should you should keep in mind is that

0:01:59.610,0:02:05.490
and if anything that I say about Java 15

0:02:02.579,0:02:07.320
can in theory still change I mean Java

0:02:05.490,0:02:09.739
team will be released in September so

0:02:07.320,0:02:12.569
between now and then there might be

0:02:09.739,0:02:13.910
change that something that you have to

0:02:12.569,0:02:19.670
keep in mind about

0:02:13.910,0:02:21.440
disclaimer okay May is a very important

0:02:19.670,0:02:25.040
month because we are about to celebrate

0:02:21.440,0:02:27.730
the 25th anniversary of Java so Java has

0:02:25.040,0:02:30.560
been released the first release has been

0:02:27.730,0:02:33.620
released 25 years ago so we were just

0:02:30.560,0:02:35.840
about to celebrate that anniversary the

0:02:33.620,0:02:39.110
thing is that Java keep evolving since

0:02:35.840,0:02:42.200
25 years based on two core principle the

0:02:39.110,0:02:43.460
first one developer productivity second

0:02:42.200,0:02:46.820
core principle is application

0:02:43.460,0:02:49.930
performance this has been done through

0:02:46.820,0:02:53.270
the last 25 years in the face of

0:02:49.930,0:02:56.090
constantly evolving things such as

0:02:53.270,0:02:59.630
programming programming predicts for

0:02:56.090,0:03:01.840
example 25 20 years ago we're not really

0:02:59.630,0:03:05.150
talking about any kind of functional

0:03:01.840,0:03:06.290
programming when it was when it when

0:03:05.150,0:03:08.120
were talking about Java

0:03:06.290,0:03:10.270
that's something since then that has

0:03:08.120,0:03:12.230
been become more and more important

0:03:10.270,0:03:15.080
something else that evolved is

0:03:12.230,0:03:17.390
application style in the beginning we

0:03:15.080,0:03:19.100
were mainly talking about client-server

0:03:17.390,0:03:21.050
application we're talking about

0:03:19.100,0:03:23.930
Minnelli's application those day

0:03:21.050,0:03:25.730
obviously it's more and more about micro

0:03:23.930,0:03:29.350
services so this is yet another

0:03:25.730,0:03:32.840
revolution that Java has to cope with

0:03:29.350,0:03:35.570
deployment styles in the early days we

0:03:32.840,0:03:39.520
were deploying in our own data center on

0:03:35.570,0:03:42.410
large Java those day we tend to deploy

0:03:39.520,0:03:45.950
using containers in the cloud so that's

0:03:42.410,0:03:47.690
another big shift when it comes to to

0:03:45.950,0:03:49.910
the way we deploy our application and

0:03:47.690,0:03:51.709
again Java has to cope with that and

0:03:49.910,0:03:53.540
last but not least obviously the other

0:03:51.709,0:03:55.970
one is evolving so those day for example

0:03:53.540,0:04:00.200
we have more and more course in our

0:03:55.970,0:04:03.010
machines we have more and more memory we

0:04:00.200,0:04:05.900
have vector support directly built into

0:04:03.010,0:04:07.940
general-purpose computers we have

0:04:05.900,0:04:09.459
multiple level cache when it comes to

0:04:07.940,0:04:12.950
memory and so on and so on

0:04:09.459,0:04:14.959
so does blas this is basically out of a

0:04:12.950,0:04:18.310
divorce for the last 25 years and this

0:04:14.959,0:04:20.630
is how it will continue to evolve so

0:04:18.310,0:04:22.220
this is a pretty busy slide I'm not

0:04:20.630,0:04:23.990
gonna spend time on this slide this

0:04:22.220,0:04:26.960
slide basically lists all the features

0:04:23.990,0:04:27.840
that were added in Java 9 and Java 9 was

0:04:26.960,0:04:29.550
the special release

0:04:27.840,0:04:33.360
in the sense that it was the latest

0:04:29.550,0:04:36.990
large release of Java and there's a big

0:04:33.360,0:04:39.090
issue with that so every two to three

0:04:36.990,0:04:41.310
years we were releasing one Java version

0:04:39.090,0:04:42.960
with a bunch of features so when it

0:04:41.310,0:04:44.460
comes to adapting those features it was

0:04:42.960,0:04:47.550
very difficult because the developers

0:04:44.460,0:04:50.460
basically had horror of a sudden access

0:04:47.550,0:04:52.800
to a bunch of features so getting a

0:04:50.460,0:04:54.810
getting familiar with those features was

0:04:52.800,0:04:58.770
very difficult so we decided to change

0:04:54.810,0:05:00.389
the way Java is evolving so now it works

0:04:58.770,0:05:04.169
this is something that we have put in

0:05:00.389,0:05:06.210
place end of 2017 so every six months

0:05:04.169,0:05:09.650
does there is a new Java release so it's

0:05:06.210,0:05:12.419
called it's called a feature release so

0:05:09.650,0:05:15.930
11 12 13

0:05:12.419,0:05:19.560
the current Java release is 14 released

0:05:15.930,0:05:22.169
in March and in September 2020 we're

0:05:19.560,0:05:22.820
gonna release 15 that's a given six

0:05:22.169,0:05:26.940
months later

0:05:22.820,0:05:29.340
16 and so on and so on now all those

0:05:26.940,0:05:31.650
feature release are open source and are

0:05:29.340,0:05:34.560
supported until the next release comes

0:05:31.650,0:05:37.139
out so 9 was supported at least until 10

0:05:34.560,0:05:39.780
cans out and so on and so on so that

0:05:37.139,0:05:44.220
means that today 14 will be at least

0:05:39.780,0:05:46.110
supported and until 15 comes out and 115

0:05:44.220,0:05:48.360
will be released in September the

0:05:46.110,0:05:50.310
current release will be 15 and that does

0:05:48.360,0:05:51.930
Italy if you're in the open source aisle

0:05:50.310,0:05:53.220
you should use that version because

0:05:51.930,0:05:54.680
that's the that's the version that is

0:05:53.220,0:05:57.240
supported

0:05:54.680,0:05:59.310
now we also acknowledge that there are

0:05:57.240,0:06:01.800
some user typically enterprise they are

0:05:59.310,0:06:06.240
not able to move that rapidly so moving

0:06:01.800,0:06:08.130
for 14 to 15 is in itself not a big work

0:06:06.240,0:06:09.510
given that they are not demanding that

0:06:08.130,0:06:11.070
penny features between all those beliefs

0:06:09.510,0:06:12.870
but still there are people there are

0:06:11.070,0:06:14.550
there are some type of user that prefer

0:06:12.870,0:06:16.830
to stick to one release for many many

0:06:14.550,0:06:18.330
years so that's what that's why we are

0:06:16.830,0:06:21.150
tricolor I have decided to have

0:06:18.330,0:06:22.979
long-term support release so basically a

0:06:21.150,0:06:24.960
long-term supporter ease is nothing more

0:06:22.979,0:06:30.419
than a given future release that we take

0:06:24.960,0:06:33.410
and we maintain for a very long time 11

0:06:30.419,0:06:37.020
is the current LTS the next one will be

0:06:33.410,0:06:39.120
17 so those release would be supportive

0:06:37.020,0:06:40.440
supported for many many years despite

0:06:39.120,0:06:42.210
the fact that obvious

0:06:40.440,0:06:46.290
we will still have every six months and

0:06:42.210,0:06:50.100
new features release so basically it

0:06:46.290,0:06:53.160
provides choice either you use the open

0:06:50.100,0:06:55.950
JDK build that Oracle is providing they

0:06:53.160,0:06:58.400
are free the only thing is that if you

0:06:55.950,0:07:01.140
are using those bills well you'd better

0:06:58.400,0:07:03.240
keep with the Java release guidance

0:07:01.140,0:07:05.670
so right now ideally you want to be on

0:07:03.240,0:07:07.140
14 because this is the race that is

0:07:05.670,0:07:10.920
supported and that's also the reason

0:07:07.140,0:07:12.800
that is getting the security updates if

0:07:10.920,0:07:16.620
you are not able to move that quickly

0:07:12.800,0:07:20.400
Oracle also sells support for Java

0:07:16.620,0:07:22.950
that's the Oracle JDK so when it comes

0:07:20.400,0:07:24.660
to buying Oracle support there are two

0:07:22.950,0:07:27.660
things that you should look at the price

0:07:24.660,0:07:32.640
of that support honestly the price of

0:07:27.660,0:07:35.700
the Oracle support for Java is pretty

0:07:32.640,0:07:36.780
cheap but I will let you judge that the

0:07:35.700,0:07:39.030
only thing that you would need to look

0:07:36.780,0:07:40.740
at when you decide where you want to get

0:07:39.030,0:07:42.150
your support for Java is basically the

0:07:40.740,0:07:43.920
ability that the organization you are

0:07:42.150,0:07:47.430
looking at is able to support you and

0:07:43.920,0:07:50.250
this slide shows the number of issue

0:07:47.430,0:07:53.490
that were fixed in in this particular

0:07:50.250,0:07:56.070
example in GDG 14 and we see that Oracle

0:07:53.490,0:08:02.010
is clearly the company that contributes

0:07:56.070,0:08:04.620
the most to Java so the takeaway here

0:08:02.010,0:08:06.330
Java is still free dr bean there has

0:08:04.620,0:08:10.380
been a lot of countries and confusions

0:08:06.330,0:08:14.400
regarding that but java is and remains

0:08:10.380,0:08:17.280
free so now let's quickly discuss about

0:08:14.400,0:08:19.020
how can we enable faster innovation

0:08:17.280,0:08:21.660
within the platform so the first thing

0:08:19.020,0:08:23.400
that we put in place two or three years

0:08:21.660,0:08:25.040
ago was this new release guidance where

0:08:23.400,0:08:27.690
every six months we have a new release

0:08:25.040,0:08:31.260
we also have the just the jep's

0:08:27.690,0:08:33.180
mechanism so chip stands for jdk enhance

0:08:31.260,0:08:35.930
and enhancements proposal so it's

0:08:33.180,0:08:38.490
basically a mechanism that we used to

0:08:35.930,0:08:41.310
introduce in the platform new Java

0:08:38.490,0:08:43.950
language features new GDK features or

0:08:41.310,0:08:46.380
even we're using that process to remove

0:08:43.950,0:08:48.510
things from the platform or we are also

0:08:46.380,0:08:53.400
using that features for example to

0:08:48.510,0:08:56.730
evolve out the open to open JDK project

0:08:53.400,0:08:59.250
is manager so it's basically some kind

0:08:56.730,0:09:01.740
of lightweight mechanism that clearly

0:08:59.250,0:09:03.420
that is clearly documented and tell the

0:09:01.740,0:09:05.370
community how things are supposed to

0:09:03.420,0:09:07.470
work when it comes to doing something

0:09:05.370,0:09:10.140
non-trivial non-trivial in the into the

0:09:07.470,0:09:11.670
platform next to that we have also put

0:09:10.140,0:09:13.830
in place multiple feedback feedback

0:09:11.670,0:09:16.410
mechanism that we are using to get

0:09:13.830,0:09:17.760
feedback on non final features so the

0:09:16.410,0:09:20.760
thing is that whenever we put something

0:09:17.760,0:09:22.350
into the platform as soon as it's final

0:09:20.760,0:09:24.770
it's something that is there forever

0:09:22.350,0:09:28.560
so it's basically it becomes permanent

0:09:24.770,0:09:30.210
so we'd better get it right before we

0:09:28.560,0:09:33.480
turn something into a permanent feature

0:09:30.210,0:09:35.970
within the platform so for that we have

0:09:33.480,0:09:38.430
multiple mechanism that we can use to

0:09:35.970,0:09:42.000
basically give to developers non final

0:09:38.430,0:09:43.980
features we encourage developer to used

0:09:42.000,0:09:45.870
on those non final features and based on

0:09:43.980,0:09:47.940
the feedback we can still do adjustments

0:09:45.870,0:09:50.520
to those features before we make them

0:09:47.940,0:09:53.280
permanent so we have the preview

0:09:50.520,0:09:56.070
features mechanism which is used more

0:09:53.280,0:09:58.320
for language Java language features will

0:09:56.070,0:10:02.160
serve experimental features which we use

0:09:58.320,0:10:03.930
mainly for odd spot VM features and then

0:10:02.160,0:10:05.910
we have an additional which sorry

0:10:03.930,0:10:07.400
additional mechanisms such as encoder

0:10:05.910,0:10:10.920
modules

0:10:07.400,0:10:15.300
early GDK access built that we use to

0:10:10.920,0:10:17.670
basically give access to to prototype of

0:10:15.300,0:10:20.580
new capabilities that we are thinking of

0:10:17.670,0:10:22.770
adding into the platform and last but

0:10:20.580,0:10:24.810
not least we have an ongoing open JDK

0:10:22.770,0:10:25.920
project that his name's Karass so the

0:10:24.810,0:10:28.500
the goal of SCARA

0:10:25.920,0:10:30.270
is to investigate alternative to

0:10:28.500,0:10:31.980
mercurial so if you are looking if you

0:10:30.270,0:10:33.930
know open JDK you know that for many

0:10:31.980,0:10:35.790
years open JDK when in fact since the

0:10:33.930,0:10:39.290
beginning open JDK has used a mercurial

0:10:35.790,0:10:42.510
as his as its source code management

0:10:39.290,0:10:45.240
solution it worked for many years but

0:10:42.510,0:10:47.850
honestly material is a bit tough to

0:10:45.240,0:10:48.720
learn so if you want to encourage more

0:10:47.850,0:10:51.540
contributions

0:10:48.720,0:10:53.040
well we'd better look at alternative so

0:10:51.540,0:10:56.960
that was the goal of that project look

0:10:53.040,0:10:59.580
at our alternatives and the outcome is

0:10:56.960,0:11:01.320
skaara selected git as the alternative

0:10:59.580,0:11:04.530
so that means that all the open JDK

0:11:01.320,0:11:08.089
development is moving to get SCARA has

0:11:04.530,0:11:12.379
also looked at Austin get provider

0:11:08.089,0:11:16.290
Gaeta has been selected but Kelly

0:11:12.379,0:11:17.939
skaara and openjdk is not tied to a get

0:11:16.290,0:11:21.089
up so if something goes wrong with

0:11:17.939,0:11:23.009
github we can easily switch despite the

0:11:21.089,0:11:25.619
size of the project where different gate

0:11:23.009,0:11:27.959
providers and last but not least Kara's

0:11:25.619,0:11:29.879
also looked at how we can improve the

0:11:27.959,0:11:32.699
complete development lifecycle of open

0:11:29.879,0:11:34.249
JDK by adding on top of it some

0:11:32.699,0:11:37.439
additional tunings

0:11:34.249,0:11:41.220
so a bunch of open JDK project I've

0:11:37.439,0:11:43.829
already moved to github we have the list

0:11:41.220,0:11:46.559
here amber Sierra GMC loom and so on and

0:11:43.829,0:11:48.929
so on and all the rest obviously are

0:11:46.559,0:11:53.910
planned to move in fact we plan to move

0:11:48.929,0:11:57.259
GDK itself hater around I think end of

0:11:53.910,0:12:03.600
GDK 15 so that would be still in 2020 or

0:11:57.259,0:12:05.459
around early 16 so still in 2020 but

0:12:03.600,0:12:06.240
still all the project are ridden alive

0:12:05.459,0:12:08.819
read-only

0:12:06.240,0:12:12.929
amuro's on the tabs so basically all

0:12:08.819,0:12:16.139
those all those barrettes won't give us

0:12:12.929,0:12:18.089
the ability to enable faster innovation

0:12:16.139,0:12:19.980
within the platform something that we

0:12:18.089,0:12:27.059
have already used and we clearly see the

0:12:19.980,0:12:29.610
benefit of all of those tools sorry so

0:12:27.059,0:12:32.249
delivering faster so we have enabled the

0:12:29.610,0:12:34.249
ability to deliver to deliver faster and

0:12:32.249,0:12:36.959
well let's look at what we have

0:12:34.249,0:12:38.819
delivered recently when I say we it's

0:12:36.959,0:12:40.620
really open JDK community obviously

0:12:38.819,0:12:44.129
Oracle is a big player in that community

0:12:40.620,0:12:48.569
but it's not just a rifle right so Java

0:12:44.129,0:12:49.889
10 delivering in March 2018 those are

0:12:48.569,0:12:52.559
all the features I'm not going to spend

0:12:49.889,0:12:54.350
any time on those release because we're

0:12:52.559,0:12:58.620
we already have enough to cover with a

0:12:54.350,0:13:02.249
14 and 15 the only thing is that you

0:12:58.620,0:13:05.040
might seem that we have two Jet's that

0:13:02.249,0:13:07.829
are in kind of yellow orange color those

0:13:05.040,0:13:09.629
have been delivered by someone else than

0:13:07.829,0:13:11.189
Oracle so the one in blacks are coming

0:13:09.629,0:13:14.879
from Oracle and yellow one are coming

0:13:11.189,0:13:17.240
from other open JDK members and I

0:13:14.879,0:13:20.490
believe those two are coming from reddit

0:13:17.240,0:13:22.470
then we had 11 which was a pretty big

0:13:20.490,0:13:24.060
release in terms of capability the thing

0:13:22.470,0:13:26.580
to keep in mind is that any features

0:13:24.060,0:13:28.950
release is driven by the dates so it's

0:13:26.580,0:13:32.250
either March or September's they are not

0:13:28.950,0:13:34.230
driven by features so if if a feature is

0:13:32.250,0:13:35.820
not ready to be included in a given

0:13:34.230,0:13:38.339
feature release well it's not an issue

0:13:35.820,0:13:46.790
that features will just have to wait the

0:13:38.339,0:13:49.709
next feature release 12 March 29 13

0:13:46.790,0:13:54.149
September 20 1913 was clearly a

0:13:49.709,0:13:56.810
relatively small release but yeah anyway

0:13:54.149,0:14:00.630
14 that was released two months ago

0:13:56.810,0:14:02.520
basically well cope with the fact that

0:14:00.630,0:14:03.810
nothing was really modest but again the

0:14:02.520,0:14:07.380
only thing that did drive those release

0:14:03.810,0:14:09.990
is the due dates not the content so

0:14:07.380,0:14:11.970
today we're gonna discuss us some of

0:14:09.990,0:14:16.950
those jabs that have been headed in a

0:14:11.970,0:14:19.140
Java 14 again we see that there are two

0:14:16.950,0:14:22.350
Jet's coming from know that are not

0:14:19.140,0:14:24.720
coming from Oracle non-volatile byte

0:14:22.350,0:14:26.790
buffer I think is coming from Reddit and

0:14:24.720,0:14:30.770
helpful pointer exception that we're

0:14:26.790,0:14:30.770
gonna discuss later is coming from sa P

0:14:32.390,0:14:39.450
okay so Java 14 was released in March

0:14:36.240,0:14:42.120
2020 everything is open source Sajida GD

0:14:39.450,0:14:44.880
k dot java.net slash 14 you can have

0:14:42.120,0:14:46.350
access to the open JDK builds of 14 you

0:14:44.880,0:14:48.870
can also have access to all the

0:14:46.350,0:14:53.670
technicals content for regarding that

0:14:48.870,0:14:55.589
release now quickly Java 15 what do we

0:14:53.670,0:14:58.200
know about Java 15 well first and

0:14:55.589,0:15:02.250
foremost we know that Java 15 will be

0:14:58.200,0:15:04.410
released in September 2020 we also know

0:15:02.250,0:15:07.440
the schedule so we know that random

0:15:04.410,0:15:09.990
phase 1 that's basically when we have

0:15:07.440,0:15:14.640
the feature freeze is in 1 months from

0:15:09.990,0:15:16.680
now so 1111 of of June so today based on

0:15:14.640,0:15:19.140
the information that is available in the

0:15:16.680,0:15:21.750
open JDK project we can already discuss

0:15:19.140,0:15:24.270
about what's being planned within 15

0:15:21.750,0:15:26.190
that's what I'm gonna do today now keep

0:15:24.270,0:15:28.350
in mind that things can obviously still

0:15:26.190,0:15:30.089
change we can add things at the very

0:15:28.350,0:15:31.740
last minute or we can even drop things

0:15:30.089,0:15:34.020
at the very last minute depending on

0:15:31.740,0:15:36.330
well on some stability

0:15:34.020,0:15:40.470
issue or something else things can might

0:15:36.330,0:15:44.700
still evolve so that those tunings

0:15:40.470,0:15:53.970
basically gives you the content that is

0:15:44.700,0:15:55.529
plane 414 so we clearly well it's a very

0:15:53.970,0:15:58.860
interesting time for Java because we

0:15:55.529,0:16:02.610
clearly have a very rich pipeline when

0:15:58.860,0:16:05.339
it comes to features why because my well

0:16:02.610,0:16:09.149
quite as well I wouldn't say many years

0:16:05.339,0:16:10.680
ago but five to four years ago we have

0:16:09.149,0:16:14.220
decided to work on very ambitious

0:16:10.680,0:16:17.459
project a multiple project that where

0:16:14.220,0:16:21.410
long terms are in the project and they

0:16:17.459,0:16:23.730
each had a goal to basically either

0:16:21.410,0:16:26.700
fundamentally improve certain aspect of

0:16:23.730,0:16:29.790
the Java platform or event reeve revamp

0:16:26.700,0:16:32.040
a given aspect of the platform so I'm

0:16:29.790,0:16:34.589
going to discuss some of those today the

0:16:32.040,0:16:37.980
GCC amber Panama Varela metropolice loom

0:16:34.589,0:16:41.370
and so on so very quickly the first one

0:16:37.980,0:16:44.100
that I want to discuss is the GC 0 GC so

0:16:41.370,0:16:47.070
it's low latency scalable garbage

0:16:44.100,0:16:48.540
collector that we started to work on few

0:16:47.070,0:16:52.020
years ago it was introduced as

0:16:48.540,0:16:55.170
experimental features in Java 11 and the

0:16:52.020,0:16:58.470
main goal of the GC is basically gives

0:16:55.170,0:17:00.540
you the lowest latency possible so it's

0:16:58.470,0:17:02.730
a concurrent GC meaning that all the

0:17:00.540,0:17:05.010
heavy lifting work of the GC is done

0:17:02.730,0:17:08.670
basically while your Java threads are

0:17:05.010,0:17:10.920
being executed so there are a few posts

0:17:08.670,0:17:14.520
but they are reduced to about well to

0:17:10.920,0:17:17.370
the smallest possible to the smallest

0:17:14.520,0:17:19.650
time possible we claim that the post

0:17:17.370,0:17:22.020
time should stay below 10 milliseconds

0:17:19.650,0:17:24.900
with on with the GC but what we observe

0:17:22.020,0:17:26.850
is that most of the time the poles are

0:17:24.900,0:17:29.179
more around 2 milliseconds which

0:17:26.850,0:17:32.400
obviously is very low

0:17:29.179,0:17:35.460
it's callable in the sense that the post

0:17:32.400,0:17:39.179
time will not increase as you grow your

0:17:35.460,0:17:40.770
Y or your life sets so the 10

0:17:39.179,0:17:42.120
millisecond post time is something that

0:17:40.770,0:17:44.700
you would get typically on a one

0:17:42.120,0:17:49.580
gigabyte it but also on a one terabyte

0:17:44.700,0:17:49.580
if so there's no change in that from

0:17:49.669,0:17:54.600
judges in the in the early days was

0:17:52.080,0:17:56.460
designed for large ships multi terabyte

0:17:54.600,0:17:58.740
if but it turns out that they are used

0:17:56.460,0:18:00.899
case where it also make sense to use the

0:17:58.740,0:18:02.490
GC for smaller hips so one of the

0:18:00.899,0:18:04.950
features that we have added recently is

0:18:02.490,0:18:06.750
the support for a few megabytes it's I

0:18:04.950,0:18:11.549
think that the law was that we can go is

0:18:06.750,0:18:14.039
8 megabytes so how do you use as a GC

0:18:11.549,0:18:16.200
today so I mentioned that the GC was

0:18:14.039,0:18:20.870
added as an experimental feature in a

0:18:16.200,0:18:24.000
Java 11 so you need to unlock explicitly

0:18:20.870,0:18:27.299
the GC so there is a specific hotspot

0:18:24.000,0:18:28.889
flag unlock experimental a vm option to

0:18:27.299,0:18:31.500
basically unlock any experimental

0:18:28.889,0:18:34.710
feature of the vm so you do that and

0:18:31.500,0:18:37.799
then you use the specific flag to enable

0:18:34.710,0:18:40.320
the GC so basically to sell the vm to

0:18:37.799,0:18:41.700
switch from g1 which is the default GC

0:18:40.320,0:18:44.730
to zgc

0:18:41.700,0:18:47.789
and there we go then the thing that you

0:18:44.730,0:18:50.580
might want to do is tune the GC to tune

0:18:47.789,0:18:53.279
the GC the thing that you need to do

0:18:50.580,0:18:56.330
basically is just said the each size one

0:18:53.279,0:19:01.200
of the design goal of the GC was also to

0:18:56.330,0:19:02.519
provide a default behavior that avoid

0:19:01.200,0:19:04.289
any tunings

0:19:02.519,0:19:06.659
obviously you still have the ability to

0:19:04.289,0:19:10.409
do more tuning than just setting the hip

0:19:06.659,0:19:12.539
size but by default the GC should should

0:19:10.409,0:19:17.700
give you a good result with just setting

0:19:12.539,0:19:19.940
the website so AGC what is the history

0:19:17.700,0:19:23.669
behind the GC GC was initially

0:19:19.940,0:19:27.450
introduced in 11 as an experimental

0:19:23.669,0:19:30.950
features on linux we have hadded

0:19:27.450,0:19:35.120
additional capabilities in 12 intersted

0:19:30.950,0:19:37.740
the GC support was added for arm 64 and

0:19:35.120,0:19:39.510
finally in 14 so there is that we have

0:19:37.740,0:19:43.220
done two months ago is hiring support

0:19:39.510,0:19:45.720
for Mac OS and windows for the GC and

0:19:43.220,0:19:47.399
the plan is to make the GC as a

0:19:45.720,0:19:50.039
production feature so basically we are

0:19:47.399,0:19:55.429
removing that experimental flag from the

0:19:50.039,0:19:55.429
future in DDF 15 so this year

0:19:57.740,0:20:04.850
so this is a picture that I took only

0:20:00.850,0:20:07.240
earlier this year in Sweden and on stage

0:20:04.850,0:20:09.620
was a Monica Beckwith from Microsoft and

0:20:07.240,0:20:11.360
well that's her claim it's not my claim

0:20:09.620,0:20:13.370
so zgc shine when it comes to

0:20:11.360,0:20:15.740
responsiveness so I encourage you to

0:20:13.370,0:20:18.200
check her presentation which is now

0:20:15.740,0:20:23.510
online where she goes basically about

0:20:18.200,0:20:26.419
the benefit of zgc now let's quickly

0:20:23.510,0:20:29.899
talk about G 1 G C so G 1 G C is the

0:20:26.419,0:20:32.510
default G C obviously we have made a lot

0:20:29.899,0:20:35.480
of investment within GGC but that

0:20:32.510,0:20:39.260
doesn't mean that we were not looking at

0:20:35.480,0:20:42.320
improving G 1 so for example in 14 we

0:20:39.260,0:20:45.380
had it support for a new ma so new must

0:20:42.320,0:20:48.770
stand for non-uniform memory access so

0:20:45.380,0:20:52.070
basically that means that some some

0:20:48.770,0:20:53.840
memory might be well the distance

0:20:52.070,0:20:56.659
between the memory and the course is not

0:20:53.840,0:20:58.370
always equal so from 1 cor accessing a

0:20:56.659,0:21:00.559
given memory might be more expensive

0:20:58.370,0:21:04.159
because it's more distant than accesses

0:21:00.559,0:21:07.309
memory in a different part of the well

0:21:04.159,0:21:10.909
formed from a different course parallel

0:21:07.309,0:21:14.480
GC was new more worse in C this a long

0:21:10.909,0:21:20.299
time so in 14 we have had it support

0:21:14.480,0:21:22.039
Numa support for G 1 and that's not all

0:21:20.299,0:21:23.960
if we look at the number of an

0:21:22.039,0:21:27.020
enhancement that we have done in our on

0:21:23.960,0:21:30.440
G 1 since gk8 it's over 700

0:21:27.020,0:21:36.169
announcements that together greatly

0:21:30.440,0:21:37.909
improve G 1 so the shafts shows for

0:21:36.169,0:21:39.649
example so the shots below shows the

0:21:37.909,0:21:43.640
native memory overhead caused it by the

0:21:39.649,0:21:46.490
by your G 1 GC for a heap size of 6 16

0:21:43.640,0:21:49.399
mega byte and what we can see is that

0:21:46.490,0:21:53.029
well if we look at g DK 8 the extra

0:21:49.399,0:21:56.000
native memory was a run for megabyte in

0:21:53.029,0:21:59.360
11 it was around well it was below 3

0:21:56.000,0:22:05.360
sorry I said megabytes gigabytes so 8

0:21:59.360,0:22:07.950
need an additional 4 gigabyte 2 GC that

0:22:05.360,0:22:15.190
large heap

0:22:07.950,0:22:18.010
GDK 11 it was reduced to I think 2.7

0:22:15.190,0:22:21.610
gigabyte and in 14 its it has been

0:22:18.010,0:22:24.250
reduced to 1.7 gigabyte so basically you

0:22:21.610,0:22:27.100
see that by switching from 8 to 14 we

0:22:24.250,0:22:29.860
have greatly reduced the memory

0:22:27.100,0:22:32.320
footprint of g1 not only that we also

0:22:29.860,0:22:34.000
improve the performance so basically

0:22:32.320,0:22:37.120
when you put together all those heaven

0:22:34.000,0:22:42.360
and reading enhancements that improves

0:22:37.120,0:22:47.380
g1 a lot across all areas so throughput

0:22:42.360,0:22:49.540
footprint latency and so on and so on so

0:22:47.380,0:22:55.480
that's something that you you need to

0:22:49.540,0:22:57.280
consider if obviously GC well the GC GC

0:22:55.480,0:22:59.530
characteristic as you are important to

0:22:57.280,0:23:05.640
you you need to think about moving to a

0:22:59.530,0:23:08.500
newer version of the of the platform so

0:23:05.640,0:23:10.600
this is another chart that shows some of

0:23:08.500,0:23:13.180
the management that have been done to g1

0:23:10.600,0:23:17.170
so let's see this is using the standard

0:23:13.180,0:23:21.390
spec gbb benchmark so this one is using

0:23:17.170,0:23:24.460
a fix it fix hip so set to 4 gigabyte

0:23:21.390,0:23:27.580
all the results are normalized and I her

0:23:24.460,0:23:30.010
is better so we have maxed G ops and

0:23:27.580,0:23:32.320
quick LG ops both are looking at the

0:23:30.010,0:23:34.630
throughput the thing is that quick LG G

0:23:32.320,0:23:37.890
ops is looking in addition to throughput

0:23:34.630,0:23:43.870
is also looking at Latin Z's

0:23:37.890,0:23:45.880
so we can see that parallel GC has been

0:23:43.870,0:23:49.780
included so the performance of our LG C

0:23:45.880,0:23:51.490
has been increased between 8 and 14 but

0:23:49.780,0:23:54.820
we can also see that there is a huge

0:23:51.490,0:23:58.510
boost in terms of latency improvement

0:23:54.820,0:24:02.470
when it comes to G 1 in 14 having said

0:23:58.510,0:24:05.860
that if you look sorry at this slide at

0:24:02.470,0:24:08.350
the next slides we see in this

0:24:05.860,0:24:11.050
particular case so this is whether with

0:24:08.350,0:24:13.660
a heap of 16 GB gigabyte that there has

0:24:11.050,0:24:16.330
been a regression between 8 well we I

0:24:13.660,0:24:19.570
don't have the result of G 1 here but we

0:24:16.330,0:24:20.650
can clearly see that there is a drop so

0:24:19.570,0:24:24.550
we had a

0:24:20.650,0:24:28.960
aggression basically and I don't

0:24:24.550,0:24:32.050
remember the exact issue if you want to

0:24:28.960,0:24:33.280
know more about the given bug it's you

0:24:32.050,0:24:36.250
just need to check the blocks at the

0:24:33.280,0:24:41.350
bottom of the slides but that issue has

0:24:36.250,0:24:46.330
been solved so we can clearly see that G

0:24:41.350,0:24:48.550
1 in 15 will improve the latencies we

0:24:46.330,0:24:50.770
see that the throughput is is while

0:24:48.550,0:24:53.140
there is a slight drop in terms of

0:24:50.770,0:24:57.340
throughput only 97 percent versus

0:24:53.140,0:24:59.380
hundred percent well it's a small it's a

0:24:57.340,0:25:01.000
small basically small trade-off but when

0:24:59.380,0:25:03.340
we see the benefit that gives that it

0:25:01.000,0:25:04.960
gives in terms of latency improvement I

0:25:03.340,0:25:14.170
think that it's fair to say that it's ok

0:25:04.960,0:25:16.690
to pay that that's more price so quickly

0:25:14.170,0:25:19.240
stuffed-up time is something that we

0:25:16.690,0:25:21.520
always look to improve in all the Java

0:25:19.240,0:25:24.220
release and obviously 14 is not is not

0:25:21.520,0:25:26.800
an exception now we can see in this case

0:25:24.220,0:25:28.630
that the stuff that time for a given

0:25:26.800,0:25:30.940
it's a small application it's basically

0:25:28.630,0:25:31.810
a HelloWorld application there is a

0:25:30.940,0:25:34.900
small improvement

0:25:31.810,0:25:36.610
obviously the as faster we get the more

0:25:34.900,0:25:39.220
difficult it is to find large

0:25:36.610,0:25:41.230
improvement but still between 13 and 14

0:25:39.220,0:25:42.970
the startup time has been improved and I

0:25:41.230,0:25:47.920
can already tell you that between 14 and

0:25:42.970,0:25:51.040
15 it we still slightly improved now

0:25:47.920,0:25:53.020
this is basically the same benchmark but

0:25:51.040,0:25:54.760
with different scenarios so a hello

0:25:53.020,0:25:56.230
world application a hello world

0:25:54.760,0:25:58.150
application that uses a lambda

0:25:56.230,0:25:59.980
expression and then a hello world

0:25:58.150,0:26:01.810
application that is using a conquered

0:25:59.980,0:26:03.640
string I think I knew basically seen

0:26:01.810,0:26:06.370
that across all the release we are

0:26:03.640,0:26:07.720
improving the startup time for those

0:26:06.370,0:26:11.200
different scenarios so that's something

0:26:07.720,0:26:12.910
that again is useful over time whenever

0:26:11.200,0:26:20.320
you switch to a larger to a newer

0:26:12.910,0:26:24.280
version of Java so now let's talk so we

0:26:20.320,0:26:26.380
have discussed about the GC which which

0:26:24.280,0:26:28.510
is one of that those ambitious project

0:26:26.380,0:26:31.920
basically having a new garbage

0:26:28.510,0:26:34.600
collectors that provide low latency

0:26:31.920,0:26:36.820
another one that deal with memory

0:26:34.600,0:26:41.110
is project Valhalla and that that is a

0:26:36.820,0:26:42.700
clearly very ambitious project so the

0:26:41.110,0:26:45.429
code of general of vanilla is basically

0:26:42.700,0:26:49.480
to reboot the relationship that the gvm

0:26:45.429,0:26:51.220
are with the data in memory so if you

0:26:49.480,0:26:53.080
know Java you know that Java is very

0:26:51.220,0:26:55.870
good at optimizing code we have for

0:26:53.080,0:27:00.009
example a JIT compiler that will improve

0:26:55.870,0:27:02.350
over time your code as it runs so on

0:27:00.009,0:27:04.330
that side we're good but the next step

0:27:02.350,0:27:08.259
is we to look on how we can optimize a

0:27:04.330,0:27:10.440
data in memory now there's an issue we

0:27:08.259,0:27:12.159
have the jet d'eau Java type systems

0:27:10.440,0:27:14.559
something that obviously is very

0:27:12.159,0:27:16.899
powerful but there is a price price to

0:27:14.559,0:27:19.899
pay and sometimes we miss a bit of

0:27:16.899,0:27:22.330
flexibility and that's basically due to

0:27:19.899,0:27:25.210
the fact that each object has an

0:27:22.330,0:27:27.340
identity it's something that obviously

0:27:25.210,0:27:30.190
is needed we are not going to get rid of

0:27:27.340,0:27:33.039
object identity it enables mobility

0:27:30.190,0:27:35.340
polymorphism and so on and so on on the

0:27:33.039,0:27:38.529
other hand there are some use case where

0:27:35.340,0:27:41.440
objects might not need identity but

0:27:38.529,0:27:43.870
still today they have to pay the price

0:27:41.440,0:27:47.039
for that features even though those

0:27:43.870,0:27:50.620
object might not benefit from identity

0:27:47.039,0:27:54.100
so basically project Valhalla is looking

0:27:50.620,0:27:57.070
at how we can improve the density of

0:27:54.100,0:27:59.769
information within memory and the thing

0:27:57.070,0:28:04.120
that the team is looking at is basically

0:27:59.769,0:28:06.940
how we can declaratively say that ok for

0:28:04.120,0:28:09.370
that type of object I don't need that

0:28:06.940,0:28:11.529
object to handle an identity it's not

0:28:09.370,0:28:14.440
something that can be done automatically

0:28:11.529,0:28:16.059
so that we involve some help from the

0:28:14.440,0:28:18.789
developers so the developer will have to

0:28:16.059,0:28:21.220
specifically say or specifically say ok

0:28:18.789,0:28:23.679
for that type of object I don't need

0:28:21.220,0:28:26.200
identity and then the VM will be able to

0:28:23.679,0:28:29.440
improve out those object will be stored

0:28:26.200,0:28:32.860
into memory and the VM will be able to

0:28:29.440,0:28:37.600
increase the density to a memory density

0:28:32.860,0:28:44.480
for those type of objects another pro

0:28:37.600,0:28:46.610
is projecting so if you look today they

0:28:44.480,0:28:48.620
are well I will simplify a little bit

0:28:46.610,0:28:52.610
but there are two types of programming

0:28:48.620,0:28:56.000
approach so you have a traditional

0:28:52.610,0:28:58.640
blocking approach so it's very easy to

0:28:56.000,0:29:00.260
program to develop with the thing is

0:28:58.640,0:29:03.140
that well it's so it's very easy to

0:29:00.260,0:29:05.150
develop it's also very easy to debug the

0:29:03.140,0:29:07.700
thing is that that approach doesn't

0:29:05.150,0:29:09.620
scale as soon as your code blocks

0:29:07.700,0:29:11.900
well basically your code is waiting for

0:29:09.620,0:29:13.910
something to happen so you are using

0:29:11.900,0:29:16.490
while you are blocking resources

0:29:13.910,0:29:18.880
that's not very effective on the other

0:29:16.490,0:29:22.550
hand you can go for a model that is more

0:29:18.880,0:29:23.870
geared towards a reactive approach the

0:29:22.550,0:29:26.390
thing is that developing reactive

0:29:23.870,0:29:29.240
application well that's on one hand a

0:29:26.390,0:29:33.350
very difficult model to program with and

0:29:29.240,0:29:37.220
more importantly that the code you write

0:29:33.350,0:29:39.350
is very difficult to debug enhance to

0:29:37.220,0:29:41.180
maintain typically if you try to debug a

0:29:39.350,0:29:43.280
reactive application well you see that

0:29:41.180,0:29:45.410
something you have an issue here but in

0:29:43.280,0:29:47.690
fact the issue is not reopening on that

0:29:45.410,0:29:49.520
well in that region of the application

0:29:47.690,0:29:51.950
but it happens on for somewhere else but

0:29:49.520,0:29:53.750
it's very basically it's very difficult

0:29:51.950,0:29:56.570
to do correlation between an issue and

0:29:53.750,0:29:59.600
where it happened within the flow of the

0:29:56.570,0:30:02.360
code but still if you want to scale if

0:29:59.600,0:30:04.460
you want to have efficient resource use

0:30:02.360,0:30:07.670
of you you need to go to other approach

0:30:04.460,0:30:10.660
that approach so a project loom is

0:30:07.670,0:30:14.170
basically trying to solve that by making

0:30:10.660,0:30:18.500
concurrency simple again ow

0:30:14.170,0:30:21.320
right now the JVM is using native

0:30:18.500,0:30:23.030
threads kernel threads loom introduced

0:30:21.320,0:30:26.690
the notion of your 12 threads which are

0:30:23.030,0:30:30.110
basically two threads that are managed

0:30:26.690,0:30:34.010
by the JVM so those threads are some

0:30:30.110,0:30:36.050
kind of well visual threads software

0:30:34.010,0:30:38.900
threads that are managed and he ruled by

0:30:36.050,0:30:40.430
the JVM and obviously the JVM will have

0:30:38.900,0:30:42.740
to do mapping between those virtual

0:30:40.430,0:30:45.440
thread and some underlying kernel

0:30:42.740,0:30:47.540
carrier thread but that that isn't

0:30:45.440,0:30:49.820
dulled by the JVM and the thing is that

0:30:47.540,0:30:51.800
those virtual threads are very very

0:30:49.820,0:30:53.360
cheap so it doesn't

0:30:51.800,0:30:54.980
it's not a really an issue to write code

0:30:53.360,0:30:56.750
that is blocking because the virtual

0:30:54.980,0:31:01.280
thread that is blocking is not blocking

0:30:56.750,0:31:02.630
an actual underlying physical threads so

0:31:01.280,0:31:04.610
basically you can write application

0:31:02.630,0:31:07.390
using virtual thread your code can

0:31:04.610,0:31:12.320
blocks but you don't have to pay of

0:31:07.390,0:31:15.680
resource and the virtualization so those

0:31:12.320,0:31:17.780
that are so cheap that it well you don't

0:31:15.680,0:31:20.060
have an ax you don't haven't have to

0:31:17.780,0:31:22.360
pull those threads so you just block the

0:31:20.060,0:31:24.860
thread and you you start a new thread

0:31:22.360,0:31:26.720
it's it's it's it's not an issue because

0:31:24.860,0:31:29.000
those threads are very cheap so that's

0:31:26.720,0:31:32.240
basically what a loom is trying to

0:31:29.000,0:31:35.660
solved now those days we have multiple

0:31:32.240,0:31:36.980
early access build of loom if we look in

0:31:35.660,0:31:39.740
the platform there are already a few

0:31:36.980,0:31:42.020
gems that are been that have been added

0:31:39.740,0:31:45.890
in the platform for loom and more

0:31:42.020,0:31:48.230
specifically in GDK 14 we have we have

0:31:45.890,0:31:50.660
hope we implemented the legacy socket

0:31:48.230,0:31:52.820
API that was something in preparation

0:31:50.660,0:31:54.740
for something that's coming in JDK 15

0:31:52.820,0:31:57.620
which is or implementing the legacy data

0:31:54.740,0:32:03.710
so grew that diagram socket API which

0:31:57.620,0:32:08.240
has been done in preparation of flume so

0:32:03.710,0:32:10.280
another large project is Panama so the

0:32:08.240,0:32:12.290
goal of Panama is basically to arrange

0:32:10.280,0:32:14.000
to enrich the interaction between the

0:32:12.290,0:32:18.950
Java Virtual Machine and a foreign

0:32:14.000,0:32:22.280
native code historically we had gni for

0:32:18.950,0:32:24.080
that Java native interface but gni has

0:32:22.280,0:32:27.200
been specifically designed in the early

0:32:24.080,0:32:29.780
days to be I would say not friendly to

0:32:27.200,0:32:32.960
use we want to basically provide an

0:32:29.780,0:32:36.250
alternative to Ginny I wear it is easy

0:32:32.960,0:32:40.630
safe and efficient to use from Java

0:32:36.250,0:32:43.760
nutella's to use native code from Java

0:32:40.630,0:32:46.760
if we look at the deliverables of Panama

0:32:43.760,0:32:49.580
there are three main deliverables the

0:32:46.760,0:32:51.680
foreign memory access API which is in 14

0:32:49.580,0:32:53.630
in incubator so that's something that

0:32:51.680,0:32:56.210
you can use already today

0:32:53.630,0:33:00.830
it basically allowed to efficiently and

0:32:56.210,0:33:02.960
safely use of memory of that is not on

0:33:00.830,0:33:05.290
the Java app but you can access that

0:33:02.960,0:33:08.300
memory from Java code

0:33:05.290,0:33:10.070
then there is an extraction part it's

0:33:08.300,0:33:17.630
basically the ability to extract from

0:33:10.070,0:33:20.390
sea native header files so the extract

0:33:17.630,0:33:22.790
interface and generate binders that you

0:33:20.390,0:33:24.890
can use directly from Java code there

0:33:22.790,0:33:27.050
are two parts for the extraction parts

0:33:24.890,0:33:29.090
that there is a tool that mimic that

0:33:27.050,0:33:31.640
mechanically do the extraction but there

0:33:29.090,0:33:33.940
also no API that more advanced developer

0:33:31.640,0:33:36.920
can use to meet more advanced scenarios

0:33:33.940,0:33:38.900
and last but not least there's the

0:33:36.920,0:33:40.880
vector API which allows to easily

0:33:38.900,0:33:43.400
express vector computation that will

0:33:40.880,0:33:48.110
compile at runtime and execute on a

0:33:43.400,0:33:53.840
vector on CPU that support vector vector

0:33:48.110,0:33:58.120
eyes extension such as SSE or AVX 4md

0:33:53.840,0:34:01.340
your arms scalable vector extension and

0:33:58.120,0:34:03.230
the vector RP I is right now in

0:34:01.340,0:34:03.740
incubator candidate so we don't know

0:34:03.230,0:34:07.100
yeah

0:34:03.740,0:34:09.590
yet in which GD Carol is it will be

0:34:07.100,0:34:11.540
headed so today what we have for loom is

0:34:09.590,0:34:12.950
the foreign memory access API in

0:34:11.540,0:34:14.420
incubator that's something that you can

0:34:12.950,0:34:18.470
use and we also have a early access

0:34:14.420,0:34:21.230
build for the extraction part and then I

0:34:18.470,0:34:23.630
also put this in the Panama part even

0:34:21.230,0:34:25.550
though that specific job is not really

0:34:23.630,0:34:28.220
part of Panama but given that it's very

0:34:25.550,0:34:31.220
close to the hardware and well I put it

0:34:28.220,0:34:35.290
here so jet 3-5-2 basically had the

0:34:31.220,0:34:38.300
ability to manage non-volatile memory

0:34:35.290,0:34:40.010
via byte buffer that's something very

0:34:38.300,0:34:43.700
specific so I'm not going to discuss

0:34:40.010,0:34:50.660
about that anymore so what I'm going to

0:34:43.700,0:34:51.580
do now is a very small Panama demo so it

0:34:50.660,0:35:01.330
takes a bit of time

0:34:51.580,0:35:03.240
switch okay so let's see so I hope that

0:35:01.330,0:35:07.350
it's big enough

0:35:03.240,0:35:09.940
so whatever here I have a very simple

0:35:07.350,0:35:16.090
java application but first I'm going to

0:35:09.940,0:35:22.770
go let's see where is it no so I'm on

0:35:16.090,0:35:22.770
six this is a Linux so I sign in Linux

0:35:27.180,0:35:39.040
no I don't want to do that well I fit

0:35:33.910,0:35:45.160
the name and sorry let me check okay

0:35:39.040,0:35:47.860
this this or sorry too small you know

0:35:45.160,0:35:51.730
it's red line so this is a header file

0:35:47.860,0:35:53.830
that is part of a five six so this is a

0:35:51.730,0:35:55.780
real line library that basically give us

0:35:53.830,0:35:58.150
read line support of something very

0:35:55.780,0:36:00.520
basic so there are multiple function and

0:35:58.150,0:36:02.530
what I want to do here is you use one of

0:36:00.520,0:36:05.290
the one of the red line function from

0:36:02.530,0:36:08.020
Java so the first thing that I need to

0:36:05.290,0:36:12.120
do is use the extract tool to basically

0:36:08.020,0:36:14.260
parse the red line header files to

0:36:12.120,0:36:16.470
extract all the information and then

0:36:14.260,0:36:19.480
generate the binder interface for that

0:36:16.470,0:36:22.000
so I'm going to use this G extract tool

0:36:19.480,0:36:24.100
so and I specify here that this is the

0:36:22.000,0:36:27.280
past for example of the library the G

0:36:24.100,0:36:29.260
the riddling library this is the path of

0:36:27.280,0:36:33.550
the header file that we want to x-ray it

0:36:29.260,0:36:37.290
and what I want is that I want the

0:36:33.550,0:36:37.290
outcome to be in that a jar file

0:36:37.860,0:36:44.080
obviously I'm not on the right version

0:36:40.180,0:36:52.930
so let's see I'm on 14 and I'm I need to

0:36:44.080,0:36:55.770
switch G so I'm going to switch to a

0:36:52.930,0:37:00.700
specific GDK build that support panama

0:36:55.770,0:37:05.290
and it's 14 I think oops

0:37:00.700,0:37:07.829
ramaa yes so let's invoke jig strike G

0:37:05.290,0:37:07.829
extract again

0:37:12.480,0:37:17.920
okay bunch of warning but this is a

0:37:14.680,0:37:20.829
early access build okay now I have this

0:37:17.920,0:37:23.440
jar that has been generated so what I

0:37:20.829,0:37:26.050
want to do is basically I have this

0:37:23.440,0:37:27.190
small java application we can very

0:37:26.050,0:37:29.980
quickly go over the code of that

0:37:27.190,0:37:34.690
application so a scope is something that

0:37:29.980,0:37:37.680
is provided by the foreign memory yes

0:37:34.690,0:37:40.599
the foreign memory api of panama and

0:37:37.680,0:37:42.700
basically scope are used to enforce

0:37:40.599,0:37:45.550
lightness checks on scope resources so

0:37:42.700,0:37:47.560
it's basically some sort of memory but

0:37:45.550,0:37:51.310
that we were allocated on the other side

0:37:47.560,0:37:53.710
so on the native side we need to enforce

0:37:51.310,0:37:55.210
likeness because whenever we are locate

0:37:53.710,0:37:56.740
on the other sides of the fence so on

0:37:55.210,0:37:58.540
the native side obviously at some point

0:37:56.740,0:38:01.950
in time what has been allocated needs to

0:37:58.540,0:38:05.770
be dedicated so that's why we need scope

0:38:01.950,0:38:10.240
so I create a scope then from that scope

0:38:05.770,0:38:12.010
has I allocate a string I pass it I pass

0:38:10.240,0:38:15.430
in the screen name so we're on the on

0:38:12.010,0:38:16.990
the sea side and then I'm just invoking

0:38:15.430,0:38:19.780
that function that is coming from the

0:38:16.990,0:38:21.280
redline library using this pointer that

0:38:19.780,0:38:23.740
is defined here so basically I'm just

0:38:21.280,0:38:26.140
passing this string to the native

0:38:23.740,0:38:29.470
function and what we get in return is a

0:38:26.140,0:38:31.599
P object which is a pointer and then I'm

0:38:29.470,0:38:33.700
just deploying displaying that object so

0:38:31.599,0:38:36.010
this is a two string method invocation

0:38:33.700,0:38:38.829
on the P so on the pointer object and

0:38:36.010,0:38:41.109
then I use this static method to

0:38:38.829,0:38:47.609
basically get the content of that

0:38:41.109,0:38:47.609
pointer so let's compile that so Java C

0:38:49.740,0:39:02.260
let's see class bus I specify the jar

0:38:55.710,0:39:07.859
redline and then the source okay now I

0:39:02.260,0:39:07.859
need to run that

0:39:09.930,0:39:20.740
that guy so name so this is basically

0:39:17.970,0:39:24.910
this line here where we invoke the real

0:39:20.740,0:39:27.790
line so this is the CE OS six function

0:39:24.910,0:39:30.760
that is invoke I pass it's something

0:39:27.790,0:39:33.670
test and then the result is the

0:39:30.760,0:39:35.440
following so it's a so the type is a

0:39:33.670,0:39:37.810
bonding pointer so this is this line in

0:39:35.440,0:39:41.560
fact to string on that P object-- which

0:39:37.810,0:39:43.870
is a pointer and then so this is all the

0:39:41.560,0:39:45.340
result of the two string information all

0:39:43.870,0:39:47.530
the information that we get the idea to

0:39:45.340,0:39:51.700
string and then the last thing is this

0:39:47.530,0:39:53.950
test which is basically we asked the

0:39:51.700,0:39:55.720
foreign memory API to give us the

0:39:53.950,0:39:57.880
content that is pointed on the other

0:39:55.720,0:40:02.280
side of the fence but by that given

0:39:57.880,0:40:02.280
pointer so this is in a nutshell how

0:40:03.000,0:40:10.960
panamá works so if you if you have any

0:40:08.770,0:40:14.470
question you can use the chat or we can

0:40:10.960,0:40:16.660
discuss at the end it's up to you so

0:40:14.470,0:40:18.730
moving on another big project is a

0:40:16.660,0:40:20.590
project ember so the goal of amber is

0:40:18.730,0:40:22.750
basically to continue continuously

0:40:20.590,0:40:24.850
improve developer productivity through

0:40:22.750,0:40:26.380
the evolution of the java language so

0:40:24.850,0:40:27.940
it's not something that happened through

0:40:26.380,0:40:30.810
one single release it's something that

0:40:27.940,0:40:33.550
we have started around a Java 10 and

0:40:30.810,0:40:35.170
since Java 10 we have hadded new

0:40:33.550,0:40:38.380
features which are basically emerging

0:40:35.170,0:40:41.490
from project amber var is a big one so

0:40:38.380,0:40:44.920
variable type inference was added in 10

0:40:41.490,0:40:47.290
in 14 we're having switch expression it

0:40:44.920,0:40:50.110
becomes a standard features after to run

0:40:47.290,0:40:52.540
off preview we're doing another round of

0:40:50.110,0:40:55.690
preview for text blocks we are

0:40:52.540,0:40:58.630
introducing records weren't sure

0:40:55.690,0:41:02.260
introducing also pattern matching with

0:40:58.630,0:41:05.860
instance of in preview 2 so I'm going to

0:41:02.260,0:41:09.780
discuss most of those features so the

0:41:05.860,0:41:09.780
first one is a record so

0:41:10.510,0:41:17.170
course basically give you the ability to

0:41:13.860,0:41:18.910
so they are providing a very compact

0:41:17.170,0:41:21.250
syntax for declaring class which are

0:41:18.910,0:41:24.490
data holder so basically a couple

0:41:21.250,0:41:26.260
inimitable trouble in which you can

0:41:24.490,0:41:29.680
store data and that's something that you

0:41:26.260,0:41:31.180
can basically pass around I'm going to

0:41:29.680,0:41:33.370
show you how it work so you will see

0:41:31.180,0:41:35.530
that well it's something that is a on

0:41:33.370,0:41:39.640
one hand very simple but on your hand

0:41:35.530,0:41:43.180
very efficient something else that is

0:41:39.640,0:41:47.680
coming from amber is a text blocks

0:41:43.180,0:41:48.810
so basically text blocks are multi-line

0:41:47.680,0:41:51.460
string literals

0:41:48.810,0:41:54.790
so take the following example so you

0:41:51.460,0:41:56.860
want to store the HTML that we have on

0:41:54.790,0:41:59.770
the left side typically you would do

0:41:56.860,0:42:01.540
something in your code with text blocks

0:41:59.770,0:42:05.050
you can now do that

0:42:01.540,0:42:07.240
so you basically keep the Descent acts

0:42:05.050,0:42:09.460
as it is you don't have to escape

0:42:07.240,0:42:12.280
anything this is something which is very

0:42:09.460,0:42:14.230
convenient for dealing with XML JSON ml

0:42:12.280,0:42:16.390
SQL and so on again that's something

0:42:14.230,0:42:22.300
that we will see in a demo in a minute

0:42:16.390,0:42:24.190
so then we have a pattern matching

0:42:22.300,0:42:26.260
that's something that we will see in the

0:42:24.190,0:42:30.250
demo it will be more clear and finally

0:42:26.260,0:42:32.860
we have a new switch expression so let's

0:42:30.250,0:42:43.000
go to the demo that will be a more

0:42:32.860,0:42:45.580
concrete so let's see well intelligence

0:42:43.000,0:42:48.870
already started so I'm going to very

0:42:45.580,0:42:48.870
quickly create a new project

0:42:57.940,0:43:08.730
I need to configure my compiler because

0:43:05.140,0:43:13.510
I don't know why but by default generate

0:43:08.730,0:43:15.430
Java c5 bytecode and then I also need to

0:43:13.510,0:43:18.130
configure my project and I'm gonna

0:43:15.430,0:43:18.720
increase the font for the code don't

0:43:18.130,0:43:23.319
worry

0:43:18.720,0:43:24.490
so here given that I'm gonna use SR it's

0:43:23.319,0:43:25.930
not here it's here

0:43:24.490,0:43:28.000
given that I'm going to use some preview

0:43:25.930,0:43:30.130
feature I need to ask specifically tell

0:43:28.000,0:43:32.020
to IntelliJ that I want to use preview

0:43:30.130,0:43:34.750
features because preview features are

0:43:32.020,0:43:38.950
not enabled by default and I also need

0:43:34.750,0:43:45.490
to do it let's see here so again I'm

0:43:38.950,0:44:08.140
going to use 14 preview features okay so

0:43:45.490,0:44:20.970
a source ok so let's just run that and

0:44:08.140,0:44:22.290
see if it works ok it works

0:44:20.970,0:44:25.830
so the first thing that I'm going to

0:44:22.290,0:44:28.200
show you is recourse so let's create a

0:44:25.830,0:44:33.450
record let's say that we want to create

0:44:28.200,0:44:39.780
a record for a persona and a person as a

0:44:33.450,0:44:40.290
name and a person as a first name and

0:44:39.780,0:44:43.050
that's it

0:44:40.290,0:44:47.810
it's all we have to do now what I can do

0:44:43.050,0:44:47.810
in my code is the following for example

0:44:48.710,0:45:03.349
so I can create a record and today

0:44:56.670,0:45:03.349
speakers is the let us say David oops

0:45:16.930,0:45:27.050
oops sorry it's obviously not a record

0:45:20.810,0:45:29.090
about a person okay so now I have this

0:45:27.050,0:45:43.070
speaker object that I can use so for

0:45:29.090,0:45:45.170
example a speaker so let's run that so

0:45:43.070,0:45:47.060
this is the result so this is basically

0:45:45.170,0:45:50.510
the to do to string method that is

0:45:47.060,0:45:56.960
invoke ated on that speaker object so

0:45:50.510,0:46:01.670
let's have a look at what has been what

0:45:56.960,0:46:03.080
we are here so target class we should

0:46:01.670,0:46:05.570
have two class so we have the test class

0:46:03.080,0:46:07.280
and we have this person claps so this is

0:46:05.570,0:46:10.700
our record so if we look at the record

0:46:07.280,0:46:13.460
itself so just by this simple

0:46:10.700,0:46:14.770
declaration we see that we have a few

0:46:13.460,0:46:18.140
methods that have been generated so

0:46:14.770,0:46:20.660
generated so the class person is final

0:46:18.140,0:46:23.060
it extends java.lang records it has a

0:46:20.660,0:46:24.800
few methods so it has a constructor it

0:46:23.060,0:46:26.690
has a two string it has a it has a

0:46:24.800,0:46:30.050
default ascot methods it has an equals

0:46:26.690,0:46:33.260
and then it has two gathers last and

0:46:30.050,0:46:41.420
first name so that means that I can for

0:46:33.260,0:46:43.190
example invoke one of those and we use

0:46:41.420,0:46:44.870
one of those method and you see that

0:46:43.190,0:46:47.900
this time we have the lab assay instead

0:46:44.870,0:46:50.360
of the two string so what we can do if

0:46:47.900,0:46:51.740
we look at the record itself obviously

0:46:50.360,0:46:55.040
this is the default behavior

0:46:51.740,0:47:00.310
I haven't specified anything I can

0:46:55.040,0:47:11.840
define my own constructor so person I

0:47:00.310,0:47:12.580
can say for example that let's see we

0:47:11.840,0:47:17.110
want to upper

0:47:12.580,0:47:32.920
case all the names right so let's run

0:47:17.110,0:47:35.620
that so you see that the lab assay is

0:47:32.920,0:47:37.140
now in uppercase and you see that the

0:47:35.620,0:47:39.670
only thing I had to do is basically I

0:47:37.140,0:47:41.980
just have to specify what needs to be

0:47:39.670,0:47:44.530
done with one of the the field I didn't

0:47:41.980,0:47:46.480
have to specify anything for the first

0:47:44.530,0:47:48.850
field so it has a default behavior but

0:47:46.480,0:47:56.280
now if I'm doing something like this for

0:47:48.850,0:48:09.880
example if let's see last is blank then

0:47:56.280,0:48:14.110
this last equal Nemo's here the compiler

0:48:09.880,0:48:16.450
will complain because last might not

0:48:14.110,0:48:18.550
have been initialized so if we go

0:48:16.450,0:48:21.100
through this branch of course last easy

0:48:18.550,0:48:23.740
last is initialized but that means that

0:48:21.100,0:48:25.750
we if we have a else it won't be so if

0:48:23.740,0:48:27.250
last name is not blank it won't be

0:48:25.750,0:48:29.530
initialized so to solve that basically

0:48:27.250,0:48:35.830
we need two other in this case a health

0:48:29.530,0:48:38.170
and so else this last fall's plus in

0:48:35.830,0:48:41.800
this case we have a default for second

0:48:38.170,0:48:53.620
branch and this case it it works so if I

0:48:41.800,0:48:57.150
have a blanks let's run that and you see

0:48:53.620,0:48:59.800
that this time oops sorry

0:48:57.150,0:49:02.050
it's the the first time is an animal's

0:48:59.800,0:49:05.370
because it is blank so that's basically

0:49:02.050,0:49:11.280
our record works

0:49:05.370,0:49:11.280
the next thing text blocks so let's see

0:49:12.600,0:49:20.020
for that I'm gonna yes so this is the my

0:49:17.680,0:49:23.260
the poem that has been generated so it's

0:49:20.020,0:49:26.080
just some XML so it's the pump from my

0:49:23.260,0:49:28.870
project and well I want

0:49:26.080,0:49:31.180
a string for that so for that I'm going

0:49:28.870,0:49:36.940
to use a text block so for that I'm used

0:49:31.180,0:49:45.330
a triple quotes and that's all it takes

0:49:36.940,0:49:45.330
now I can do so from South if I run that

0:49:47.040,0:49:55.330
well you see that the text blocks has

0:49:52.840,0:49:58.480
been is correctly including the ident a

0:49:55.330,0:50:02.680
tion because here I'm basically copy the

0:49:58.480,0:50:04.600
HTML as it was so what what I've done

0:50:02.680,0:50:06.370
here is basically I kept the ident Asian

0:50:04.600,0:50:08.200
but we will see we probably don't want

0:50:06.370,0:50:12.090
to have all those space in front that's

0:50:08.200,0:50:14.380
something that takes blog handles for us

0:50:12.090,0:50:15.970
something else that we can do is for

0:50:14.380,0:50:18.490
example the following with text blocks

0:50:15.970,0:50:25.870
so they're not able to able to evaluate

0:50:18.490,0:50:34.750
the expression but well let's just do

0:50:25.870,0:50:38.320
that so how did a person has here and

0:50:34.750,0:50:44.370
now I can use formatted and let's see

0:50:38.320,0:50:52.590
and what I want here is the speaker

0:50:44.370,0:50:52.590
first for example so let's run that

0:50:53.490,0:51:05.319
yep sorry typo it's a method so if we

0:51:02.829,0:51:06.789
look at the HTML you we see that here

0:51:05.319,0:51:08.230
well it's not class but it's the first

0:51:06.789,0:51:13.059
name but you get the idea so basically

0:51:08.230,0:51:15.819
we can do some kind of cheap expression

0:51:13.059,0:51:17.920
interpolation using formatted with text

0:51:15.819,0:51:20.680
blocks so that's basically our texworks

0:51:17.920,0:51:24.069
text blocks works now let's move on to

0:51:20.680,0:51:29.619
another features of number and that's

0:51:24.069,0:51:33.700
let's pattern matching so pattern

0:51:29.619,0:51:37.420
matching so you see we have this speaker

0:51:33.700,0:51:40.769
object which in fact is a person so that

0:51:37.420,0:51:50.349
means that we can do something like

0:51:40.769,0:51:53.200
speaker first right so we would get

0:51:50.349,0:51:57.069
david but it might happen that the type

0:51:53.200,0:51:58.869
of that object is of that yes of that

0:51:57.069,0:52:00.460
speaker would be object in that case if

0:51:58.869,0:52:02.019
you see we cannot directly invoke the

0:52:00.460,0:52:04.480
first method so what would would

0:52:02.019,0:52:11.619
typically do with something like this so

0:52:04.480,0:52:22.539
if speaker instance of it's a person so

0:52:11.619,0:52:27.999
if it's a person then what we do we

0:52:22.539,0:52:32.769
create a new object so it's a person

0:52:27.999,0:52:37.230
object X equal to a speaker but we have

0:52:32.769,0:52:39.489
two specific cast it to person type and

0:52:37.230,0:52:41.859
here obviously we want with the

0:52:39.489,0:52:44.769
exception so that works so the thing is

0:52:41.859,0:52:47.079
that here you see that if we have this

0:52:44.769,0:52:49.269
type we create an object of that same

0:52:47.079,0:52:51.099
type and we cast it from the other

0:52:49.269,0:52:53.289
object using that same type there are a

0:52:51.099,0:52:55.599
lot of repetition going on what we can

0:52:53.289,0:52:58.599
do now with pattern matching instance of

0:52:55.599,0:53:01.630
energy TK 14 is the following so we

0:52:58.599,0:53:05.670
declare the new variable here and that's

0:53:01.630,0:53:07.930
it so if you run this

0:53:05.670,0:53:08.490
we'll get the exact the exact same

0:53:07.930,0:53:12.180
behavior

0:53:08.490,0:53:14.380
so hello Davi this is the first one and

0:53:12.180,0:53:16.510
hello David this is the second one and

0:53:14.380,0:53:22.690
you see that this one is more 6n so it's

0:53:16.510,0:53:24.640
more obvious to use so the last one and

0:53:22.690,0:53:26.220
I'm probably gonna skip that one because

0:53:24.640,0:53:29.440
it takes a bit of time is this

0:53:26.220,0:53:34.450
expression so it's a new type of switch

0:53:29.440,0:53:36.430
expression that works like this so this

0:53:34.450,0:53:38.440
is on the left side this is how we

0:53:36.430,0:53:41.320
traditionally works the thing attacked

0:53:38.440,0:53:44.350
for example here there's a bug in the

0:53:41.320,0:53:47.530
sense that there is no break here so if

0:53:44.350,0:53:49.660
I do a switch on let's say Friday well

0:53:47.530,0:53:51.460
number of character will be 6 and then

0:53:49.660,0:53:55.690
it would be 7 so that would be the end

0:53:51.460,0:53:57.880
result 7 in this case I'm doing a switch

0:53:55.690,0:54:00.000
over an enumeration so all the values

0:53:57.880,0:54:03.160
are no because when numeration but still

0:54:00.000,0:54:04.960
if I miss for example one of the day the

0:54:03.160,0:54:07.240
compiler will not be able to tell me

0:54:04.960,0:54:09.100
okay you are not evaluating windows day

0:54:07.240,0:54:12.160
for example so that's why we have a

0:54:09.100,0:54:15.370
default but given that we know all the

0:54:12.160,0:54:17.670
value the default is a bit well it's a

0:54:15.370,0:54:21.130
bit hot to have to use a default value

0:54:17.670,0:54:23.920
so what we can do now there is a

0:54:21.130,0:54:27.880
question we will we be able to use

0:54:23.920,0:54:29.710
recorded GBA GP entities and not

0:54:27.880,0:54:31.690
directly something that well you can use

0:54:29.710,0:54:33.430
records with GPA but the thing that you

0:54:31.690,0:54:35.710
have to keep in mind is that records are

0:54:33.430,0:54:40.780
immutable so you cannot change with any

0:54:35.710,0:54:42.970
fills as soon as it has been created so

0:54:40.780,0:54:45.550
let's go back to these to the switch

0:54:42.970,0:54:49.090
expression this is the new switch

0:54:45.550,0:54:51.730
expression it basically returns the

0:54:49.090,0:54:53.140
value directly so something we were not

0:54:51.730,0:54:55.630
able to do in the former switch

0:54:53.140,0:54:57.250
expression so that well that's why this

0:54:55.630,0:54:59.020
is on the left side the switch statement

0:54:57.250,0:55:01.150
and this is an expression because it

0:54:59.020,0:55:03.790
returns the value so we have all the

0:55:01.150,0:55:06.520
case given that again we are doing a

0:55:03.790,0:55:09.280
case on enumeration the compiler will

0:55:06.520,0:55:11.500
test tell us if if for example were

0:55:09.280,0:55:13.720
missing a day so if we are missing a day

0:55:11.500,0:55:16.330
either we had this day or we have to

0:55:13.720,0:55:19.130
deal with the default value if we are

0:55:16.330,0:55:22.050
dealing with all the days and if

0:55:19.130,0:55:23.850
we have a default value the default will

0:55:22.050,0:55:27.990
never be rich so that's something that

0:55:23.850,0:55:29.730
the compiler can can also infer that the

0:55:27.990,0:55:33.060
default branch will is basically a dead

0:55:29.730,0:55:34.619
branch those kind of things so that's in

0:55:33.060,0:55:36.570
a nutshell the switch expression so I'm

0:55:34.619,0:55:39.570
going to move a little bit because I'm a

0:55:36.570,0:55:44.010
bit ahead of time I'm sorry

0:55:39.570,0:55:47.070
shouldn't my bad I switch the slide I

0:55:44.010,0:55:53.940
should then switch moved out of the

0:55:47.070,0:55:58.560
slides so the amber demo we have seen

0:55:53.940,0:56:00.240
the amber demo so those are some of the

0:55:58.560,0:56:01.980
project that the more ambitious

0:56:00.240,0:56:03.570
long-term project that we're working on

0:56:01.980,0:56:05.220
what we see is that gradually some of

0:56:03.570,0:56:08.220
the features emerging from this project

0:56:05.220,0:56:10.109
are headed in Java so we've seen the

0:56:08.220,0:56:12.090
foreign memory coming from loom for

0:56:10.109,0:56:14.460
example we've seen Alhambra has added

0:56:12.090,0:56:18.900
multiple features or since Java 10 in

0:56:14.460,0:56:21.210
the Java platform but obviously the Java

0:56:18.900,0:56:23.970
platform is not all about huge an

0:56:21.210,0:56:27.290
ambitious project in 14 we have this new

0:56:23.970,0:56:30.840
elf full new pointer exception jab 3 5 8

0:56:27.290,0:56:32.369
so we have all seen seen that kind of

0:56:30.840,0:56:34.320
code where we basically have a new

0:56:32.369,0:56:36.119
pointers so it's not a big deal because

0:56:34.320,0:56:38.850
the we know where the new point shows

0:56:36.119,0:56:41.730
happened so line 6 6 6 so we just have

0:56:38.850,0:56:43.820
to look at that line right the thing is

0:56:41.730,0:56:46.590
that line might looks like the following

0:56:43.820,0:56:49.619
so we know that it's happened here but

0:56:46.590,0:56:53.850
we really have no idea where it happened

0:56:49.619,0:56:56.310
exactly that's what the new pointers the

0:56:53.850,0:56:57.359
helpful with pointers option gives us so

0:56:56.310,0:57:01.020
that's something that you have to

0:56:57.359,0:57:02.700
explicitly enable in a 14 and now you

0:57:01.020,0:57:05.940
will have something like this so it

0:57:02.700,0:57:08.910
cannot involve the city get district

0:57:05.940,0:57:11.100
because the return value of get city is

0:57:08.910,0:57:13.680
null so it basically gives us more

0:57:11.100,0:57:15.150
information to help us to pinpoint the

0:57:13.680,0:57:17.040
exact issue that raised that new

0:57:15.150,0:57:20.270
pointers so that's something that is

0:57:17.040,0:57:22.619
available as a standard feature in 14

0:57:20.270,0:57:25.350
it's not in available enabled by default

0:57:22.619,0:57:28.920
and I've seen some discussion where in

0:57:25.350,0:57:30.630
15 it might be enabled by default so

0:57:28.920,0:57:33.950
it's a it's a small features but it's a

0:57:30.630,0:57:33.950
very convenient features

0:57:34.340,0:57:40.320
GDK flight recorder is something that is

0:57:37.920,0:57:43.560
available I think since Java 11 and the

0:57:40.320,0:57:45.780
basic idea of JDK of flight recorder GFR

0:57:43.560,0:57:47.730
it's a black box that keeps track of

0:57:45.780,0:57:49.800
even that are emitted by different

0:57:47.730,0:57:53.910
component within the GDK itself so it

0:57:49.800,0:57:58.800
can be the JVM it can be your code so a

0:57:53.910,0:58:00.690
bunch of heavens are raised and GFR will

0:57:58.800,0:58:03.390
keep track of them and that's something

0:58:00.690,0:58:05.400
that you can use after the fact to do

0:58:03.390,0:58:07.170
some kind of analysis the thing is that

0:58:05.400,0:58:08.280
GFR is very low overhead so that's

0:58:07.170,0:58:10.500
something that you can use in production

0:58:08.280,0:58:12.750
to basically detect and pinpoint

0:58:10.500,0:58:17.310
specific issue something that we're

0:58:12.750,0:58:22.290
hiring in GDK 14 is even swimming so

0:58:17.310,0:58:23.700
until now the the way you were using GFR

0:58:22.290,0:58:27.300
was the following so you start the

0:58:23.700,0:58:28.530
recording of your application so you use

0:58:27.300,0:58:30.840
your application then you stop the

0:58:28.530,0:58:33.980
recording you dub the content of the

0:58:30.840,0:58:38.400
event to repository and then you process

0:58:33.980,0:58:40.730
those events now an application that is

0:58:38.400,0:58:43.080
running as the ability to stream out

0:58:40.730,0:58:46.350
event as they happen so you can

0:58:43.080,0:58:48.510
basically do is you can have some some

0:58:46.350,0:58:51.210
some cough some some sort of sidecar

0:58:48.510,0:58:54.510
application to do analysis of the event

0:58:51.210,0:58:59.940
as they happen so there is a specific

0:58:54.510,0:59:02.400
API to do that in GDK 14 the thing is

0:58:59.940,0:59:04.620
that obviously we're keeping we are

0:59:02.400,0:59:07.560
improving a GFR through all the release

0:59:04.620,0:59:10.350
so in 14 we are we had hundred and forty

0:59:07.560,0:59:12.840
five different event types for GFR and

0:59:10.350,0:59:14.190
in 15 I've checked in the late well it's

0:59:12.840,0:59:16.680
not the latest bill because we have done

0:59:14.190,0:59:18.510
at twenty to build yesterday but in the

0:59:16.680,0:59:23.070
middle of last week we are we had

0:59:18.510,0:59:27.150
hundred and fifty-seven GFR even type so

0:59:23.070,0:59:29.790
it it keeps GFR it in itself keeps to

0:59:27.150,0:59:31.710
have more matrix within the platform

0:59:29.790,0:59:34.050
that you can use and not only that you

0:59:31.710,0:59:38.790
can also write your own custom and even

0:59:34.050,0:59:40.590
type for your application something else

0:59:38.790,0:59:44.280
that is part of Gd k14 is this new

0:59:40.590,0:59:46.200
packaging tool Jib Jab 343 right now

0:59:44.280,0:59:48.779
it's still in an equation phase

0:59:46.200,0:59:50.519
so the idea of that tool is it's a tool

0:59:48.779,0:59:53.099
that gives you the ability to create

0:59:50.519,0:59:55.200
native installer specific for a given

0:59:53.099,0:59:58.859
platform so on Windows you will either

0:59:55.200,1:00:01.529
have an MSI or an excel file on my quest

0:59:58.859,1:00:05.309
you will have a big package file or a

1:00:01.529,1:00:08.119
dmg and so on and so on and it has a lot

1:00:05.309,1:00:11.640
of additional I would say native

1:00:08.119,1:00:14.849
features such as the ability to pass

1:00:11.640,1:00:17.220
parameters to the native executable that

1:00:14.849,1:00:18.750
will invoke that will do the

1:00:17.220,1:00:21.089
installation of your java application

1:00:18.750,1:00:21.960
and obviously work with jailings and so

1:00:21.089,1:00:23.430
on and so on

1:00:21.960,1:00:25.049
so that's something that you can use

1:00:23.430,1:00:30.089
today to basically create an activex

1:00:25.049,1:00:34.380
installer for your java code now let's

1:00:30.089,1:00:36.119
quickly look at java 15 so that's the

1:00:34.380,1:00:42.809
schedule nothing will change on that

1:00:36.119,1:00:45.269
front so this is a table that I did well

1:00:42.809,1:00:47.789
I did it yesterday and I checked this

1:00:45.269,1:00:49.410
morning it was still up to date so those

1:00:47.789,1:00:55.440
are the multiple job that will be part

1:00:49.410,1:01:00.019
of 15 I'm going to discuss specifically

1:00:55.440,1:01:03.109
to Jeb's that is a learning class and

1:01:00.019,1:01:06.150
where it's your the one I'll seal the

1:01:03.109,1:01:10.619
silk types you'll class it's not here

1:01:06.150,1:01:12.329
now I don't so yeah I miss one well

1:01:10.619,1:01:15.210
anyway it's on my slide later on oh yes

1:01:12.329,1:01:19.470
here sorry it see the other one is silk

1:01:15.210,1:01:22.980
class so so this slide shows the jet

1:01:19.470,1:01:28.049
that are either integrated so already in

1:01:22.980,1:01:31.799
the early build of GDK 15 or they are

1:01:28.049,1:01:35.160
targeted so then sorry targeted means

1:01:31.799,1:01:37.710
that we intend to add them to 15 or we

1:01:35.160,1:01:39.150
propose to target them though so that's

1:01:37.710,1:01:40.920
basically the first step before we

1:01:39.150,1:01:43.980
integrate them so we tell the community

1:01:40.920,1:01:46.710
okay we want to add that to 15 is there

1:01:43.980,1:01:49.559
any objection if not we will if we move

1:01:46.710,1:01:52.140
to target it and then one the works is

1:01:49.559,1:01:54.599
done it will move from targeted to

1:01:52.140,1:01:57.599
integrated so basically there is a very

1:01:54.599,1:01:59.490
high chance that all the jets here will

1:01:57.599,1:02:03.809
be part of

1:01:59.490,1:02:06.750
GDK 15 just keep in mind the small

1:02:03.809,1:02:09.329
disclaimer that we might find a big

1:02:06.750,1:02:11.760
issue in one of those one of the jab

1:02:09.329,1:02:14.760
here and we might decide to remove it at

1:02:11.760,1:02:17.849
the very last minute so that there's

1:02:14.760,1:02:19.770
always a risk and then there are a few

1:02:17.849,1:02:22.500
other jabs that are currently being

1:02:19.770,1:02:26.069
worked on and we don't know yet if there

1:02:22.500,1:02:28.200
will be part of 15 so one is silk class

1:02:26.069,1:02:30.450
and well there are a bunch of jet but I

1:02:28.200,1:02:32.369
just took three where clearly there are

1:02:30.450,1:02:35.280
a lot of activities going on right now

1:02:32.369,1:02:36.839
so maybe there will be part of 15 we

1:02:35.280,1:02:39.660
will see in a few weeks

1:02:36.839,1:02:41.819
and at worst by early June we will know

1:02:39.660,1:02:44.880
for sure if they are part of 15 or not

1:02:41.819,1:02:47.130
so silk class flow in memory access an

1:02:44.880,1:02:49.050
incubator so that's part of project loom

1:02:47.130,1:02:52.380
and then the vector API which is also

1:02:49.050,1:02:56.480
part of Project loom so I'm going to

1:02:52.380,1:03:00.270
very quickly discuss a hidden class and

1:02:56.480,1:03:01.970
seal class which are often confused so a

1:03:00.270,1:03:04.650
hidden class is something that is very

1:03:01.970,1:03:09.180
specifically that has been specifically

1:03:04.650,1:03:11.790
done for frameworks developers so if we

1:03:09.180,1:03:14.670
look at frameworks they have this habit

1:03:11.790,1:03:18.089
of dynamically generating classes and

1:03:14.670,1:03:19.589
use those classes through reflection the

1:03:18.089,1:03:21.150
thing is that those classes given that

1:03:19.589,1:03:25.710
they're generated can potentially be

1:03:21.150,1:03:28.680
used by Hodder slash external bytecode

1:03:25.710,1:03:30.480
something that we clearly don't want so

1:03:28.680,1:03:32.369
basically the ability of it edan class

1:03:30.480,1:03:34.079
give now frameworks developer the

1:03:32.369,1:03:37.500
ability to still generate dynamic e

1:03:34.079,1:03:40.140
classes on the fly but those class are

1:03:37.500,1:03:41.670
hidden for the rest of the world so only

1:03:40.140,1:03:43.829
the framers that generate those tasks

1:03:41.670,1:03:46.470
will be able to use those classes so it

1:03:43.829,1:03:48.000
targets frameworks developers but if we

1:03:46.470,1:03:50.309
look at Java C for example Java sees

1:03:48.000,1:03:53.040
your show using the techniques for

1:03:50.309,1:03:54.780
example for lambda expression so that's

1:03:53.040,1:03:57.359
something that is also useful for Java

1:03:54.780,1:03:59.040
itself and one of the thing that will be

1:03:57.359,1:04:01.740
done in addition to creating this new

1:03:59.040,1:04:04.440
facility is also deprecating the Sun

1:04:01.740,1:04:06.900
Myshkin safe define analysis that is

1:04:04.440,1:04:11.339
used exactly for doing that dynamically

1:04:06.900,1:04:13.290
generating generating classes so if you

1:04:11.339,1:04:14.820
look at the properties of those classes

1:04:13.290,1:04:18.960
well in terms of discovery

1:04:14.820,1:04:21.270
discoverability they shouldn't be

1:04:18.960,1:04:23.640
basically discovered by discoverable by

1:04:21.270,1:04:27.119
classes outside of the classes that has

1:04:23.640,1:04:30.330
created at that classes in terms of life

1:04:27.119,1:04:34.500
cycle it should those classes should be

1:04:30.330,1:04:36.780
able to be aggressively unloaded to give

1:04:34.500,1:04:39.119
the framers the ability to generate a

1:04:36.780,1:04:40.740
lot of classes and as soon as those

1:04:39.119,1:04:43.560
classes are not needed they will be

1:04:40.740,1:04:45.180
automatically garbage collected now they

1:04:43.560,1:04:46.920
can be garbage collected through a more

1:04:45.180,1:04:49.800
traditional approach that's something

1:04:46.920,1:04:52.080
that is but the behavior of the GC is

1:04:49.800,1:04:54.420
configurable for hidden classes but what

1:04:52.080,1:04:55.830
we know for sure is that the aggressive

1:04:54.420,1:04:59.430
unloading is something that is needed

1:04:55.830,1:05:02.010
and then access control that basically

1:04:59.430,1:05:05.130
give us the ability forecast that

1:05:02.010,1:05:07.530
creates dynamically another class to

1:05:05.130,1:05:09.840
access that class but that also prevent

1:05:07.530,1:05:14.310
other classes external to that classes

1:05:09.840,1:05:15.540
to access that newly created class so

1:05:14.310,1:05:17.310
that's basically none shall hidden

1:05:15.540,1:05:19.260
classes it's not something that you're

1:05:17.310,1:05:20.940
gonna use that most of the developers

1:05:19.260,1:05:24.230
like you and me will use it's clearly

1:05:20.940,1:05:28.170
something for frameworks developers and

1:05:24.230,1:05:29.490
then they are seed blast and some people

1:05:28.170,1:05:33.750
tend to confuse the two there are

1:05:29.490,1:05:35.670
completely different so before we talk

1:05:33.750,1:05:38.369
about seed class we need to quickly talk

1:05:35.670,1:05:41.340
about inheritance so inheritance is

1:05:38.369,1:05:43.380
something that encourage code reuse so

1:05:41.340,1:05:45.420
we basically have a class hierarchy and

1:05:43.380,1:05:50.490
all the class for example a class that X

1:05:45.420,1:05:55.380
and the class can reuse features from

1:05:50.490,1:05:57.270
the class that it extends for now the

1:05:55.380,1:06:00.720
thing is that the class hierarchy is

1:05:57.270,1:06:02.940
most of the quail is often used for code

1:06:00.720,1:06:05.369
reuse but sometimes it's used for

1:06:02.940,1:06:07.380
something completely different so the

1:06:05.369,1:06:09.300
class hierarchy is on is sometimes also

1:06:07.380,1:06:11.940
used to model different possibility of a

1:06:09.300,1:06:13.619
given gap of given domains so for

1:06:11.940,1:06:15.240
example we want to model the different

1:06:13.619,1:06:17.160
shape that are supported by a graphic

1:06:15.240,1:06:22.040
application so we would have a shape

1:06:17.160,1:06:24.920
class or interface and then we are have

1:06:22.040,1:06:27.040
subclasses that would extend that shape

1:06:24.920,1:06:29.260
classes like a square

1:06:27.040,1:06:31.840
the shapes on exactly next and shapes

1:06:29.260,1:06:34.570
and so on or we we can have a class that

1:06:31.840,1:06:37.720
representative type of vehicles that we

1:06:34.570,1:06:40.480
sell and then we would have I don't know

1:06:37.720,1:06:45.070
a CV a coupe sedan and so on that

1:06:40.480,1:06:46.930
extends that super classes so that's a

1:06:45.070,1:06:48.820
different something that is completely

1:06:46.930,1:06:52.540
different and the problem is that right

1:06:48.820,1:06:54.490
now if you have this shape superclass

1:06:52.540,1:06:56.080
that is extended by triangle circle

1:06:54.490,1:06:58.600
exact on and so on you cannot prevent

1:06:56.080,1:07:00.250
any other class to also extend it and

1:06:58.600,1:07:05.170
that's something that we would like to

1:07:00.250,1:07:10.420
well read with a sealed class so C Class

1:07:05.170,1:07:12.370
would basically allows to have a given

1:07:10.420,1:07:14.380
class hierarchy that is bounded so it

1:07:12.370,1:07:18.610
the class hierarchy can only be extended

1:07:14.380,1:07:20.740
by class within that limited closed

1:07:18.610,1:07:23.230
class hierarchy and not by any external

1:07:20.740,1:07:25.240
classes and every cycle we use would

1:07:23.230,1:07:26.860
still be possible but it would only be

1:07:25.240,1:07:29.260
possible within domain within the

1:07:26.860,1:07:34.390
boundary boundary of the closet class

1:07:29.260,1:07:36.820
hierarchy so how does that work well

1:07:34.390,1:07:39.160
let's have a look at an example that

1:07:36.820,1:07:42.790
would be more obvious so I have this

1:07:39.160,1:07:46.960
shape superclass and we have two new

1:07:42.790,1:07:49.750
keywords so we have sealed that is used

1:07:46.960,1:07:52.120
to basically say okay the class shape is

1:07:49.750,1:07:54.430
sealed and then we have the permits

1:07:52.120,1:07:57.460
keyword that tells which class or

1:07:54.430,1:08:01.990
interface can use that superclass so

1:07:57.460,1:08:05.080
sealed is sorry shape is sealed and only

1:08:01.990,1:08:09.550
in this example circle circle rectangle

1:08:05.080,1:08:11.500
and square are allowed to extend the

1:08:09.550,1:08:13.720
shapes and then there are a few

1:08:11.500,1:08:15.670
variations like the flag the fact that

1:08:13.720,1:08:17.950
if you are within the same package or SM

1:08:15.670,1:08:21.010
modules you can just use the class name

1:08:17.950,1:08:25.089
you don't have to use the full package

1:08:21.010,1:08:29.650
name if you have nested class so all the

1:08:25.089,1:08:32.170
classes within a single file source you

1:08:29.650,1:08:34.540
just seal the superclass and by default

1:08:32.170,1:08:37.619
all the classes that are present in the

1:08:34.540,1:08:41.730
same source file will be

1:08:37.619,1:08:42.750
permitted by default to extend that soup

1:08:41.730,1:08:45.599
superclass

1:08:42.750,1:08:47.909
so that's basically how it works now

1:08:45.599,1:08:51.089
it's not clear today if Silva's will be

1:08:47.909,1:08:53.639
part of did he give 15 if not that's not

1:08:51.089,1:08:55.380
really an issue just mean that we'll

1:08:53.639,1:09:02.310
have to wait another six months

1:08:55.380,1:09:06.630
and it will be for GF 16 so I think it's

1:09:02.310,1:09:09.449
time to wrap up so today we've discussed

1:09:06.630,1:09:11.369
about what new features will be added to

1:09:09.449,1:09:14.400
Java in 2020

1:09:11.369,1:09:17.609
so GDK 14 was released two months ago

1:09:14.400,1:09:19.650
and DK 15 will be raised in four months

1:09:17.609,1:09:21.690
from now i've also discussed very

1:09:19.650,1:09:23.810
quickly and outdoors large ambitious

1:09:21.690,1:09:26.670
long-term projects are basically

1:09:23.810,1:09:29.599
gradually adding capabilities into the

1:09:26.670,1:09:33.900
platform with the ultimate goal goals of

1:09:29.599,1:09:37.020
revamping completely the platform now I

1:09:33.900,1:09:38.909
I need to quickly discuss another new

1:09:37.020,1:09:41.520
project that we've just announced two

1:09:38.909,1:09:44.369
weeks ago and that is Laden so laden

1:09:41.520,1:09:46.650
basically tried to solve to tackle some

1:09:44.369,1:09:49.170
of the pain points of Java and that is

1:09:46.650,1:09:51.569
the slow startup time the slow time to

1:09:49.170,1:09:53.040
performance and the locked footprint of

1:09:51.569,1:09:54.989
the Bob java application

1:09:53.040,1:09:57.599
and everything is relative when I say

1:09:54.989,1:09:59.119
slow it's low compared to typically

1:09:57.599,1:10:01.920
native applications for example

1:09:59.119,1:10:05.670
footprints it's again compared to native

1:10:01.920,1:10:07.260
application so basically a Laden tried

1:10:05.670,1:10:09.659
to tackle those pain point by

1:10:07.260,1:10:13.500
introducing the concept of a static

1:10:09.659,1:10:18.380
image to Java something similar to Ralph

1:10:13.500,1:10:21.270
Ian achieve image Laden aims to leverage

1:10:18.380,1:10:24.659
existing component of the GDK such as

1:10:21.270,1:10:27.119
hotspot G a OTC which is an alt compiler

1:10:24.659,1:10:27.690
that we have an experimental form since

1:10:27.119,1:10:31.020
gk9

1:10:27.690,1:10:33.420
into the platform but also C D s and

1:10:31.020,1:10:34.980
gelling and clearly this is just the

1:10:33.420,1:10:39.810
early days of leiden we have just

1:10:34.980,1:10:41.730
started to gather interest around that

1:10:39.810,1:10:43.199
project but we think that over time this

1:10:41.730,1:10:45.389
is something that would be important so

1:10:43.199,1:10:47.810
basically trot bring the capability that

1:10:45.389,1:10:51.350
we have with native Miam then similar

1:10:47.810,1:10:56.840
capabilities but directly into the Java

1:10:51.350,1:10:59.780
form so this is the slides depict the

1:10:56.840,1:11:01.430
content of GDK 14 I think that we have

1:10:59.780,1:11:03.770
discussed most of the jobs that we have

1:11:01.430,1:11:05.330
here the only thing that I need to

1:11:03.770,1:11:07.010
mention and I think I've mentioned that

1:11:05.330,1:11:09.830
at the beginning is that jobs are are

1:11:07.010,1:11:11.510
also used to remove holger things from

1:11:09.830,1:11:16.220
the platform so you see that for example

1:11:11.510,1:11:18.890
3 6 2 & 3 6 3 are duplicating things

1:11:16.220,1:11:20.480
from the platform and or removing so

1:11:18.890,1:11:22.670
when we remove something from the

1:11:20.480,1:11:24.080
platform we first deprecated to tell the

1:11:22.670,1:11:26.930
world that ok that features will be

1:11:24.080,1:11:29.600
removed in the features and then later

1:11:26.930,1:11:37.220
on it will be actually removed so it's

1:11:29.600,1:11:39.230
abilities face removal approach and da14

1:11:37.220,1:11:44.240
is available so you should download it

1:11:39.230,1:11:46.880
right now and give it a try so in terms

1:11:44.240,1:11:48.530
of conclusion Java is still free we have

1:11:46.880,1:11:50.810
put in place everything to deliver

1:11:48.530,1:11:53.630
faster and we are delivering faster and

1:11:50.810,1:11:57.890
we haven't had Rich's future pipeline

1:11:53.630,1:12:01.310
for the Java platform a heifer and also

1:11:57.890,1:12:04.400
keep in mind this year marks the 25th

1:12:01.310,1:12:06.320
anniversary of Java and given the

1:12:04.400,1:12:07.340
pipeline that we have well we can't

1:12:06.320,1:12:11.630
really say that there is a bright future

1:12:07.340,1:12:14.390
for Java developers and with that I'd

1:12:11.630,1:12:15.440
like to thank you for your time and I

1:12:14.390,1:12:17.770
don't know if we still have time for

1:12:15.440,1:12:17.770
questions

1:12:20.870,1:12:30.560
have time for one question someone have

1:12:23.090,1:12:32.150
a question you can also ask question on

1:12:30.560,1:12:33.920
Twitter so there is my Twitter handle

1:12:32.150,1:12:37.700
there so if you have any question and

1:12:33.920,1:12:39.110
you don't feel like asking now you can

1:12:37.700,1:12:46.300
also ping me on Twitter

1:12:39.110,1:12:52.940
I think stream 8 has a question yeah so

1:12:46.300,1:12:55.640
regarding the project so the last thing

1:12:52.940,1:12:59.390
was actually looking into is is the the

1:12:55.640,1:13:00.770
problem of high pressures in high

1:12:59.390,1:13:03.110
pressure in gently so that is a real

1:13:00.770,1:13:05.480
that's more complicated problem in

1:13:03.110,1:13:08.870
father so what is the state of it and if

1:13:05.480,1:13:16.460
there is that is that is that mountain

1:13:08.870,1:13:18.980
climb then so you know Brian gets the

1:13:16.460,1:13:21.020
job architect so Brian is the architect

1:13:18.980,1:13:23.450
of the Java platform and basically his

1:13:21.020,1:13:25.640
answer is it will be so whenever someone

1:13:23.450,1:13:28.370
ask about when it will be deliver his

1:13:25.640,1:13:30.590
answer is is pretty easy it will be a

1:13:28.370,1:13:34.550
below it will be available when it's

1:13:30.590,1:13:36.860
ready and the fact that well it's not

1:13:34.550,1:13:41.090
yet there means that well things are

1:13:36.860,1:13:42.710
still being being worked on so I cannot

1:13:41.090,1:13:44.870
give you any more precise answer than

1:13:42.710,1:13:47.570
that but yeah you're right Vala lies

1:13:44.870,1:13:51.410
it's really a fundamental change within

1:13:47.570,1:13:53.990
the platform the nice thing is that with

1:13:51.410,1:13:55.700
the new release guidance well we don't

1:13:53.990,1:13:57.830
have the issue that we we had in the

1:13:55.700,1:13:59.060
past where we basically add a time

1:13:57.830,1:14:02.510
window to add new features in the

1:13:59.060,1:14:05.180
platform every three years so if we miss

1:14:02.510,1:14:06.560
that time window that basically means

1:14:05.180,1:14:09.980
that we have to wait another three years

1:14:06.560,1:14:12.920
to add that into the platform those days

1:14:09.980,1:14:14.920
we can gradually add features every six

1:14:12.920,1:14:18.770
months so we can expect in the future

1:14:14.920,1:14:22.190
release to come to see some features

1:14:18.770,1:14:23.540
emerging from Vdara but I can I can give

1:14:22.190,1:14:26.260
you any more precise answer than that

1:14:23.540,1:14:26.260
I'm sorry

1:14:33.710,1:14:37.130
thank you David

1:14:37.729,1:14:43.469
thank you thanks you thank you very time

1:14:40.639,1:14:52.249
okay thanks everyone for joining since

1:14:43.469,1:14:52.249
you next time thank you yeah bye