The @SuppressWarnings Annotation - "static"4:40 with Chris Ramacciotti
Here we get our first look at the
@SuppressWarnings annotation. This annotation can be used to turn off compiler warnings - either all warnings or only certain ones. This video considers the warning a compiler gives you when you incorrectly call a static method.
Android Style Guide
In reference to the public service announcement to avoid using the
@SuppressWarnings annotation by correcting any errors possible, here is Google's note to developers of the Android OS:
Let's turn now to the SuppressWarnings annotation, 0:00 another one provided by the core Java library. 0:03 The SuppressWarnings annotation is also a compiler instruction that does 0:05 exactly what it says, it suppresses compiler warnings. 0:10 Though warnings won't prevent your code from compiling, 0:13 they can indicate a number of potential problems including unnecessary code, 0:16 a higher likelihood for runtime errors or 0:21 code that is in need of updating to the latest standards and practices. 0:24 Let's check out the use of suppress warnings in two scenarios, 0:28 improper use of the static method and a missing break statement in a switch block, 0:32 let's check out these two cases now. 0:36 In the same workspaces project, open the suppresswarnings package to see a handful 0:39 of starter classes related to a hypothetical blogging engine. 0:43 Now, these classes are largely useless in their current form, but for 0:47 the purposes of context, I'll explain a bit of the set up. 0:50 First there is the blog class, which is meant to simply be a container for 0:53 methods related to retrieving blog related content. 0:58 In this case, some of the latest posts. 1:02 The Post class encapsulates the main components of a blog post, a title, 1:05 subtitle, maybe the text content, a couple of dates here and 1:09 a list of the comments on the post. 1:13 Remember, everything here is simply to demonstrate a basic concept but 1:16 in a relevant context. 1:20 And what is that context? 1:22 Let say you are contracted by a company 1:25 to write a new website based on their old blogging engine. 1:27 That is, this hypothetical one we have here. 1:30 You might need to use outdated code that you don't have control over. 1:34 Of course, your code will be pristine, so 1:37 how do you bridge the gap between your modern flawless code and legacy code? 1:39 You want your code to compile with zero errors and zero warnings so 1:44 that your attention can be quickly captured when a new warning pops up 1:48 that is indeed problematic. 1:51 Heading over to the main class, this being the new code that you may have written. 1:54 What we have here is a simple user interface for our blog. 1:59 It starts by a user prompt asking for the number of posts the user 2:04 would like to see, stores it into this variable named numPosts, and 2:08 then uses that variable in calling the blog classes getLatestPost methods. 2:12 Then there is a switch statement here that displays a message depending 2:18 on the number of posts the user has decided he or she wants to see. 2:22 Let's go ahead and compile this code to see what kind of shape we're in. 2:27 And hey, remember that excellent option we just learned about? 2:30 Let's add that so that we can see all compiler warnings. 2:34 So, we'll use the javac command, 2:37 there's the Xlint option, don't forget to capitalize that X. 2:39 We will use the out directory as the destination for our .class files. 2:43 Don't forget to specify the source directory as your classpath and 2:48 then the full path name to the file that we'd like to compile. 2:52 Two warnings. 3:00 Let's look at the first one. 3:02 It says that the static method should be qualified by type name instead of 3:03 an expression. 3:08 You probably see how to fix this, and we'll do that later, but I want to show 3:10 you how to tell the compiler to stop telling us about these kinds of warnings. 3:14 What you can do is apply the SuppressWarnings annotation 3:19 to the method or class that contains the reference line. 3:22 In this case that would be line 17 that is causing this warning, 3:25 this line right here. 3:29 If we go to the method that contains this line, 3:31 that would be the main method, we can apply a SuppressWarnings annotation there. 3:34 First though, 3:40 a public service announcement about suppressing compiler warnings. 3:40 Whenever possible, and this is usually possible, correct your code so 3:45 that there's no need to use SuppressWarnings. 3:49 As a motivation to Android developers, in its Java style guide for Android, 3:53 Google tells its developers that a warning must pass the impossible to 3:57 eliminate test in order to use the SuppressWarnings annotation. 4:02 Okay, with that out of the way, let's use SuppressWarnings. 4:07 I'll add the annotation to the main method using SuppressWarnings and 4:11 in parentheses, I will list the string static. 4:17 I know to use static because that's the name the compiler shows in brackets. 4:22 And after we recompile, we see that we are down to one warning instead of two. 4:27 Sweet. 4:35 Let's take a short break and then look at another warning we can suppress. 4:36
You need to sign up for Treehouse in order to download course files.Sign up