Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
In a switch statement with many cases, it can be easy to accidentally leave off a break statement. And in some cases, this may be done intentionally to save a few lines of code. We can use the @SuppressWarnings annotation to control the compiler warnings about these scenarios when a break statement is missing and execution "falls through" to the next case.
Back in the same workspaces
project as before,
0:00
I'm in the main class of
the suppress warnings package.
0:02
I'm gonna recompile my code with
the excellent directory and
0:05
class path options to remind
myself of our remaining warnings.
0:08
So javac, here's my Xlint, options so that
I can see all compiler warnings, here's
0:11
my directory options so that I can specify
the destination of our class files.
0:16
I can specify the classpath with the cp
option using src as the classpath.
0:21
And then I can indicate the full path
of the file I'd like to compile.
0:27
And it looks like we have just one warning
left, and this one is called fallthrough.
0:35
Even though we'd ideally fix
the source of the warning,
0:41
we are able to suppress
the warning as well.
0:43
We can do this by adding to our
suppressed warnings annotation.
0:46
If we want to add multiple
warnings to suppress,
0:50
we add them just as we would a string
of ray literal with curly braces.
0:52
So after the string static
I would add fallthrough.
0:57
Again, I know this because that
is exactly the string that's used
1:01
by the compiler when it
gives us the warning.
1:05
And, if we recompile after this,
we see that we have no warnings.
1:09
Great, we fixed both our problems.
1:15
Well, not really.
1:18
We silenced the compiler.
1:20
And, kind of like closing the door to
a messy bedroom doesn't mean you have tidy
1:22
house, shushing the compiler doesn't mean
we're using best programming practices.
1:25
If we didn't have access to all
the source code used in our application,
1:30
this might be the extent of our fix.
1:34
But remember that public
service announcement I made
1:36
that you should correct your
code whenever possible so
1:39
that you don't have to
use suppress warnings.
1:41
Since it is indeed possible for
us, let's do that now.
1:44
I'm sure you already figured this out but
1:49
the incorrect static reference that we
were told about is due to the fact that
1:50
we've called a static method
getLatestPost on an instance B.
1:54
We can verify that it's a static
method by going to our blog class and
2:00
seeing that, yes, it is indeed static.
2:04
So, we should be calling that
method with the class name instead
2:06
of an instance name.
2:09
Blog.getlatestposts.
2:11
And with that change made it looks
like variable B is no longer used.
2:14
And also let's delete it all together.
2:17
I'll save that, and let's remove static,
since we took care of that warning.
2:21
Let's remove static from our suppressed
warnings annotation and recompile.
2:26
Great, still no warnings.
2:34
Now, moving on to the fallthrough warning.
2:36
This is because of a missing break
statement in the switch statement.
2:38
So, in our switch statement here,
we have three cases.
2:43
The first case or
case zero has no break statement.
2:47
The only case in which one should really
2:51
omit a break statement is if there's
no code to run in that case.
2:54
Otherwise, if you have any code
that you're running in that case,
2:58
in general it's considered best
practices to include a break statement.
3:00
Let's do that now.
3:04
Otherwise, if there are zero posts, we'll
see this message that says, no posts.
3:06
And execution falls through to case one
to the first break statement is there.
3:10
Now that we have a break statement here,
we will no longer have a fallthrough.
3:15
So let's delete this suppress
warnings annotation altogether,
3:19
since fallthrough was
the only one that was left.
3:23
I'll save that.
3:26
Let's recompile it.
3:27
And wonderful,
we have no errors or warnings.
3:30
And as icing on the cake,
3:34
we didn't accomplish this by
actively silencing the compiler.
3:35
Success!
3:39
You've seen the built-in annotations
provided by the core Java language library
3:41
with override, suppress warnings,
and deprecated.
3:45
These three simply serve as instructions
to the compiler to perform additional
3:49
checks on your code and tweak the error
and warning reporting of the compiler.
3:53
Now that you've got the basics,
let me tell you that third-party libraries
3:58
make extensive and
powerful use of annotations.
4:02
For example, if you're writing a web
app using the spring framework,
4:06
with the addition of a simple annotation
on a method, you can configure your app to
4:09
execute that method whenever
a user visits a certain URL.
4:14
Or, if your application is
backed by a a database,
4:19
which most are these days, then you
can use a library called hibernate.
4:22
Hibernate adds a handful of annotations
to connect java objects to database rows
4:27
and instance fields to database columns.
4:32
After that, you can call a simple
save method on a Java object
4:35
which will automatically update
the corresponding record in the database.
4:40
It's pretty cool stuff, and
saves programmers loads of time.
4:44
In general,
a recent trend in third party libraries
4:48
is to provide programmers
XML free configuration.
4:52
In the past, the most common way to
configure your application to properly use
4:56
these libraries was to
include a pile of XML files.
5:00
Some think that this
separation of configuration
5:04
from the code it directly
relates to is confusing.
5:07
One alternative that has gained
popularity is the use of annotations
5:11
which is a pure Java solution.
5:16
Apply those annotations to the code it
affects and we're rocking and rolling.
5:18
Well, this seems like a good time for
a short break.
5:24
When we return, we'll chat about
writing our own annotation.
5:26
You need to sign up for Treehouse in order to download course files.
Sign up