The @SuppressWarnings Annotation - "fallthrough"

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