Back in the same workspaces project as before,

I'm in the main class of the suppress warnings package.

I'm gonna recompile my code with the excellent directory and

class path options to remind myself of our remaining warnings.

So javac, here's my Xlint, options so that I can see all compiler warnings, here's

my directory options so that I can specify the destination of our class files.

I can specify the classpath with the cp option using src as the classpath.

And then I can indicate the full path of the file I'd like to compile.

And it looks like we have just one warning left, and this one is called fallthrough.

Even though we'd ideally fix the source of the warning,

we are able to suppress the warning as well.

We can do this by adding to our suppressed warnings annotation.

If we want to add multiple warnings to suppress,

we add them just as we would a string of ray literal with curly braces.

So after the string static I would add fallthrough.

Again, I know this because that is exactly the string that's used

by the compiler when it gives us the warning.

And, if we recompile after this, we see that we have no warnings.

Great, we fixed both our problems.

Well, not really.

We silenced the compiler.

And, kind of like closing the door to a messy bedroom doesn't mean you have tidy

house, shushing the compiler doesn't mean we're using best programming practices.

If we didn't have access to all the source code used in our application,

this might be the extent of our fix.

But remember that public service announcement I made

that you should correct your code whenever possible so

that you don't have to use suppress warnings.

Since it is indeed possible for us, let's do that now.

I'm sure you already figured this out but

the incorrect static reference that we were told about is due to the fact that

we've called a static method getLatestPost on an instance B.

We can verify that it's a static method by going to our blog class and

seeing that, yes, it is indeed static.

So, we should be calling that method with the class name instead

of an instance name.

Blog.getlatestposts.

And with that change made it looks like variable B is no longer used.

And also let's delete it all together.

I'll save that, and let's remove static, since we took care of that warning.

Let's remove static from our suppressed warnings annotation and recompile.

Great, still no warnings.

Now, moving on to the fallthrough warning.

This is because of a missing break statement in the switch statement.

So, in our switch statement here, we have three cases.

The first case or case zero has no break statement.

The only case in which one should really

omit a break statement is if there's no code to run in that case.

Otherwise, if you have any code that you're running in that case,

in general it's considered best practices to include a break statement.

Let's do that now.

Otherwise, if there are zero posts, we'll see this message that says, no posts.

And execution falls through to case one to the first break statement is there.

Now that we have a break statement here, we will no longer have a fallthrough.

So let's delete this suppress warnings annotation altogether,

since fallthrough was the only one that was left.

I'll save that.

Let's recompile it.

And wonderful, we have no errors or warnings.

And as icing on the cake,

we didn't accomplish this by actively silencing the compiler.

Success!

You've seen the built-in annotations provided by the core Java language library

with override, suppress warnings, and deprecated.

These three simply serve as instructions to the compiler to perform additional

checks on your code and tweak the error and warning reporting of the compiler.

Now that you've got the basics, let me tell you that third-party libraries

make extensive and powerful use of annotations.

For example, if you're writing a web app using the spring framework,

with the addition of a simple annotation on a method, you can configure your app to

execute that method whenever a user visits a certain URL.

Or, if your application is backed by a a database,

which most are these days, then you can use a library called hibernate.

Hibernate adds a handful of annotations to connect java objects to database rows

and instance fields to database columns.

After that, you can call a simple save method on a Java object

which will automatically update the corresponding record in the database.

It's pretty cool stuff, and saves programmers loads of time.

In general, a recent trend in third party libraries

is to provide programmers XML free configuration.

In the past, the most common way to configure your application to properly use

these libraries was to include a pile of XML files.

Some think that this separation of configuration

from the code it directly relates to is confusing.

One alternative that has gained popularity is the use of annotations

which is a pure Java solution.

Apply those annotations to the code it affects and we're rocking and rolling.

Well, this seems like a good time for a short break.

When we return, we'll chat about writing our own annotation.