1

00:00:00.06 --> 00:00:02.02

- [Instructor] Now the

last big-picture change



2

00:00:02.02 --> 00:00:05.06

that we're going to talk about,

is the Nullable annotation



3

00:00:05.06 --> 00:00:08.09

that we now have support for in Spring 5.



4

00:00:08.09 --> 00:00:11.04

Nullable is part of JSR 305,



5

00:00:11.04 --> 00:00:14.00

which is a set of

annotations used primarily



6

00:00:14.00 --> 00:00:16.05

for software defect detection.



7

00:00:16.05 --> 00:00:20.07

In fact a lot of static

analysis leverages JSR 305



8

00:00:20.07 --> 00:00:23.02

to determine if null

checks need to be included



9

00:00:23.02 --> 00:00:25.00

in the code or not.



10

00:00:25.00 --> 00:00:28.08

IDE support also is leveraging JSR 305



11

00:00:28.08 --> 00:00:32.09

to give you compiler warnings

as you're writing your code.



12

00:00:32.09 --> 00:00:35.06

Now Spring is using

the Nullable annotation



13

00:00:35.06 --> 00:00:39.04

as part of its IoC container

in version of control,



14

00:00:39.04 --> 00:00:40.09

or dependency injection, depending on



15

00:00:40.09 --> 00:00:42.05

how you want to look at that, but it's all



16

00:00:42.05 --> 00:00:44.04

really the same thing.



17

00:00:44.04 --> 00:00:48.04

This is an indication of

optional injection points.



18

00:00:48.04 --> 00:00:50.05

And that's really key

there because we're getting



19

00:00:50.05 --> 00:00:53.03

optional injection points that can be used



20

00:00:53.03 --> 00:00:56.02

for other JVM languages, and

we're going to talk about that



21

00:00:56.02 --> 00:00:57.05

in a little bit.



22

00:00:57.05 --> 00:01:00.02

We get field-level

annotation through the use



23

00:01:00.02 --> 00:01:02.06

of the @Nullable annotation.



24

00:01:02.06 --> 00:01:05.00

We also get parameter-level annotation



25

00:01:05.00 --> 00:01:08.01

using that same Nullable annotation.



26

00:01:08.01 --> 00:01:11.00

Indeed we can put it on

the return value method,



27

00:01:11.00 --> 00:01:15.08

a parameter of a method, or a

field-level value in a class.



28

00:01:15.08 --> 00:01:18.01

Now at the package level

we get an annotation



29

00:01:18.01 --> 00:01:21.09

of NonNullApi, that can be

applied to all of the methods



30

00:01:21.09 --> 00:01:23.05

within a package.



31

00:01:23.05 --> 00:01:25.04

One thing that you can't help but ignore



32

00:01:25.04 --> 00:01:28.01

is that the beauty of

Kotlin has really influenced



33

00:01:28.01 --> 00:01:30.03

a lot of this within the JVM,



34

00:01:30.03 --> 00:01:33.00

and specifically within Spring.



35

00:01:33.00 --> 00:01:36.07

Spring has a very strong

affinity towards Kotlin,



36

00:01:36.07 --> 00:01:38.06

and it appears to me

that it really has become



37

00:01:38.06 --> 00:01:43.00

the defacto language of choice

when you're not using Java



38

00:01:43.00 --> 00:01:45.08

for developing Spring applications.



39

00:01:45.08 --> 00:01:48.01

Kotlin itself has native support



40

00:01:48.01 --> 00:01:51.04

for non-null safety, and that's key.



41

00:01:51.04 --> 00:01:53.00

Because when you declare a variable



42

00:01:53.00 --> 00:01:55.09

you say whether it can be null or not.



43

00:01:55.09 --> 00:01:58.05

And if it is not nullable, you don't need



44

00:01:58.05 --> 00:01:59.05

to put null checks.



45

00:01:59.05 --> 00:02:02.04

But if it is nullable, you

need to have null checks



46

00:02:02.04 --> 00:02:04.00

across your code.



47

00:02:04.00 --> 00:02:05.09

And this is really designed to remove



48

00:02:05.09 --> 00:02:08.01

a lot of that code bloat that happens



49

00:02:08.01 --> 00:02:11.01

when we write good-quality defensive code.



50

00:02:11.01 --> 00:02:13.02

Now I am a fan of defensive code.



51

00:02:13.02 --> 00:02:15.08

I think it's very easy

to read and very clean,



52

00:02:15.08 --> 00:02:18.01

and it let's me actually

check what I'm doing.



53

00:02:18.01 --> 00:02:19.08

But I'm probably in the minority



54

00:02:19.08 --> 00:02:22.07

when it comes to the

beauty of that in my eyes.



55

00:02:22.07 --> 00:02:25.05

And of course beauty is always

in the eye of the beholder,



56

00:02:25.05 --> 00:02:27.04

so I don't have a problem with that.



57

00:02:27.04 --> 00:02:30.00

But if you're a fan of

not having null checks



58

00:02:30.00 --> 00:02:32.07

in your code and not being as defensive,



59

00:02:32.07 --> 00:02:34.07

check out the Nullable annotation.



60

00:02:34.07 --> 00:02:36.07

You might really like it, especially when



61

00:02:36.07 --> 00:02:38.05

you're writing a Spring application.



