Let's turn now to the SuppressWarnings annotation,

another one provided by the core Java library.

The SuppressWarnings annotation is also a compiler instruction that does

exactly what it says, it suppresses compiler warnings.

Though warnings won't prevent your code from compiling,

they can indicate a number of potential problems including unnecessary code,

a higher likelihood for runtime errors or

code that is in need of updating to the latest standards and practices.

Let's check out the use of suppress warnings in two scenarios,

improper use of the static method and a missing break statement in a switch block,

let's check out these two cases now.

In the same workspaces project, open the suppresswarnings package to see a handful

of starter classes related to a hypothetical blogging engine.

Now, these classes are largely useless in their current form, but for

the purposes of context, I'll explain a bit of the set up.

First there is the blog class, which is meant to simply be a container for

methods related to retrieving blog related content.

In this case, some of the latest posts.

The Post class encapsulates the main components of a blog post, a title,

subtitle, maybe the text content, a couple of dates here and

a list of the comments on the post.

Remember, everything here is simply to demonstrate a basic concept but

in a relevant context.

And what is that context?

Let say you are contracted by a company

to write a new website based on their old blogging engine.

That is, this hypothetical one we have here.

You might need to use outdated code that you don't have control over.

Of course, your code will be pristine, so

how do you bridge the gap between your modern flawless code and legacy code?

You want your code to compile with zero errors and zero warnings so

that your attention can be quickly captured when a new warning pops up

that is indeed problematic.

Heading over to the main class, this being the new code that you may have written.

What we have here is a simple user interface for our blog.

It starts by a user prompt asking for the number of posts the user

would like to see, stores it into this variable named numPosts, and

then uses that variable in calling the blog classes getLatestPost methods.

Then there is a switch statement here that displays a message depending

on the number of posts the user has decided he or she wants to see.

Let's go ahead and compile this code to see what kind of shape we're in.

And hey, remember that excellent option we just learned about?

Let's add that so that we can see all compiler warnings.

So, we'll use the javac command,

there's the Xlint option, don't forget to capitalize that X.

We will use the out directory as the destination for our .class files.

Don't forget to specify the source directory as your classpath and

then the full path name to the file that we'd like to compile.

Two warnings.

Let's look at the first one.

It says that the static method should be qualified by type name instead of

an expression.

You probably see how to fix this, and we'll do that later, but I want to show

you how to tell the compiler to stop telling us about these kinds of warnings.

What you can do is apply the SuppressWarnings annotation

to the method or class that contains the reference line.

In this case that would be line 17 that is causing this warning,

this line right here.

If we go to the method that contains this line,

that would be the main method, we can apply a SuppressWarnings annotation there.

First though,

a public service announcement about suppressing compiler warnings.

Whenever possible, and this is usually possible, correct your code so

that there's no need to use SuppressWarnings.

As a motivation to Android developers, in its Java style guide for Android,

Google tells its developers that a warning must pass the impossible to

eliminate test in order to use the SuppressWarnings annotation.

Okay, with that out of the way, let's use SuppressWarnings.

I'll add the annotation to the main method using SuppressWarnings and

in parentheses, I will list the string static.

I know to use static because that's the name the compiler shows in brackets.

And after we recompile, we see that we are down to one warning instead of two.

Sweet.

Let's take a short break and then look at another warning we can suppress.